Wingnut

Members
  • Content count

    4,509
  • Joined

  • Last visited

  • Days Won

    94

Everything posted by Wingnut

  1. Oh, Naz is on-forum ( @NasimiAsl )... he built a big shopping center with long, climbable stairs. http://melyon.ir/ (slow loader, but gorgeous). Enter tallest building. Many stairs inside. I don't think camera gravity is active AT ALL in Melyon. Perhaps terrain-following, though, and that might be the same system that climbs the stairs. Thoughts, Naz? Maybe he used invisible mesh parented to camera(low height), and when mesh intersects next step, he lifts camera/player one step-height (probably with NO camera gravity active... when player/camera is upon stairs). I guess that IS basic "feel-with-a-stick" terrain-sensing, eh? Need picking-ray or bounding box intersects... something like that. More thinkin'.
  2. Hi guys. @JohnK, ya "bought the farm" on this one, eh? https://www.babylonjs-playground.com/#PVAC9F#2 Just another. I lined up the camera, put it in the air and set _needMoveForGravity = true; Then added my flaky .showEllipsoid func, and went to work in 138-140, putting the collider in the center of the first step as best i could. That's not going to work, though. Not only do we need a collider on every step, but as long as camera.applyGravity is ON, the camera will not climb-over the collider. It keeps sliding-off the collider backwards, because the camera gravity won't let it climb over. WE got trouble. BIG BIG trouble. Ok, not that much trouble, but some. I don't think extruded stairs will ever be collider-climbable... not without some serious hackus big mackus. Thinkin'.
  3. Ok, https://www.babylonjs-playground.com/#1ND6TH#23 Hi gang. Moving ahead with "the human leg" physics project. @RaananW promised to help, but I think he was going to do his own thing. (I don't think he likes my physics coding style.) I haven't changed much from the initial demo, from another thread. I got the sections a bit more proportioned. Fast screen clicking impulses upper leg (red part)... both leftward and upward. Boy, is that scene slow, eh? It is for me. Raanan says it has to do with world scale, and it only LOOKS slow. But I don't quite understand. For the mass weights I'm running, it IS slow. Anyway. I am going to try Oimo hinge2joints, first, with their 2-axes and 2-limitMotor constraints. (currently, set to single-axis hingeJoints) Early-on, we I should work-on the hip. It should allow the upper leg to pivot about 80 degrees horizontal (spread 'em)... and about 170 degrees vertical (for those good cheerleader high-kicks) But, before this project advances toward Jointsburg, I want to "activate" my new "Pulsars" idea... little arrows that you can place upon physics active mesh... and click them to applyImpulse on the mesh's impostor... at that location and direction. MANY of them, on a single leg section. I want to SEE that hip joint's lateral angle-constraints - in action. Pitchew, pitchew... blasting those bones with the air hose... making sure they are acting correctly. A true joints-testing laboratory! YAY! It's the start of teaching physics joints... with playground-based tutorials (PBT's). DOUBLE YAY!! To properly watch a joint... sometimes you need to get the camera REAL close... and attach the micro-nozzle on the air hose. Pitchew Pitchew! Seeing is believing. Impulsing arrows. Pulsars! "Imps", if you wish. Coming soon, to a leg NEAR YOU! Still, I think Oimo is somehow unduly lazy/slow. It's got a boggy stepper... me thinks. (Wingy greases Oimo's joints with hot bison snot.) To me, it looks like the scene starts-off pretty fast, but bogs after the first mesh collision. hmm. Anyone else see that?
  4. 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!
  5. Boxes only, @aFalcon. The frame is derived from the bounding box. Anything fancier, and Wingnut would get a brain tumor. A "nudge" is simply a tiny value added to positions... to avoid z-fighting. On the #23 PG, the nudge/nudgie is the 'n' variable defined at line 203. It is used in the next 6 position-setting code lines. Exciting, eh? I'll try to turn ANYTHING into comedy. 'Nudgies' is surely not the correct term, but it's kind of fun to say.
  6. I had good fun. I was doing heavy drugs the whole time. This kind of thing has re-usability, too. Others will likely borrow it and sell it on the streets, for heavy drugs. heh
  7. Yeah it does. You work on stages sometimes, aW? Crazy way of life. https://www.babylonjs-playground.com/#35HAW1#20 Alright, we are rollin', now. What a pig. Functionally perfect... but I'm not sure if I have used enough code, yet. I bet the big dogs can do this same functionality... in 10 lines of code. heh Update: [#21] I made the panels all blue and gave everything a gray material... to look more like a road case (for mobile music/production gear, sometimes called an "Anvil Case"). I did not call hideFrame() at startup (although it will still hide on pointerOut). Then I thought... okay, just temporarily, I'll down-scale the gray box a bit, to beat the z-fighting on the panels (line 324). Hey, why doesn't this work? Well ya dummy Wingnut, the "frame" is "derived"-from current box scaling. SO... down-scaling the gray box... just makes the frame parts down-scale, too. DUH! var n = .001; // nudgie Lines 205-225... need some "nudgies"... little bumps of the positioning values... to kill the z-farting. I suppose a guy could "thicken" the panels... by making them be thin boxes, instead of planes. Maybe that would be easier. The best way... would be an aerosol can of spray-on "Z-Peace". But noooo... they quit making that 2 years ago. hrmph. Nudgies installed: https://www.babylonjs-playground.com/#35HAW1#23 yay!
  8. https://www.babylonjs-playground.com/#35HAW1#16 Just starting with a frame gizmo (central frame parent) and 6 panels, which will likely be invisible but they will be placed atop the box sides... and be the pointerOver/Enter sensors. Time for Wingy snowblow again, though. Currently working-on panel2 transforms [rot, poz, scaling]. Generally, 3 types of panels. FrontBack, LeftRight, TopBottom. Perhaps you might want to run-with this as a starter... while I wander-off for a couple hours. Your call. These sensor panels prepares us for 6 pointerEnter actionManagers, each with a special executeCodeAction. Example: If panel1 pointerEnter... make panel1 visible, along with spheres2, 3, 6, 7, and ridges 3, 4, 9, 11. On pointerOut/Exit... make all frame parts invisible again. These 6 invisible scaled-to-box-size panels... surround the box all the time (when box is in edit/whatever mode). Panel1 is scaled, rotated, and positioned already. Panel 2 is next. You'll want to AVOID panel.setEnabled(false) because that will disable the actionManagers on the panels. Make them visibility = 0/1 or material.alpha 0/1. The spheres/ridges can use setEnabled/disabled as wanted, unless you want to put actionManagers on THOSE for some reason. And again, I'm not sure that this is wise/not. Wingnut has a tendency to "take the long way home". You need not continue this... I will probably finish it no matter what, eventually... out of pure curiosity. ALL others are welcome to finish it, too, afaic. Be well, talk later.
  9. ahh. Good ol' physical work. yech. The idea is... you never dispose/recreate. Just setEnabled(true/false) when needed, or use .visibility = 1/0. One complete frame exists all the time... just most parts are always invisible/disabled. You might need a frame re-sizer/re-scaler, though. Will you be needing more than one of these frames... active at the same time?
  10. AND... there's one more "old school" way to put user's attention/eyes... at a certain location. It has been used in the entertainment industry for a LONG LONG time. The world famous... spotlight. No, you can't use 1000 of them all at the same time, but still, for certain tasks... light-it-up, baby. What? Another way? Okay, okay, you can also "encircle" an area on the surface of a mesh... with a ring of short-lifetime sparkly particles. This is the "up-town" way of focusing user attention at a certain place. Circus-grade highlighting. It's not exactly your grandfather's targeting reticle, is it? And it's not so easy to place onto the surface of a mesh.
  11. Still need to think about picking... with the boundingBox-made version. Perhaps... hmm... when in "edit mode", start with 6 planes, exactly sized, on all sides of the box. Put actionManagers on them... sniffing for mouseovers or clicks or whatever. If picked, then add spheres and edges, IF WANTED. But do you need them, IF a user can pick a box side, and have it change color to show it is "selected"? I dunno. Just thinkin' of stupid stuff. When exiting edit-mode, you could fly all six of those temporary box-sides... off into space... a possible cool effect. What? Did you party last night? Look at ya! whis... with ice c...?? Whiskey and ice cream? No wonder ya feel like puppy stool.
  12. Hi guys. Ziguri, if the objective is to focus user's attention at a certain location upon the model, then this might be a job for Babylon decals. They have the abilities to contour to a bumpy surface, and they have full Babylon Material powers, such as transparency, colors, textures, post-processing, etc. Keep in mind that decals are created ESPECIALLY-FOR the surface-contour beneath them. If you try to re-position a decal post-creation, it will NOT live-update its contours. So, if you need to drag a decal: - When pointerMove begins, dispose the old decal, switch to a grabbing-hand cursor for your pointer. - OnPointerUp (drop)... normalize pointer cursor, get a fresh pickedPoint somehow, and create a NEW decal upon the mesh... there. It will have fresh surface-conforming contours. *shrug* At least that's what I would do, if I ever had to drag a decal.
  13. https://www.babylonjs-playground.com/#35HAW1#15 Notice lines 14-16... setPivot... but then bring the box back to original view-position. I've got quite an extreme pivot offset on there now, as you can see when I spin the box. Also, I needed to parent all spheres and edges/ridges... to the main box. But really, better to parent all ridges and spheres to an invisi-gizmo, and then every time you pivot-shift the main box, do the same to the "frame gizmo". Parent that gizmo to main box, as wanted. Just some thoughts.... not very exciting. There's some twin parenting loops in lines 156-161... a place to change box to frameDaddy (the invisi-gizmo) or something similar.
  14. Camera's ellipsoid from above missing

    https://github.com/BabylonJS/Babylon.js/blob/master/src/Collisions/babylon.collider.ts#L191 embeddedInPlane. hmm. Makes ya wonder, eh? Special processing for when ellipsoid is completely flat, perhaps? Anyway, adjusted scene... https://www.babylonjs-playground.com/#MJRGPB#6 Left plane facing forward, right plane reversed, and yep, I see some major differences between the two. Let's ping our superhero again, huh? @Deltakosh, we are already missing you. Come tell us another bedtime story, ok?
  15. Yours is more ready for dragging verts/edges, should you want-to. My bbx version is positionKind -stupid. You're going to stay rectangular, so, you would probably drag an entire quad/side/top/bottom... 4 points moving at once. Anyway, have a fine evening, and thanks for letting me play with your project. I hope I didn't ruin any fun for ya.
  16. Ah heck, I tried a "balls from the bounding box" version... https://www.babylonjs-playground.com/#35HAW1#8 vertexData-free... but not near as much fun. How about some edges? https://www.babylonjs-playground.com/#35HAW1#9 It uses addEdge() which is almost identical-to cylinderBetweenPoints(). Goofy. Unfortunately, addEdge() screws-up the pivotPoints/origins on all the edges, and I think you would REALLY like all the edge origins to be dead center of each edge. hmm.
  17. Distance between FreeCamera and Mesh

    ALRIGHT! That's the spirit! Ok, now HOW do I do that? Put 1000 of each in for-loops, turn on the browser performance profiling, and wave the green flag? Maybe. I'm scared.
  18. Distance between FreeCamera and Mesh

    Oooh, what an answering race... neck and neck. Arte in the gate first, but his solution has more length than DK's. BABYLON.Vector3.Distance(camera.position,mesh.position) mesh.position.subtract(camera.position).length() Should we put them on the griddle, and see which one sizzles more? A little CPU race to decide it all? hmm. Gentlemen... start your rendering engines!
  19. hehe... No pressure at all. I was MAYBE going to try a "derived from boundingBox" version... IF you haven't already tried one. I'm no pro with the boundingBox wrangling, but... it might be fun for a bit of afternoon pain. You have actual verts, so you could drag and bend junk. With a boundingBox-derived 8 spheres... it would be for... well... things OTHER THAN drag-plotting verts. Add-in our now-famous tri-grid 3D drag'n'drop, next? Maybe put your box in there, and when you light-up a sphere, put a round decal or disc on all three planes, each/any can be dragged? Huh? Let's go! heh
  20. thx. Sometimes foolishly. Sooooo... did you try to "derive" the 8-points... using only boundingInfo and boundingBox (and their properties)? What happened? Not enough code lines? (snicker) Just curious. You're probably going vert-dragging and edge-dragging, so you probably need to play in vert-land anyway.
  21. Gorgeous stuff! NOW perhaps... cylinderBetweenPoints (PG search for 'vend') That will work for edges, unless you feel like going indicesKind-grinding.
  22. Camera's ellipsoid from above missing

    I assume Y-offset by Y-radius. (duh, Wingy) @Dad72, yep, your video is showing exactly what K and I saw... but I/we thought that was incorrect, until I/we learned more stuff. Sorry for confusion. Thx for video! Is that we/they want? Or, should we/them still keep auto-offset, but set it to default 0,0,0 ? *shrug* Is that what was meant? (I guess I can test and find out)
  23. Camera's ellipsoid from above missing

    Yum! I hope we didn't break older scenes. Thx DK and everyone else.
  24. Camera's ellipsoid from above missing

    Thx Dad! Good thinkin's. Meantime... Another test: https://www.babylonjs-playground.com/#WWCK0#86 Basic barrels demo with .setEllipsoidPerBoundingBox() disabled. Baby 'zoids'. "zoid" or "soid" are easier to type. Shift-Q and 'E' tests are different, now. No freezes, either, so E, Q, SHIFT-E and SHIFT-Q all work, even after collide. hmm. Those zoids "look" centered-on-mesh, by default. I suppose we could add a wireframe zoid to the camera, eh? Not for arc cams, though. Only free cams have zoids. Here is a barrels demo with a freeCam with 1.1, 1.1, 1.1 zoid radius... and we're looking-out thru the camera's zoid-sphere. Interesting-looking - a little camera.minZ corner clipping. Tweak camzoid size at line 63. We can even look-at the freecam with its new ellipsoidMesh... from a 2nd camera point-of-view. Can we "sim" cursoring that freecam, now? Then, we can watch it collide with junk, from arcCam view. Warning: I parented that camzoid to the freecam (line 77), and that might be a mis-positioning, per the Satguru info. Line 18 within my showEllipsoids() func... adjusts position for ellipsoidOffsets, in case anyone was curious about that. I hope I'm doing that correctly. I think showEllipsoids() is important for us. But, it was coded by me, and that means mistakes are likely. Anyway, moving-on... Notice the constructor in line 10. var sphere = BABYLON.MeshBuilder.CreateSphere("elli", { diameterX: this.ellipsoid.x * 2, diameterZ: this.ellipsoid.z * 2, diameterY: this.ellipsoid.y * 2 }, scene); Ellipsoid values are radii. I keep forgetting that, so I thought I would remind myself, and perhaps others. I love this type of studying, guys. Thx for tolerating me, and my sometimes-slow comprehension. We're still welcoming comments from everyone.
  25. *nod* Possibly, that cwm() early in the bake... is used to "get all pending position, rotation, and scaling completed before opening the bakery". I think rot, pos, and scale (transforms?) are all affected, but not by the bake. I think all 3 transforms are computed every frame, unless umm... freezeWorldMatrix()? But I think when mesh cwm(true)... the transforms are applied faster than once per frame... or in other words... mesh onChangeObserver. I could be wrong. In fact, it's likely. But I think freezing is the best perf, cwm(false) is 2nd place, and cwm(true) is Bogtown. Anyone buying that? I bet a forum search for computeWorldMatrix would produce a pile of goods. Hey, there's one from BZ. Yeah, you're a pro at this stuff, but you hang around with noobs like me, because you are kind (hug). Although all the big dogs are performance-driven, I bet Jerome has really worked hard to power-perf his Solid Particles System (SPS). He's produced some SPS demos with HOLY CRAP-levels of mesh moving on the screen. I can hear my CPU grunting and snorting on many of his demos. Goofy as this may sound, I ALMOST bought a gorgeous snowblower model for $64 a couple days ago... JUST BECAUSE Jerome has SPS/collisions working so well. I want to get a road grader (motor grader) model, too, and perhaps a bulldozer and front-end loader. (I have Tonka Disease) For me, SPS stands for Soil/Snow Particle System. heh. Someday I'll start work-on Tonka Land. You can "embank" on it. ar ar.