continued_at_new_forum The Wingnut Chronicles

[JackFalcon]

On 4/21/2017 at 4:15 PM, Wingnut said:

are you using a keypress to move the player/mesh? Or... click'n'go?  Touch/gamepads? 

Yeah keypress... wasd...

debounced.

[Wingnut]

Does this thing work for you, JM?  http://urbanproductions.com/wingy/babylon/thruster/t26/flyer26.htm  [zip, slightly fresher]

It's an older BJS version, but, it can give you a "feel" of keypress auto-repeating (held key) cumulative applyImpulse. 

Unfortunately, cumulative thrusting starts slow... and gains speed as inertia accumulates.  Braking does the same.  It appears to do little... but slowly counteracts the momentum.

All the buttons in that scene... can be quick-clicked OR held-down. The thrusters are a little "hot" compared to a NASA Spartan satellite, but, it's all adjustable.... later. (within controller.js)

Keys active:  control + arrows and control + pageUp/pageDown = rotation
                      shift + arrows and shift + pageUp/pageDown = translation

                      control + NumKeyPad 2,4,6,8 and control +/- = rotation
                      shift + NumKeyPad 2,4,6,8 and shift +/- = translation

Two complete sets of control keys!  WOW!  There's actually ANOTHER complete set of control and shift keys... around the "L" key.  Goofy.

And, I was VERY new to physics when I made this (before I knew about setting linear and angular velocities).  So, this is ALL applyImpulse... including DUAL applyImpulses for every rotation (mesh twists).  Holy crap, huh?  What a festival of incompetency!  But version 29 of "the flyer" will be MUCH better.  I'll code it using lots of joints, but none in the physics code.  heh.  (I'm going to wring every last drop of laughter out-of Fenny's Funny) 

Grab zip, steal code, even put your name on it, I don't mind.  It's all bad programming.  heh  The flying bed frame is somewhat modeled after a NASA "SAFER" unit, which is a cold-thrust safety device that spacewalkers wear, in case they become un-tethered. 

It is VERY EASY to parent ANY model to this "frame".  That was its original purpose... a universal physics flyer.  Import-in a Winnebago camper, parent it to the flyerframe, and start flying your Winnebago.  YAY!

This flyer has 24 thrust ports, and each thruster has FOUR particleSystems available (fire, smoke, soot, ice particles) for a grand total of 96 particleSystems.  (only 16 can be active at any given time)  WOW, huh?  Talk about your over-kill, eh?  heh.  LOVE IT.

This "thing" is/was targeted be used for Space Taxi 3D, a 3D version of an old Commodore 64 game I used to love.   Project is... well... back-sliding, like all my projects.  heh

JM, are you going to make some tests... trying out every kind of physics joint that can be connected between two physics-active mesh?  There's about... oh... 4-7 pre-made joint types available, in both physics engines.  These joints... have "constraints" and "springyness" as their parameters/settings.  For example, you can set minimum and maximum rotation limits on a standard hingeJoint.  And a distanceJoint is simply a hinge joint with a stand-off distance. 

You need to make a few mesh, hook them together with various joints, and start attaching some keypresses to some applyImpulses... thrust them puppies around on the ground a bit... watch how they "act".  FUN!   Refer to that non-working train wheel demo... for some nice modern joint code... thanks to RaananW... who once "updated" the train wheel demo FOR me.

[JackFalcon]

Ha! reached my daily 'like' limit...."You can no longer like stuff".

But I like everything - so what?

Eh? Ah..... I see.

[Wingnut]

Take your time, goof around, have fun with it all.  Um... I noticed that you are pondering... "upAlign", and things like that.  Don't over-think the "motor".

Remember Fenomas saying that you should move a "more-static" no-collide mesh (likely invisible)... with your keys, or even with your applyImpulses.  Then use a joint between THAT impostor, and your real player's impostor.

Depending upon the type of joint/motor/whatever... perhaps your "steadfast mesh" (the firm, yet moveable, non-colliding invisi-mesh at one end of the joint)... is sometimes directly above your player, or perhaps in same place as player (when motor/spring starts), or behind.  (Fenomas also reminded me about STARTING the motion on a PAM... with a spring.  Good idea, I've never tried it.)  Anyway, your stead-mesh might need orientation-adjusting for each joint experiment.  The mounting pole.  Ever play tetherball? 

I actually call them "steads" in my code.  https://www.babylonjs-playground.com/#14VFYX#30

There's a pile of... everything, eh?  I tried to convert this from setPhysicsState to... the new way.  I think it's almost converted... but... got a non-console error.  Might be a typo in my conversions or something.

Canvas2D made some changes in its positioning methods... since I coded this about 6 months ago.  Things aren't lined-up real well... but it's all fixable. 

When everything is working, clicking on a button... makes the "chain-of-buttons" swing back and forth a bit.  Each button is a PAM (physics-active mesh)... suspended from one another by physics joints.  That green "pole" at the top... a "steady" place to attach one end of joints-to, you ask?  That's my "stead".   Yay for steads!  A guy could turn-off collide on that, and applyImpulses to it, and move the whole cascade-o-buttons from place to place.  It could be invisible (hint hint).

I don't think there's a real word "stead", but it works... you know... homestead, bedstead, steadfast... all things with "steadiness"   I have a small town near me... named Springstead (Wisconsin).  Remember the long coil spring that was used to close gramma's porch door?  Well, the little "eye-screws" on each side of that long spring... are called spring steads.  The town is named after those. 

You're not buying that story, eh?  Yeah, me neither.  Carry on. 

[JackFalcon]

18 hours ago, Wingnut said:

It is VERY EASY to parent ANY model to this "frame".  That was its original purpose... a universal physics flyer. 

How does one 'parent' model to frame?  Playground or links pls?

Ok, yeah. Merely.parent. ok. I get what that implies.

[JackFalcon]

This all makes sense. stead is really good metaphor to understand it. The tetherball also made sense.

I get where you are coming from....

 

[Wingnut]

Oh, for the flyer?  oooh, well, that would require adding an AssetsManager task or SceneLoader call... to load a .babylon or .obj file... with a model in it.... into the flyer28.htm code.

Then... umm... myModel.parent = go.flyfr.handle;  Then do rotation, position, scaling adjustments on the Winnebago until it hides the bed frame's poles and rails.... and SAVE!  Bed frame is dynamic, too... easily sized, without any joint gaps (I made it before I learned about mergeMeshes() - haha)

'go' - global object (because Wingnut was confused about JS scopes, back then).  flyfr is the flyer frame. Handle... is the central gizmo parent of the frame (a sometimes-invisible box dead center of the frame).  Master parent.

SO... you can actually completely REMOVE the flyerframe (the bed frame)... and keep go.flyfr.handle.  IT is where the applyImpulses are thrusted-at.  There is no applyImpulse force happening at the thruster ports.  That's fake.    It COULD be done, but... it would take tight joints between thruster ports and flyer frame. I was too noob, back then, and haven't de-noobed much since.

That flyer... that's... quite a mess.  But there's some knowledge in there.  No promises.   Actually, controller09.js (inside the t28 zip) is the meat and potatoes.  It really ONLY controls physics on a single box... go.flyfr.handle.  So, a guy could just make a normal BJS box, do a few adjustments to controller09, and the box would fly just like the flyer, except without particle emitters.

[JackFalcon]

15 hours ago, Wingnut said:

myModel.parent = go.flyfr.handle;

controller09. I see. Idea of > cube translated by 16(?) impulses >> Like.

...

[JackFalcon]

The effect on the blue floor-grid is really cool - what is going on there?

[Wingnut]

The black area under the flyer?  Yeah, it is a landing pad.  But during some BJS or browser version, the lighting changed or something, and it lost its texture, and went backface-culled.  So did the plane in the center of the flyer, which has a helper picture on it  (these issues are MORE-likely a wingnut mistake).  So, I have two "broken textures" on those planes.  I should fix that someday.  It is likely fixed in the zipped t28 version I linked earlier.

Correction:  go.flyfr.handle is currently invisible and it is the same size as the entire flyerframe.  That is the only reason it bounces off the walls semi-nicely.  So, if the model you want to fly... is not square-ish, it will not bounce off walls "correctly".  If you want the model you parent-onto the flyer... to also have physics (perhaps on a very bumpy model), then you will need to activate Cannon's meshImpostor on your model.  If your model is a more-standard shape, use one of the simpler impostors... for higher performance.

[JackFalcon]

I see, so work on a frozen-version has advantage. DING. Thanks for that....

 

[Wingnut]

Oh crap, I forgot.  Cannon's meshImpostor only reacts-with spheres.  Well pffft.  I guess you better use a box-ish or sphere-ish model, so you can use a more standard impostor.

(Wingnut kicks the meshImpostor, just for fun)    It's mostly for heightMap terrains... and rolling spheres around (sometimes used as vehicle wheels) ...in the mountains and valleys.    Rocky Mountain bowling and Himalayan golf.  heh

The "r" key (remember cam) on the top of the flyer window... is somewhat interesting.  Pressing that (or pressing 'r')... stores the current camera rotation and position... into the browser's "sessionStore" system.  Then you edit some scene code in your programmer's editor, save, and hit control-r in the browser... (to reload the new scene).  The flyer scene can/will use that previous camera orientation... as the starting cam orientation.

This is handy for when you navigated a camera to a certain precise close-up place, examining something carefully, and you want the camera to begin at that SAME location after the reload.  It's all Wingnut code, so, it is naturally 3-8 times more code than necessary. 

[JackFalcon]

Yep put in a heightMap and saw a boximpostor drop through it...

Ok got it.

[JackFalcon]

@Wingnut wasn't easy -> First Playground, GRAVITYBOX: 

      Used that red texture sphere -> and using setGravity() made it bounce around a box:

        https://www.babylonjs-playground.com/#8C98MU#9

 

[JackFalcon]

Wingnut, Thank you for your walkthrough of JS Physics engines. I read a few threads and your thoughts, a time er two, and got a good picture. Your chronicles of methodology is enlightening, and illuminating. Thank you for the crash course in JS Physics methodology.

...

[Wingnut]

My pleasure, JM, I have enjoyed our conversations to date, and you have a fun and inventive personality.  I predict that you will quickly become a BabyonJS superstar.  You seem like a really cool person... I'm glad I got to meet you.  Perhaps we have many fun adventures ahead.  I hope so.

If you get a chance, I would like you to do a forum search for 'getHeightAtCoordinates'.  It is a function on mesh-class objects, and when used on heightMaps, it can be used for terrain-following WITHOUT physics or gravity.  (thx @jerome)

http://jerome.bousquie.fr/BJS/demos/getHeightAtCoordinates.html

There's been others who have used Rays for terrain-contour following, and behind the scenes, mesh.getHeightAtCoordinates(x, z) might use a ray, too.  All I know... is that it is useful at times.  It can keep "things" stuck to the ground when moving across bumpy terrains.  You and I talked briefly about terrain following cars and mesh. When using getHeightAtCoordinates, there's no hassles with CannonJS meshImpostors ONLY interacting with spheres.

Your car won't be doing any parabolic car jumps off-of the mountain peaks, though... unless you are calculating your own flight trajectories.  But take time to study Jerome's stuff, if you feel so inclined.  There's nobody better at making mesh act like they are using a physics engine... without using a physics engine.  (Okay, okay, there's likely others nearby who can do it as well.  But Jerome made demos with great in-code comments... and wrote fine docs.) 

Generally speaking, only cameras (not a mesh) can have physics-engine-less gravity (unless you calculate your own gravity movements for mesh - fairly easy).  So, keeping your character or vehicle on the ground in bumpy terrains... is an issue.  Our friend Jerome saw the issue, and many more geometry improvements... and "smoothed" as many as he could (he's a hero of mine, like SO MANY around here).  The solid particle system is his, meshBuilder is his, ribbons, tubes, extrudeShape, parametric constructors, spherical harmonics, on and on.  Ever seen a spherical harmonics shape, JM?  Take that link to some playgrounds and do some touring.  Jerome has even been known to morph the SH shapes from one to another.  GOOD GOOD stuff.  We got godrays (volumetric light scattering) involved, too.

Fun fact:  Since Oimo does NOT have a meshImpostor, but still likes to use physics-active terrains, the folks at Oimo have showed us how to do it.  Although I have not investigated, rumor has it that the entire terrain is "covered" with invisible sphereImpostors (you can see the spheres do a little "hopping" as they roll across slightly-bumpy invisible sphereImpostors).  Cool, huh?  A bit like Raanan's cloth demo.  (wireframed by Wingnut)

One more thing... @Temechon's tutorials/projects.  T-doggy does everything great, but especially... he is great at getting a user started toward a project... with OOP in mind (object oriented programming).  When using OOP, many of your functions and classes... are re-usable, project after project after project.  If you want to learn how to do coding/projects the right way, visit that link just above... and study his way of doing things.  HIGHLY recommended. 

These guys are just a few of the MANY excellent coders and thinkers around here.  They ALL have taught me things... and I am glad to pass those tips on to you and others, as best I can.  The few things that I know about... all came from "team"... and I really like ALL OF THEM, including you, JM.  You're going to fit-in just fine 'round here - welcome to the team.  I hope you can hang-around with us for a few... decades. 

[JackFalcon]

Ok... listening - thinking... and NOTES (for later).

- 'getHeightAtCoordinates'...terrain-following WITHOUT physics or gravity.  (thx @jerome)

    'mesh-class' objects, pressed into brain, got it. Thanks, jerome. : )

    yep - that is working well, no doubt! very helpful .

- Decades? Ok... 

Thank you.

[Wingnut]

21 hours ago, Jack Morris said:

'only cameras (not a mesh) can have physics-engine-less gravity ' - saw that, why?

I worded that badly and slightly incorrect.  I should have said... Only FreeCameras (which is not a mesh) can have physics-engine-less gravity automatically applied to it... by the BJS framework.  Only FREEcamera class has .applyGravity.  BUT, particles are (sub)mesh, and they also have applied gravity from scene or from particleSystem.gravity property.  Sometimes, I am not very thorough in my info-passing, sorry.

And last I knew, freecamera. _needMoveForGravity = true ... is the way to make the cam start falling at scene.isReady.  (secret private _property info)    Otherwise, it takes one arrow-key move of the camera... to make camera start falling.

Don't forget .checkCollisions = true for both ground and falling cam, or else it will never stop falling.  Perhaps someday, we will have a contest for "Best motion sickness in a playground scene". 

This is all non-physics engine stuff, of course.  Scene.gravity is for built-in stuff (freecams, particles)... but it is ALSO used for 3rd party physics engines IF no gravity is set on the physics engine itself.

Your question is still a good one, though. (Why mesh have no .applyGravity? [loose quote])  I have no answer.  Perhaps we can coax @Deltakosh or other core Gods... to visit and explain.

You sound like you have much technical expertise.  It seems I (and others) have PLENTY that we can learn from YOU.  Coooool!  I'm glad.  If you wish to tell me/us YOUR STORY... brief or detailed (or if you have website with "about me"), I sure would be willing and honored to read about you. (thx)

Yes, cloth demo is a bunch-o-joints ( distanceJoints hung-from stead-points )... and the cloth uses "particleImpostors".  I never knew particleImpostors (point impostors?) existed... until  @RaananW used them.  SO much to learn, SO little Wingnut brainpower. heh

[JackFalcon]

Following... Experimenting...

Thxagin,

[Jaskar]

@Wingnut Thanks, I'm great. But how can you see a little like like this ? Do you have a third eye somewhere ? 

[Wingnut]

Hi @Jaskar!  Yeah, I did not actually "see you", did I?  heh.  You funny.  (for readers, I said "good to see you" to 'Jaz' in an earlier post.)

Actually, I really wish I COULD "travel" with out-of-body (astral projection) or 3rd eye "tele-presence".  Wouldn't that be cool?  Tourism industry would likely suffer, though.    Difficult to purchase souveniers, hotel rooms, and tourism food... in a "light body"  

[JackFalcon]

Mr. @Wingnut you helped me to know what to do. Thanks for introduction, direction, tips. Catching up is best that way. Multiply knowledge === hero... in my book... Moar_L8r(this).thx();

 

[Wingnut]

Hey @enwolveren... I heard rumor that you wanted to start a never-ending thread... of your own.  Perhaps we need a forum category just for us long-talkers... so we don't keep repeatedly landing on the top of the Q&A forum.  (pushing the real questions down the list too fast)

What do you think, folks?  Time to put all the "chronicle"-type threads... in a new sub-forum?  Perhaps "snip" the first year of this thread... make it into a single webpage or something?  *shrug*

That sub-forum would also be the place to turn-on "The Babylon Radio Network"... playing selections from our github-based "Who The Hell Is Talking NOW" subfolder of audio files.    nah.

[JackFalcon]

er? yeah! no? : )

[Wingnut]

Evolving rationale?  In the first 1.5 years of TWC?  If you saw anything THAT cool-sounding, you should probably schedule an eye exam. 

Missed paths, you bet.  Missed boats, oh yeah.  Missed targets, yep.  Mis-interpretations and/or mis-understandings... by the truckload.  heh.

Miss Universe visits?  None.