• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. Oh, thx dk. Ahh yeah, adam... hero to all ages... good coder, good thinker. Adam has made a GUI control, huh? *sigh* That rotten son of a guy is SUCH a hero of mine! I wonder if he has the only "outsider"-written GUI control so far. Bet so. Anyone remember when I was mapping ADT's onto spheres to create those round gauges/meters? Well... you know... "painting" arcs/circles (math stuff) is probably a much wiser way to make a circular meter... than... you know... Why am I still talking? Oh yeah... round-shaped GUI controls (with dragable center dot). hmm.
  2. Wow, look how similar a Babylon GUI Colorpicker is... to being your wanted ipod circle. ALL of it... is similar to a thing called a virtualJoystick. It is/was a drag-able touchscreen controller... graphical rings on the screen... drag them with your thumbs on a portable device. I wonder... if we bought @Deltakosh a new speedboat or something... maybe he would down-"hack" his colorpicker... into being an ipod circular center-draggable "thing". He's a great coder and darned nice guy, but this is a rather large request. 4 compass-point buttons around a drag-able center dot. Optional 4 more buttons (northwest, northeast, southwest, southeast). Back-lit, for easy nighttime usage. Wha-da-ya-say, Delta? (or any other coding madman) Have you the time/energy to make a GUI ipod 'thing'? Custom GUI controls. sigh. Look at those cool circles in that colorpicker. I put the colorpicker code... into the PG (remmed-out cuz I couldn't get it to activate successfully, yet) Sigh. A REAL MAN... could make a GUI ipod controller-pad... from pieces/parts of the colorpicker code. (a REAL man). Unfortunately, Wingnut is a scared man. But but but but... doncha think that an ipod control... would be a useful new GUI control and possibly be the basis for Babylon VirtualJoysticks v.7.0? Huh? Have we got ANY GUI virtual joysticks? Maybe they went obsolete. A reminder, Vikk. The virtual joysticks from the old days... are not like my red joystick. They are/were more like what YOU want... a drag-thing to control camera movement/navigation. They used an annoying extra canvas layer. Maybe they still exist. Let's hope not. For ME to modify colorpicker until it became the new ipod-like control... would take about 3 months, I predict. Ow. But... colorpicker sure is a nice, pretty, drag-able GUI controller, eh? VR headset-ready. But but but 2.0... an ipod controller COULD be "pieced together" from the currently-available GUI controls, and work just fine. I know it. So... THAT route could be taken, too... without the need to invent a brand new GUI control. hmm.
  3. Hey CB, congrats on having the longest thread title EVER. Let's see... about 7-8 secs for 200 ADT's? Actually, that's probably expected, considering the amount of work/code/measurements it takes to create an ADT for each mesh. Have you tried adding all 200 textLabel to a SINGLE full-screen ADT, and then using textLabel.linkWithMesh for each? Can you give me a report on your speeds... using THAT method? (thx)
  4. MEANTIME... for fun... let's look at my renderLoop at line 127 of the red joystick demo: scene.beforeRender = function() { animationRatio = scene.getAnimationRatio(); // the same speed all devices subRight = sub.getDirection(BABYLON.Vector3.Right()); subForward = sub.getDirection(BABYLON.Vector3.Forward()); sub.position.addInPlace(subRight.scaleInPlace(-xspeed * animationRatio)); sub.position.addInPlace(subForward.scaleInPlace(zspeed * animationRatio)); if (!stickInUse) { if (xspeed > 0) xspeed -= rampdown; if (xspeed < 0) xspeed += rampdown; if (zspeed > 0) zspeed -= rampdown; if (zspeed < 0) zspeed += rampdown; } } This is similar to the renderLoop YOU will use for your camera mover. See the green lines? Pretend you have changed each 'sub' to 'camera'. camera.position.addInPlace(cameraRight.scaleInPlace(-xspeed * animationRatio)); camera.position.addInPlace(cameraForward.scaleInPlace(zspeed * animationRatio)); renderLoops run continuously. The green lines run CONSTANTLY. When joystick is centered/unused, xspeed and zspeed == 0. SO, there is no camera movement, even though these two positioning lines are always running. Perhaps you can fix your issue more quickly than my slow work. xspeed would be the amount of left/right movement of inner circle. zspeed would be amount of forward/backward movement of inner circle. Right now, the submarine only goes worldspace forward/backward/left/right. It doesn't allow turning/rotation. But take a quick look at THIS PG that satGuru helped me with: First, let's see what the 'wingnut crap' does. You can turn this free camera in ANY direction, and then use mousewheel to go forward/backward along the z-axis. Line 31 is the code that gets the current camera Z-direction. Mousewheel moves camera in camera's Z direction (in camera space, not world space), no matter which direction camera is aimed. Good, right? You want your yellow circle to do the same, right? Go forward/backward along camera aiming direction, yes? Let's make some changes... try to find camera X direction for left/right moving. In lines 31/32, I have made BOTH camera directions... Z and X. In lines 35 and 37, I am using dirX instead-of dirZ. Try the mousewheel. Again, no matter which direction the camera is aimed... camera still moves perfectly left/right (in camera space, not world space). This is what you want your yellow circle to do... when dragged left/right, too, right? @satguru's lines 35 and 37 uses the very same .addInPlace as our two green lines above, eh? So... your renderLoop for your camera mover... will likely also contain two lines like 31 and 32... which are camera directionX and directionZ getters. This is so we can move your camera along camera-space X and camera-space Z, instead of worldspace x and worldspace z. Anyway, I thought I would show you these things, and perhaps... you would have enough "stuff" to fix your issue yourself... without waiting for my slow testings and jQuery problems. xspeed and zspeed can be positive or negative... no problems. Your yellow circular touchpad values can do the same. When dragged down, it can produce negative z values. When dragged up... positive z values. When dragged left... negative x values. When dragged right... positive x values. The secret is... constantly TRYING to move the camera... in the renderLoop (whenever an Xvalue or Zvalue is produced by the yellow circle drag). I will keep working on the playground version... hopefully with help from jQuery pros. You, my friend, now have everything you need to fix your own issue... if you wish. You might be able to do it faster than I. Good luck, if you try it. Sorry for long post. Update: Just for MORE fun, let's try a camera-mover renderLoop (lines 118-139) on our red joystick. Works ok, eh? We simply "feed" the beforeRender func... a positive or negative xspeed, and a positive or negative zspeed. My "rampdown system" isn't working perfectly, so you might see a little camera "drift" after joystick is released. But... this beforeRender function is essentially the same one you will use. It is constantly watching-for changing xspeed and zspeed values, and adding them to the camera position. If you can make your yellow circle... produce some xspeed and zspeed values, you are ALMOST done/fixed, yes? Good luck. May your horse be with you.
  5. Wingnut having troubles with .draggable. I'm not very good at jQuery. In your code, you are using a variable called 'ui'. I don't think I have that available in playground, so I just set it empty in line 162. Also, I changed #inner to #innerpad ... no big deal. Also, changed the document/scene isReady method... WAS line 165, now line 166. No biggie. Watch JS console. Line 167 working fine, line 169 working fine, but line 179 is dead. (see error dump in console). .draggable is not function. I'm not sure why it is broken, but I will keep working. Help from anyone... highly welcomed.
  6. Scale mesh during velocity

    Hi kraftwer1. Welcome aboard. Hi everyone else, too. Do you need smooth-scaling, krafty? Must the scaling be gentle, or can it be in distinct steps? Anyway, I had to experiment. Currently, the small gray ibox and its impostor... is attached via joint1... to the green player box/impostor. ibox does the moving, and green box is joint-dragged-along via forces passed-thru the joint. You can use up/down arrow keys to move the ibox along z-axis. (x-axis moving also works, but auto-scaling is not yet programmed for that axis). You can also turn-on auto-velocity by enabling the code in lines 93-102. The manual-moving is done in lines 116-136. Right now, I am NOT copying the linear and angular velocity from previous impostor... to the new impostor that gets installed automatically after a physics-active shape... gets scaled. Instead... I re-add the joint that connects ibox and green player - in lines 123 and 134. It works... sort-of ok. You can re-activate the oldImp->newImp velocities-copying... by activating lines 118-119, 121-122, 129-130, and 132-133. This makes things act a little differently for manual-moving. Remember that when a physics-active mesh is scaled, our plugins (actually, our physicsImpostor wrapper-code) automatically disposes the old impostor, and adds a new one. (it's called a forceUpdate, I believe.) You can see that activity... in this area of our physicsImpostor wrapper: It is a feature, and is the only way to make a rigid body act any-what "sane" after a scaling. It CAN be disabled via hacking the wrapper (over-riding some/all of our wrapper), but after that... troubles/challenges. But still, it would be a cool adventure. Your physicsBODY really needs to change from rigid, to dynamic. A gruesome challenge. No indication of allowed rigidBody scaling features.... is seen in either of the 3rd party physics engines. But, if you want to "go deep" and "go native" (dive UNDER our physics plugins/wrappers)... you might be able to use dynamic/soft bodies. I'm sure not qualified to talk about that stuff. I just make goofy playgrounds. Speak of which... In THAT playground, the entire BJS physicsImpostor wrapper/class has been "hijacked" into the playground (for hacking fun). Wow, huh? Around line 213... perhaps adjust-to: if (this.shape != player) { this.forceUpdate() } // tweak as needed. That would prevent a shape scaling... from disposing old impostor. But that would be only the START of the needed hacking to convert from a CannonJS rigidBody... to a dynamicBody. Greasy deep hacking. I hope this has been helpful, and I hope I didn't say any incorrect things.
  7. Oh is that right? Sorry. Well, I can't seem to determine HOW the yellow circle gets its position dragged-around, speak nothing of trying to get it active in the playground. (I'm not the smartest guy in the world, though... sorry). Can you help me with the yellow circle/square in the middle? Can you show me how to make it drag-move and produce values based-upon its position? Maybe others have ideas. I need that dragging to produce values, just like my non-DOM red joystick does. After I get the yellow circle (yellow square in my PG demo) to drag-position and return usable values to me, THEN I can try to use those values to move a camera. What I would do if I were you is... use BabylonJS GUI system... to create the keypad. Even then, I'm not sure that I can drag-around the yellow circle... unless we make it be a sprite. But... there IS paddingLeft and paddingTop on BabylonJS GUI controls, and a markAsDirty() which has been seen doing live-updating of AdvancedDynamicTextures (the basis of BabylonJS GUI). Would you entertain the idea of switching to non-DOM buttons on the keypad? If we do this, the GUI becomes usable for VR headgear, too. Conversely, if you use a DOM version of the keypad, VR headgear folk won't be able to see/use it. Thoughts? (from anyone/everyone, please)
  8. I think that's where that draggable yellow circle is done. I don't foresee me being able to reproduce that in the playground. Sorry. It would take me forever to learn jquery-ui. Perhaps there are others in the forum that have experience with jQuery UI that can help.
  9. Absolute positioning

    Hey, congrats, Topper! I did a little indent-adjusting on #25... so I could more-easily see your work. Your scene looks great. Nice work. I bookmarked its URL.
  10. Where are stored advancedDynamicTexture ?

    AdvancedDynamicTextures (ADT) have a cool .level property, too, just like ALL textures. It is like a brightness knob. Default is 1.0. Lots of people forget it exists. Great for fade-in and fade-out GUI.
  11. Yay, sparticles (sparkly particles) are working again. (Wingy dances around like a chicken). There was a little bug that DeltaFlyer fixed for us. Another, you say? (Recently updated to utilize the new non-offsetting setPivotMatrix feature.) (might be memory-leaky or somehow CPU-heavy) Fireworks junkies. That's what I and all glitter-addicts... really are. I love fireworks. Another one? Ok. 6-planes with PS emitbox covering entire plane, and using very short maxLifetime. PS sequences thru all 6 emitters, constantly. Activate line 185 to "freeze" the particles after 3 seconds. Fun stuff. Okay, time to get to work. In our last episode, we put a picture inside the GUI fonts... We also did some VERY SLOW color speckles inside the fonts. The real fun... is in mixing "sparticles"... with the GUI. Here is my first attempt. Just a plane-shaped 'emitBox" behind our message... I am still too scared to try repeatedly-painting a renderTargetTexture of the panel-o-sparticles... INSIDE the fonts. But a guy COULD (i think)! Back to our image of water rings... INSIDE the fonts. This time, I have turned-on line 304... which makes the image paint into the fonts over and over. Look at the frame rates. Pretty muddy, eh? *nod* Subtract another 10%, and we can predict the frame rate... IF we ever decided to grab the sparticles panel into a renderTargetTexture, and use THAT as our ANIMATED inside-the-fonts image. Sparticles... INSIDE THE FONTS! How cool would that be? Perhaps I don't care HOW SLOW that would be, I may need to see it done... out of pure curiosity. So, who is a pro at renderTargetTextures? Are there OTHER ways of showing the sparticles (sparkly particles) from PG#60... INSIDE the fonts ONLY? Layermasking or renderGroups or blendingModes or some other complicated thing? I would LOVE to see fully-animated sparticles... INSIDE the font volumes. Anyone want to try it? (please). I need to woof a bowl of Ralston and go do some snowblowing. We got a little snow last night, and the mailperson paths and driveway... need cleaning. Ahh, thank goodness spring is near. Snow is fun, but sometimes it lasts too many months. Snowblow on!
  12. Hi gang! Newbie Wingnut here again, hope everyone is well. Here begins a massive "chronicle" of "Stupid Stuff That Wingnut Talks About". It will get big and stale, but what the heck. I goof around in 3dMax a bit, and I've seen their massive 'library' of procedural primitives/shapes, and one would think that BJS is destined to have every one of those, plus a few hundred more. Thoughts, anyone? Thanks!
  13. CellShading post-process

    Ahh, that explains a lot. Good. You're probably going to be ok, then. Yeah, Naz has Shaderitis... a disease that affects people when they start understanding shaders. The whole world is worried about Naz, but he's pretty much a genius. Scary-level intelligence. Pisses me off. (just kidding, I love the guy and want him as my next-door neighbor) Cell shading... pretty cool effect. I PG'd the cell shading demo from the main website. I haven't tried to adjust/fix the texture paths, yet. Not sure how to do that. Let's see, if I may re-state the issue, Dad72 wants to have ONE cellshading post-process... but it "effects" all materials in-scene, and perhaps optional .includedMaterials array. Is that correct, Dad72? Fix me as needed. Yesterday... I was thinking that MAYBE... this is a camera effect. If EFFECT ALL MESH is wanted, then... this feature would be similar-to "sepia" and "black and white" post-processes. Not sure if cell-shading CAN be a camera effect. Not sure if this is objective. But, still, I report my thinking, because I am yappy.
  14. CellShading post-process

    @BitOfGold - that's one of the weirdest playgrounds I have EVER seen! Did you make that? What kind of beer do you drink? You must be reading the docs or something. I'm worried about you. I bookmarked that PG, but I'm afraid it will burn a hole in my bookmarks DB, fall-out on the floor, and my dog will eat it. Then my dog will be strangely lit for the rest of its life.
  15. I am having problems programming yellow drag square, though. I dunno how to do drag on that. Can you help? Others? I cannot find way to drag-move yellow square... and get values of drag amounts and directions. Right now I am stuck.
  16. Absolute positioning

    See, that's why @JohnK makes the BIG money. Thx JK!
  17. Rotation problem of gltf meshes

    Hiya DM, welcome to the forum. Wingnut screwing around. Changed from degrees of rotation... to rate of rotation. I also moved the entire GUI and stuff... inside the importMesh onSuccess code-block. (yawn) I know, not the objective, but I wanted to play with this WONDERFUL model. Back on subject: Not so successful, yet. Still having problems keeping mesh in-sync. Fun challenge, though. Others will have more/better ideas, I'm sure. I'm a noob.
  18. My pleasure. What you ask... is very difficult for me. Still, I try. First, we must verify. Is your camera keyboard (4 arrows and yellow circle) made from HTML? I have made one in HTML, too. Absolute positioning. Much work to do yet. I have never done HTML dragging, so, I need to read about dragging yellow HTML node (called but3span). I need to make yellow square... output drag-values same as red joystick did. I am slow. Be patient with me, and I will do my best... soon.
  19. Absolute positioning

    Can I try it, JK? Hey, that's close. Look at line 80... the positioning before the bake. divide-by 50's? Holy cow. I think I am pretty far lost. A guy needs to be a nuclear scientist to get THIS mesh baked into submission (into being squared-up with its world). heh. Unreal. I have no idea why it is acting that way, but it sure is fascinating. (PS: I changed camera to z-facing)
  20. Right. But notice that wally710 cannot overlap the CENTER of Divano. The collision is happening, but Divano's ellipsoid is not properly sized. It is too small. But, in general, I think you will need to say goodbye to BJS collision system... because... I think you need a boundingbox-based collision system, and not these bad spherical ellipsoids. The BJS ellipsoid collision system was designed for camera-to-mesh collisions, and not for mesh-to-mesh collisions. Phew, there's another, with drag'n'drop turned-on. (mousewheel back a bit) Who makes these goofy playgrounds? ----------------- (a huge test scene). This time, I started with a drag'n'drop demo from our playground demos. Then, I added onCollideObservable on every mesh - lines 60-74. They never trigger during onPointerMove (during drag-intersecting). hmm. Then I added intersection ActionManagers on every mesh - lines 76-103. They ALSO never trigger during onPointerMove (during drag-intersecting). hmm 2.0. Only one method left to check. IntersectsMesh. See onPointerMove handler... lines 149-189. More precisely, lines 171-181. Watch console. We are getting intersectMesh triggering during the drag-collisions. AND... the dragging is nullified when a collision happens. BUT... it gets stuck in collide state. You can see various Wingnut-code in there, remarked-out... where I failed to re-position collided dragged mesh... back to PREVIOUS position before/after the collide happened. I think we need a better JS programmer than me. But... somewhere around line 177 - currentMesh.position = oldCurrent... get that working... and mesh won't get stuck together. Also, FAST drag-to-intersect... might still cause some overlap. More tests ahead. Are you having any fun? I hope so. We sure have visited almost every kind of colliding, haven't we? I sort of wish those observables (lines 60-74) would have worked. They are the most modern intersectMesh testing methods, I think. But nope, apparently those observers are in-active during a DOM onPointerMove event-stream. hrmf. *scratch scratch*
  21. I want to show you one other interesting playground. Camera keys are WASD. Use arrow keys... to translate the gray ibox above the green mesh. A physics joint is connected between the future-invisible ibox... and the green mesh. We have found this to be useful... in keeping moved impostors somewhat under control. Try using the arrows... bumping some mesh. It feels pretty good. I'm not sure if joint-attaching an invisible mesh above YOUR created mesh... would be useful for positioning your furniture, but maybe. I thought you should see it. Party on. Oh... version #31 has a CannonJS speed-it-up thing at line 141: scene.getPhysicsEngine().setTimeStep(.05); Default speed is approx .01666, so, I tripled that. Fast physics! Yay! vrroooooooom!
  22. Hey, nice editor! Cooool. I saw no mesh displayed in test4. But I created some mesh... big and small, and I see the overlap. Let's see if we can fig WHY. Can you put my two functions... into your editor, temporarily? I want to SEE the bounding boxes (mesh.showBoundingBox = true;)... and the wireframe ellipsoidMesh that is installed with those add-on functions. I think the .ellipsoid sizes or placements is incorrect, for each editor model. Not sure. Or, some of the models don't have .checkCollisions = true; ? Something is wrong... but it is difficult to determine... without seeing the wireframe ellipsoids. If you DO turn them ON, remember that mesh.ellipsoidMesh (the wireframe "thing" that gets added in showEllipsoid)... needs to be dragged as well. In other words, avoid setting .ellipsoidMesh.parent = mesh. Better to do renderLoop... for each mesh... mesh.ellipsoidMesh.position = mesh.position.add(mesh.ellipsoidOffset). Continuously move the wireframe ellipsoidMesh... to match mesh.position, but WITHOUT parenting. Parenting might hide problems. Not sure. Anyway, if we could SEE the bounding boxes and the positions/sizes of the .ellipsoids on each created mesh, we could perhaps find the problem, quicker, easier. For physics engine... setting .restitution = 0 on all impostors... SHOULD make them quit moving after collision. But... IF the impostors overlap at time of creation... could be trouble. Flying-away objects... even with 0 restitution. Oh no. Perhaps, when physics active, you cannot create overlapping impostors... or else they will reject each other. I recently discovered some 'collisionGroups' settings in Oimo physics engine. CannonJS may have them as well, but if you disable collisions between mesh, why use physics engine at all. I think you are trying to do "floor-space management" using collisions, right? *nod*. No overlapping allowed... during drag-placement, right? A renderLoop that sets each... mesh.physicsImpostor.setLinearVelocity(BABYLON.Vector3.Zero()); mesh.physicsImpostor.setAngularVelocity(BABYLON.Vector3.Zero()); ...might halt ALL motion. But those impact-at-creation-time issues we see in your editor... is because restitution has value, or because mesh are created atop one another, and physics engine is (violently) disallowing that overlap. We have ways of killing physics motion. But possibly... using "intersectsMesh" and boundingBox measurements... is a BETTER way to do floor-plan management... than using collisions. Instead... you would build some "rules of dragging"... where... if (draggedMesh.intersectsMesh(anyOther)) then mesh.position = lastNonIntersectingPosition. (nullify the attempted drag-to-overlap). Don't forget... "lines 134-144 is an intersection ActionManager for cylinder/barrel2". I dunno. Fun thinking, though. I think I am out-of ideas, though. Physics engine for scene layout... phew... difficult to get impostors under control. They have a mind of their own.
  23. Hi guys. That is a playground that might be helpful. WASD move left cylinder, SHIFTED-WASD move right cylinder. Line 158 distance/speed is set fast. Hold D key, or shifted-D key... to "slam" two cylinders together. Not much overlap. Overlap is minimum BECAUSE we have mesh.ellipsoid (shown in wireframe) set to same size as mesh.getBoundingInfo().boundingBox. [assorted measurements]. See wingnut-added setEllipsoidPerBoundingBox() function. I also added function showEllipsoid(). You can use them to see/test the .ellipsoid placement and sizes on your imported mesh, if you wish. Careful... I am not a pro JS coder... could have mistakes. This is ALL done... without a physics engine. It uses ONLY the BJS built-in collision system... including mesh.checkCollisions, .moveWithCollisions, .ellipsoid, .ellipsoidOffset, cam.applyGravity and .needMoveForGravity. None of those things... are for physics engines. It is easy to confuse the two collision systems. I suggest you NOT yet use physics engines. Stay with BJS built-in collision system... as described/used above. Experiment with my two add-on functions so you can always "see" the size of the mesh.ellipsoids. Make sure the size of the .ellipsoid matches the boundingBox measurements. Perhaps, later, the "precision" gotten by using a boundingBox or boundingSphere as the collider shape... might be disappointing. You might want ONLY player's extended hand to collide with something, but not the player's knees, which are much narrower. That will be difficult. Then, yes, perhaps a physicsImpostor, which likely needs to be a Cannon-only "MeshImpostor" (exactly matches complex mesh shapes). But ohh, such impostors CAN be slow, and even worse, Cannon meshImpostors ONLY collide with sphereImpostors, as far as I know. So... if you can get your project collision system... working WITHOUT using a physics engine... I think that would be to your advantage. Just for fun, in lines 134-144 is an intersection ActionManager for cylinder/barrel2. It causes the position readouts at canvas bottom... to change colors, proving it's working a-ok. Anyway, I hope I have been helpful. This "barrels" playground is a place to do some experimenting with the built-into-BJS collision system, at least. Make more edits and saves, grab a zip copy for playing at-home, paste URL's to interesting SAVES... here, and we'll talk about them, if you wish. Party on!
  24. Hiya JPdev... good to see you again. I don't know if we can expect that BabylonJS GUI would be as power-fleshed as DOM form controls. DOM events have had 100,000 developers and 20 years of time. BabylonJS GUI has had, primarily, one developer and about 1.5 years of growth-time. Still, I know what you are saying, and you make an interesting and pertinent point. Your idea/need is potentially a fine BJS GUI feature request/idea, in my opinion. @Deltakosh and others will want to see this use-case/issue. Meantime, I decided to go experimenting: Surely a bad approach (I'm famous for my bad approaches. I code JS... like an infant uses industrial power tools. heh.) Lines 36-38... my onClick eventHandler. It only dumps the clicked control to console. Line 47... I overloaded the button object... by adding my own button.isPointerOver = false; That new property is used as a filter/discriminator in the UP observer... lines 54/55. That property is toggled in the ENTER and OUT observers... lines 60 and 64. I think this playground demo is "acting" with your wanted-functionality. Be sure to correct me if I am wrong about that. But, I needed to take "the long trail" to get here, didn't I? *nod* hmm. This is an interesting topic, for sure. Anyway, we have a playground demo to do tests-upon. Likely, smarter people than I... will have more/better ideas and will comment soon. Stay tuned.
  25. Hiya MG... sorry for the slow replies. I think you can use node.metadata as a "suitcase" that will serialize/de-serialize just fine. Would that work? You can put "stuff" inside any mesh.metadata, camera.metadata, or light.metadata. So maybe, before you serialize scene1... do... var bigFatObject = anything; (maybe bigFatObject.installExtraSettings() is a function on that obj) var myInvisibleDatabase = new BABYLON.Mesh("blank", scene); myInvisibleDatabase.metadata = bigFatObject; When scene is imported, you should be able to run a pre-installed function... myInvisibleDatabase.metadata.installExtraSettings(). You are better at JSON stuff than I, but... I believe all node.metadata values are "carried-along" with all serializations/imports. Perhaps that will work for you. Holler if you have problems. I hope I am on-subject.