• Content Count

  • Joined

  • Last visited

  • Days Won


Wingnut last won the day on July 4

Wingnut had the most liked content!

About Wingnut

  • Rank
    Advanced Member
  • Birthday 12/15/1957

Profile Information

  • Gender
  • Location
    Bessemer, MI, USA
  • Interests
    3D Web, CSS, HTML, Guitars, NORML, storytelling

Recent Profile Visitors

7,255 profile views
  1. Wingnut

    Pick a point in the space with mouse.

    Remember that ALL your mesh could have actionManagers listening for picks. So, think about... ANY click that didn't pickResult.hit, or trigger a mesh.actionManager... MUST have been a click in space. We don't need an invisible plane.... IF we can eliminate all other possibilities. If all mesh have actionManagers, and none of them triggered... it HAD TO BE a "miss". So, you can run a function such as... var onMiss = function() { var whereMiss = new BABYLON.Vector2(scene.pointerX, scene.pointerY); console.log(whereMiss); } When you have this "where was the pointer on the screen at time of click-miss" value... things can be done with it. I BELIEVE one operation is called "unproject()"... which sort-of backwards-projects an imaginary line (a direction vector)... from the center of the camera, THROUGH that chosen screen X/Y... and you can use that to position mesh in "space" (along that projected line). Or maybe that is called "project". (You'll need to read about it). Still, you need SOME way of determining HOW FAR along Z-depth to place it (how far from camera). Not only that, but camera can be turned... so that could cause trouble. Maybe not. And don't forget that an actionManager is allowed on the scene object. I think we saw one used in one of the above playgrounds. I'm not sure if THAT can test for "click happened without hitting anything", but it might be worth study. Anyway, I figured I'd better tell you about the handy, constantly-updated... scene.pointerX and scene.pointerY properties. If you put an actionManager with click-test on EACH mesh... then you can use these two properties to determine screen X/Y location of clicks that missed all mesh. You don't need to use pickResults or hit checks... at all. I am not experienced in 'unproject', but a forum search about it... looks good. I dunno if any of these ideas are wise or useful... just passing along what little I know. Heck, let's try a playground search for 'unproject', too. That returns a few hits. Others are far more qualified to talk about projections... than I. Perhaps they will tell us what they know, soon. Stay tuned, party on.
  2. Wingnut

    Pick a point in the space with mouse.

    Hi DB. Yeah, I was thinking something similar. Perhaps hold-down the click, and then roll mousewheel... for depth-adjusting (mostly for positioning new mesh or "space markers"). I think many new users of BJS... want to "assemble". Although the BJS Editor is nice, sometimes it seems... that mesh could use a "snap-on GUI"... perhaps .guiManager. Add one, activate it, and very nice menu with arrow-buttons and readouts... happens somewhere on-screen. You never really drag a mesh to new positions or rotations, but you use the GUI panel buttons to move/rotate the mesh. In this way, the mesh sort-of carries-around its own editor. We're still positioning via pointer/clicks, just... not dragging. Instead, MeshMenu v1.0. *shrug* Later, with add "snap" Likely, somebody has already built it. I think I once made a right-click-on-mesh pop-open menu (context menu)... but I did it using Canvas2d. Newer GUI system can handle it fine, too. RIght-click to pop-open a mesh's "personal editor"? Sounds ok, eh? Really, the GUI/funcs in my goofy space-flyer playground... is a pretty good start. It has 6 buttons for rotate, 6 buttons for position, but needs 6 more buttons for scaling. Use symbols on the buttons, instead of text... and you should be able to shrink the 18+ button menu... to 15% x 15% screen space (3 inches by 3 inches). Have that pop-open under a mesh... when the mesh is right-clicked. Nice. Maybe allow the readouts to also be inputs... let users type-in numbers. Same things that dbawel speaks-of... only 1500% overkill added, and never used by anyone.
  3. Wingnut

    Pick a point in the space with mouse.

    Hi guys! Welcome, Tomek. Cool invisible-plane click-in-space solution, Deltakosh! I took it a few steps further. Watch the JS console to try to learn what is happening. I made Deltakosh's invisible plane... a LITTLE BIT visible... and textured some bricks on it. I also parented the wall... to the camera. Line 24. I put actionManagers on the red, green, and blue boxes... each with pick-triggers and executeCode-actions. I am testing IF/NOT we can pick the colored boxes... THROUGH the (almost-) invisible brick wall. So far, no. I think it might need "multi-pick" to do that... which IS an available feature. More about that, below. In current condition, picking red, blue, or green boxes... reports a WALL HIT at the console. The "pick" cannot travel thru the wall... to hit the boxes behind the wall. You can change '30' to '60' in line 25, and that will move the invisible wall BEHIND the colored boxes. THEN... picking red, green, or blue (using their actionManagers)... works fine. ---------------- In this demo, wall is larger and farther-back (line 25), yet still parented to camera. Picks work on invisible wall (distances over 100), yet ALSO work on red, blue, and green actionManagers. Anyway, these are just some things to think-about and experiment-with. Selecting things, and positioning 3d cross-hairs/reticles... can be challenging. --------------- With 'multi-pick'... things change a bit: See the 'multipick' in line 84. Line 85 reports ALL the mesh that were hit. So, a click in the center... reports 4 mesh (in an array) at the console. (The little white cursor box is set isPickable = false, so it is not included.) In versions #13/#14, the pickResult object had many cool properties, like .pickedMesh and .pickedPoint and .distance. Conversely, the pickResult returned from a multi-pick... is only a simple array of ALL the mesh that were hit. No cool properties and no automatic distance, but SOME values can be calculated/measured. Getting a .pickedPoint for each returned mesh... will be difficult, though. The multipick's pickResult only contains the "hit mesh"... and no information about WHERE they were hit. TMI, eh? *nod*. In general, there are many ways to get the screen X/Y position of a click/pick. It is not so easy to determine the Z-depth when clicking in "empty space". Deltakosh installed the invisible plane... to show that "clicking in space" needs to hit SOMETHING, or else it won't be "seen" as a pick/click. But using invisible planes for "space clicks"... has some "block clicks upon other mesh" -issues that need to be understood. In many cases, the invisible "space-plane"... needs to be behind all other scene mesh. Ok, we have plenty of playgrounds to experiment-with. Good luck! Tell us of your progress and/or problems. We're here to help. Be patient with yourself. Soon, you will be an expert. Sorry for all the talking... I hope I have been helpful. PS: 'Collisions' are not really a mouse-pointer thing. They are mesh-to-mesh and freeCamera-to-mesh intersection testing/systems. But, that was some very intuitive thinking. 'Collision' is indeed a term that COULD apply to pointer hits, eh? Not in BabylonJS, though.
  4. Hi girls. A little update on the SKAP tumble-recovery auto-pilot, as well as the new automatic "orient" auto-pilot. (skap - station-keeping auto-pilot) (tumble-recovery) Just RUN it and relax. Spacecraft is auto-tumbled, and SKAP func (lines 1318-1371) auto-activates after 3 seconds. It uses a combination of throttled thrusting, and a tiny bit (more) of physicsBody angularDamping. So far, I have not seen the SKAP phase fail. You can watch the av: numbers (angular velocity) as the skap "grinds" those numbers toward low magnitude values. When SKAP reaches a reasonable threshold of tumble-recovery... it shuts off. 3 seconds later, auto-orient activates... thrusting the spacecraft toward 0,0,0 on the erot (euler rotation) and qrot (quaternion rotation) values. It takes a while, and it is NOT perfect. But, if I ask it to be MORE perfect-resulting, it takes even LONGER. So, it's a trade-off. Most astro-crews probably don't care if they have a tiny bit of angular drift... at the end of a short auto-orient function. It seems to work pretty well, but SKAP phase COULD still fail... sometimes. It's "on the fence" Maybe that's part of the fun of the game. SKAP failures happen when the craft is ALMOST PERFECTLY done spinning... but then the av numbers start increasing again. I have not figured out WHY that happens. But, all in all, I can programmatically "watch for" indications of a SKAP about to start failing, and have it shut-off the SKAP immediately (prevent craft from slowly re-entering violent tumble again). I am still in search of the reason WHY SKAP failures happen. I think you can promote more SKAP failures... if you remove line 1351, and increase amp in line 1337... to perhaps 15 or 20. At a certain point of slow angular velocity and low rotation, the whole thing reverses... and my thrusters appear to start INCREASING angular velocity, going against their code logic. Interesting note (yeeeah): If I see the av: numbers start increasing, and manually shut-off the SKAP (by clicking any SKAP button)... then wait a few seconds, and click a SKAP button again (to re-start SKAP)... the "backwards-ness" is STILL there. The SKAP thrusting starts increasing the tumble speed. Bad, bad, bad. I wonder what causes this "suddenly, all my thrusters work backwards" problem. hmm. See lines 130-138? It's a cool little function that DK showed me. What it does... is calculate the very-current rotation/orientation of the craft. EVERY TIME I generate a physics translation impulse, or two rotation impulses (I "twist" the craft with 2 opposed'n'offset physics impulses... to cause a rotation thrust)... this function gets called. EVERY thrust pulsing! I dunno IF or WHY this function would/could "invert"... where it starts doing everything in the opposite direction... but that's my best suspect so far. SKAP works just fine... thru its "coarse" phase... counter-thrusting almost all angularVelocity magnitudes... using only thrusters and EVEN with UN-throttled thrusters. I hate (highly-dislike) setting/varying throttle values on the thrusters. It seems like cheating. By initial design, they are supposed-to always thrust at the same set power. But noooo. Ex: Line 1344... the Math.abs(av.z*amp) portion... is a thruster throttle-setting value. (Wingy pokes it with a stick and hopes it will leave). It should probably be Math.abs(av.z)*amp, too, but I guess that doesn't matter. ANYWAY... when the SKAP starts working on the "vernier" phase... the little-thrustings.... the final tweaks... THAT'S when I see the SKAP sometimes start failing. Most/all the av: numbers start increasing instead-of decreasing. SO, this persistent and annoying "thrusters suddenly start working opposite when av values get low" -problem... is still a huge issue and a major puzzle. All help welcome. Thx. Click here for 2 meg .zip of entire box-flyer package - no keypress observers - no spacecraft model attached. Meantime, I think I'll start working on linearVelocity SKAP now... when the craft is changing position at an insane rate. Just possibly, I will need to ensure the craft is NOT TUMBLING... before I can begin counter-thrusting the unwanted translation. So, rot-skap first (but maybe no auto-orient needed)... and then lin-skap. Then orient. Complete vehicle insanity-recovery. It's not like any of us would EVER pilot a spacecraft... in a way that would cause it to tumble violently thru space, right? Nah. Update: #295 is ready. PG starts with craft tumbling and translating uncontrolled. Click 'Rot Skap' and wait until that is finished. After that, you can click Trans Skap or Orient in any order, and maybe at the same time. Do Rot SKAP first, because Trans SKAP does not work well... while craft is tumbling. All 3 buttons are toggles. Old 'null rot' and 'null trans' buttons are still active... for instant-stop, as wanted. Trans-SKAP is brand new... and fails often... same problem as rot SKAP... thrusters sometimes operate in wrong direction. Still testing.
  5. Wingnut

    Possible Playground FragID issue

    Hi gang! I THINK I am seeing the playground increase the fragment identifier +2 each save. In other words... save once... #65. Save again, #67. Again, #69. Might need checking. thx.
  6. Wingnut

    Text as polygon mesh

    That shader code was stolen from the amazing CYOS (create your own shader) editor... Default shader for CYOS. Ain't fake-chrome PRETTY? I used the ZIP option in CYOS, to insert that shader code into a giant string, and bring it home. Then I took the shader-code string and inserted it into a playground... for use in the BJS ShadersStore-method of storing shader code (which is the same method that the zip from CYOS uses). I think there are about 3-4 other ways to store shader code. One, is within files. Another... within an HTML script element, and also ShaderBuilder can store it in JS... in little pieces/values... and assemble/compile it at scene run-time or whenever needed. I THINK... a more-standard reflection-texture can be used instead-of a shader, and can look/act exactly the same chrome-like way... IF we correctly set the reflection-texture parameters, and maybe the texture's "coordinatesMode". But also... I think the "addressMode" used for texture wrapU, wrapV, and wrapR... is pertinent, too. In THIS effect, the reflection is mega-important. These advanced texture settings... aren't well-understood by noobs like me. We probably need a PBT (playground-based tutorial) to teach these advanced texture things. uv(w) offsets, scales, angs, wraps, and coordinatesModes... the big 5 "weird" texture knobs. Wraps and coordinatesModes... being the weirdest. Those 2 set which part of the texture to clamp (glue) to which part of the mesh, and which areas are allowed to stretch or compress, as best I know/can explain. The mesh's UVs are involved, too, if they are present. Yep, these meshWriter fonts/words/sentences... have a whole lot of reflection experiments that need to be performed/tested. Add-in another camera used to generate a renderTargetTexture (rtt)... put chrome words in front of it, and then use ITS texture on a different single-word mesh! OMG! For example... a child learning a word. The word sits in front of them... in big fat fonts... and in the reflection of the word's texture.... sentences are slowly scrolling-thru... showing the word properly used in example sentences. SO COOOOOOL! Further down the line... I believe .moveWithCollisions() works on letter shapes. Sooo... letters of a word... can bump into each other, and that can open-up a whole new world. AND... Jerome has basic SPS collisions already happening somewhat... without a physics engine (actually, with his own basic SPS physics engine). And there's scaling... making each letter of a word or word of a sentence... go squatty'n'wide, then tall'n'thin, back and forth, as it bounces along on the rolling plains. Nice. There's some serious (comedy) options for making text dance and sing, here. In a way, we are talking about meshWriter "behaviors" here, similar to camera behaviors. Or perhaps... array-of-mesh behaviors. For example... scale wide and squatty, then scale tall and thin, back and forth at some rate and some limits... is a "behavior" that can work on ANY array of mesh, not only a "group" of meshWriter characters or words. Many of @jerome's demented SPS experiments... could be considered SPS "behaviors", too, yes? It really depends upon how flexible we want to be... with the term/definition of a "behavior". So... we probably need to think about IF/NOT... meshWriter behaviors... and general array-of-mesh behaviors... are the same thing. Or... AT LEAST the two things might inherit from the same base class... should we decide to try array-of-mesh behaviors AT ALL. In a way, this is "advanced choreography", which will LIKELY involve the BJS animation system, AND might also apply to array-of-lights and to cameras, too. Scene.actionManager.choreographyManager ... v1.0 Not used too often for games, but instead... for shows and mesh parades.
  7. Wingnut

    Text as polygon mesh

    Thx TL! Hey, mapping textures... In that one... I changed the .xyz in line 91... to be .zyx ! The other value remains 0.0. (That 0.0 seems like a scaler, to me. Stretches stuff.) Whatever it did... the chrome looks much more nipple-free. Wow, we can really abuse this Purina GPU-chow. Them critters will eat ANYTHING! The objective here... is to get a picture of a fire truck or stage coach or something... to pass across the face of the word... as the word or camera does a slow rotation/pan. THAT... would win us the CNET Artificial-Chrome Reflect-Master-of-the-Year Award, for sure. Hands down. For best effect, the fonts need to be REAL big and blocky, lots of facial surface area... not much empty space, absolute minimum kern between letters. Lots of surface, so the fire truck picture has good clarity as it passes across the word. Yet the fonts must not be SO fat as to make the word difficult to read. An artistic balancing act. Got some really fat font-sets... earmarked for meshWriter, someday, TL? It's only miserable hand-tweaking work, TL... no biggie, right? (ahem) (sorry) And yeah, I know... fat fonts, low kern, possibility of SPS letter-over-lapping increases. But, as you can see.... for THIS effect, the more word/font surface-area, the clearer the reflected picture. *shrug* Thoughts?
  8. Wingnut

    Text as polygon mesh Oooo, my "u" has a tumor! hmm. He grew a tail. Can ya help with this, TL? (thx) ------------ Hi thread-watchers! Hey... we (I) still have "that other issue"... with the texture mapped-onto the text... oddly (in the fake-chrome shader thing). See how we are looking-at the "nipple" of the texture... when we have our cam aimed +Z-ward? (like all good cams should aim.) We are looking at the BUTT-END of the kielbasa, where the sausage casing is tied-off. (sausage = texture) Does anyone know how to map the lateral SIDE of the sausage... across the word's "faces"? If you pan the camera around the mesh, you can see that there is a texture "nipple"/spincter... in the end-faces of the mesh, too, and in the center of the back side. I think it needs a u or v offset of about 50%. Probably vOffset. (see note below about meshWriter fonts' default orientation) I dunno how to do a vOffset with this fancy shader texture. Anyone know how? I'd use it. (thx) Note: Keep in mind that these meshWriter/SPS mesh... are laying on their backs... on the floor, by default. They start... napping. Could THAT affect why I see texture-nipples (poles) in the center of every mesh face? I think it is related-to the issue. It's as-if... when I tip-up the mesh, the texture doesn't come-along. It doesn't tip-up WITH the mesh. It is not supposed to tip-up WITH the mesh, but still, I need to tip it-up... just once. Actually, I need to tell the texture to map-onto the mesh with a 50% vOffset... from the start. Or, I could leave the mesh lay on their backs, move the camera to -Y aim (overhead), and work from there. But that sucks. Words need to be ON THEIR FEET when they stampede across the rolling heightMaps of the western plains. Help welcome! Extra: In PG #57, change '0.0' in line 91... to 1.0 ...does SOMETHING. Texture nipple not in center of word anymore. Hmm. Wingnut with shader code == child with power tools... erf. Oh well... line 91 seems like a good point of demented shader experimenting, for sure. :)
  9. Wingnut

    multiple mesh models

    haha. That sounds SO goofy, but true. I guess... what? Slowly rotate each mesh, and it's easier to see offset-distances of vert positions... from mesh 0,0,0 origin. Likely, the point-of-pivot will NOT be in the center of the actual mesh-"volume" (on certain layer-mesh). I think there is a way to set the mesh origin to a more bounding-box-centered position. Some setPivotPoint or setPivotMatrix BJS feature. Here, I found this, somewhere: mesh.setPivotMatrix(BABYLON.Matrix.Identity()); mesh.makeGeometryUnique(); mesh.setPivotPoint(mesh.getBoundingInfo().boundingBox.centerWorld, BABYLON.Space.WORLD); I dunno what that stuff does, but it's fun to experiment-with. I hear makeGeometryUnique() ensures that pivot point changes happen on THIS mesh only, and NOT its parent. Clones are also involved, and possibly instances. Forum search for 'makeGeometryUnique' == good idea. Ok, that's enough Wingnut interrupting/yammering for THIS post. Party on!
  10. Hi F! Welcome. Umm... wow, that's a tough challenge, as best I can tell. I built a testing playground... using a 6-plane box, with a skybox inside. It ALMOST looks like I have the skybox hidden inside a transparent standard box, eh? But nooooooo. This is a black box with no transparency. (I change the scene background color to blue, after the door finishes opening - to reveal the foolery.) So, I failed, so far. But, I made a testing playground. This might be a GPU and/or a "layers" thing. A forum search for "augmented reality" might be wise. Stay tuned for more/better comments.
  11. Yay! (Read recent older posts in this thread... to catch-up with "the story", as needed.) Just RUN it, box (spacecraft) is automatically randomly tumbled. 3 seconds later, the station-keeping auto-pilot (SKAP) turns on, and you can see the thrusters go to work. Watch the AV: numbers (angular velocity). Larger numbers... reduce faster, smaller numbers... reduce slower. More on that, below. So far, it does successful tumble-recovery ALMOST every attempt (It takes a while, though... dependent upon amp power-scaler variable - line 1332.) When the SKAP has attained station-keeping (tumble-recovery)... it automatically shuts off. Lines 1330-1355 is where the fun is at. For those who are following closely and wanting to know the technical mods so-far (nobody)... if (av.x > maxResidual) { bobsled.controller.rotNegativeX(Math.abs(av.x*amp)) }; if (av.x < -maxResidual) { bobsled.controller.rotPositiveX(Math.abs(av.x*amp)) }; if (av.y > maxResidual) { bobsled.controller.rotNegativeY(Math.abs(av.y*amp)) }; if (av.y < -maxResidual) { bobsled.controller.rotPositiveY(Math.abs(av.y*amp)) }; if (av.z > maxResidual) { bobsled.controller.rotNegativeZ(Math.abs(av.z*amp)) }; if (av.z < -maxResidual) { bobsled.controller.rotPositiveZ(Math.abs(av.z*amp)) }; While SKAP is active, this section gets run every 1/3 second. Feel free to adjust that "thrustActionManager" polling-rate... in line 1381. Triggers and actions, and rates of checking. I wonder what the polling-rate is... for BJS observers. I suppose that depends upon how many of them... are triggered and need actions (seeing we're not multi-threaded). Power scaler: I added a parameter/feature to my 6 thruster funcs... amount of power (throttle setting). Variable throttle settings on thrusters was NOT part of original intended flyer design. Var amp is just a scaler/amplifier... multiplies all thrust-forces by 15, currently. (yawn) What this does... is counter-thrust MORE... on axes with LOTS of spinning, and counter-thrust LESS... on slower-spinning axes. (no matter spin-direction) In other words, doing this... attempts to "equalize" the spin on all 3 axes. It slowly tries to make all three axes spin at the same velocity (without accelerating the spin on ANY axes). This has somewhat reduced the "overshoot" problem I had with rotational SKAP in earlier versions. Translational SKAP (linearVelocity) will probably use the same method. I will counter-thrust hardest.... against the axes with the most velocity. I'll counter-thrust less... on axes with lower absolute velocity values. Phew, I'm glad I'm finally making some progress (but maybe not - see below). It's nice to see rot-skap work fairly-consistently. Feel free to adjust the values in lines 1332, 1333, 1381, then re-RUN, and watch the tumble-recovery system... change characteristics. I HAVE seen some fails, though, so, I'm still worried (experimenting with amp = 20 and maxResidual = .01). Same crap... a type of "overshoot" of station-keeping - an "almost". After overshoot/fail happens, thrusters act like they are reversed, and ADD TO the spin velocities. Not sure why, yet. A tough puzzle to solve! If I solve/fix WHY the thrusters act backwards (after over-shoot/failed SK), then the future SKAP will auto-compensate for any overshoot issues. That's what it is supposed to do. If the numbers in the av: start increasing, the SKAP should grind them down... no matter what. Currently, after over-shoot/fail, the numbers keep going up and the spin goes crazy. In a way, this "thrusters-with-throttles"-solution is "illegal". The thrusters on the flyer were never intended to have on-the-fly variable thrust force (throttle). They are supposed to have a SET pulse power. And each is either ON (single-pulse or held-button pulse-repeating), or OFF. Soooo... hmm. The NEW solution... would be to adjust the length of TIME a thruster "runs" (pulse-repeats)... based upon the amount (severity/magnitude) of tumble (angularVelocity) on each axes. hmm. Faster-spinning axes... get longer-run-time counter-thrusting. How the heck would I do THAT? Also, any GOOD space engineer would NOT counter-thrust HARD against the fastest-spinning axis (...of a tumbling spacecraft). IF ANYTHING... the fastest spinning axis would get the most-gentle counter-thrusting... and enjoy a "take your time"-attitude in bringing that fast-spinning axis to a stop. That's the opposite of what I am doing. *sigh* I have work to do. In real-life spacecraft, and depending-upon mass and thrust-power, it is possible that an auto-pilot tumble-recovery... for a severely-tumbling spacecraft... could take an hour or a half-day. If it is a spacecraft with a crew, there will be lots of vomit to clean-up, when station-keeping is attained.
  12. Hi O! We probably need highlight-professor @Sebavan to help us with this. Other pros are nearby, too. I did some testing with your playground (thx for providing a good one to test-with). No solutions, yet. Just tests. Thx for the report! It is an interesting issue-find. hmm. Stay tuned. :)
  13. Wingnut

    Swapping texture issue

    Just create an extra plane in your scene... basic BabylonJS... Then set ITS material as that PBR material you are experimenting-with. See if you can make eyeballs appear on the extra plane. IF/WHEN you DO, does the eyeball appear in the center of the plane? Or, maybe in one corner? const changeEyeColor = function(e) { scene.meshes[2].material.albedoTexture.dispose(); scene.meshes[2].material.albedoTexture = new BABYLON.Texture("eye2.png", scene); var plane = BABYLON.Mesh.CreatePlane("plane", 120, scene); plane.rotation.x = Math.PI / 2; plane.material = scene.meshes[2].material; } That should work... for testing. After calling this func, look at the plane carefully to see if you can see the eye. You might need to light the plane. Good luck.
  14. Wingnut

    Swapping texture issue

    No need to swap material. Try... putting the exact same material.... on a plane. Does the iris show on the plane? Could the iris part of of the texture... be offset (slid sideways)? You will know when you put the same material on a plane. It might be easier to see the iris, then. Is NEW texture... same dimensions as old texture? Might need some new-Texture .uOffset and .vOffset adjustments (slide the texture left/right and up/down on the material), and perhaps some .uScale and .vScale adjustments (adjust height/width of texture). By putting the same material on an extra plane... you/we might learn more.
  15. Wingnut

    Swapping texture issue

    Hiya FTP. Nothing learned, yet. Just trying some test code in lines 84-89. Seems to work, so far. After 6 seconds, albedoTexture on wood... changes. Can you reproduce your issue... in a playground scene? That would make life easier for helpers. And, of course, add lots of console.log(whatever)... such as: console.log(scene.meshes[2]); console.log(scene.meshes[2].material); console.log(scene.meshes[2].material.albedoTexture); etc, etc. Make sure everything exsits and is as-expected. You might also try wrapping it all in a JS try/catch. Just some ideas. *shrug* Other/better answers might be coming soon.