continued_at_new_forum The Wingnut Chronicles

[Wingnut]

It was rhetorical question.  I didn't want to ruin the announcement party or surprise.  But yeah, I think I will love it, too.

I only saw top line of editor window... change to "let's do metadata" or something like that.    I said "oh, playground workers are under the floor.  I need to quit smoking pot so they don't get uncomfortable."    My dog nodded in agreement.

NewsCenter 4 - Breaking News:  Earlier today, rescue workers accessed 3 subterranean playground construction workers, who had apparently succumb to a skunk-like gas leak!  Witnesses claim that the workers appeared dazed, hungry, and talkative, but otherwise in good health.  heh

[Wingnut]

Uh oh, we seem to have misplaced the #18 test playground:  http://www.babylonjs-playground.com/#11YE88#18

I think it was the first one that I added metadata-to.  (Wingy digs in the toybox) 

[Wingnut]

Saved another - http://www.babylonjs-playground.com/#11YE88#18

No metadata in this one.  I'll test metadata in a less code-loss-situation than this.  (I lost a few minutes of work when I lost original #18).

Anyway, here's repeat of test... sort of.  Instead of yayManeuver() called in line 77, it is called in lots of places. 

ALL the mesh shown on the screen (except box)... go dark when scaled significantly.  The scaled sphere, scaled ribbon, and scaled torus... all have active yayManeuver() calls (adjusting their brightness and shine).  The scaled knot and scaled cylinder are still dark - their yayManeuver() calls are not activated.

That is all.    Wingnut learning and talking. 

[Wingnut]

Ok, the bobsled is looking good.  Here's a new look at it. 

Changed to SINGLE piece cockpit section, so main "body" is nose, cockpit, and tail.  They are "merged" mesh.  Little tiny "seams" can be seen in the yellow diffuseColor... if you control-drag and mousewheel-in real close.  No big deal... maybe a tiny position adjustment.

Next step is... of course... placing decals from our bobsled racing sponsors (Such as BJS Racing Oil)... all-over the new merged-together 'body'.  YAY!

So, I slapped a yellow diffuseColor and a local diffuseTexture... onto the new 'body'.  AS YOU CAN SEE... each of the 3 merged pieces... has its own individual/specific UV mapping.

In other words, the UV's of 'body' (the merged 3-part mesh) could use some adjusting.    The 3 parts aren't being "team" players.  heh.

Yes, I DID ask myself... "Wingnut, would you like to use MANY BABYLON.Decals... to place all the racing stickers?  Or would you like to TRY, SOMEHOW, to UVW-"unwrap" the entire body texture.  Then load that "unwrap" into CorelPaint, and return with all the racing stickers bake-painted onto a single body.diffuseTexture?"

Yep, that is what I asked myself.  I received no answers from myself.    Anyone else have opinions/thoughts?  I'd be glad to listen.

update: Ya know, the bobsled has been completely dynamic, so far.  A "purist" might say "Thou shalst not use static (pre-made) images and racing stripes, etc.  Thoust SHALT use dynamicTexture and context2d drawing tools."  erf. 

So, here is a bobsled with a dynamicTexture, and a simple grid that is dynamically drawn on its canvas (stolen dynamicTexture code).  No, I haven't determined how to convert the UVs of body... to "act like" one single mesh, yet.  Not sure it is possible. 

But perhaps... if each of the 3 merged meshes... had a separate MATERIAL, each using a common-yet-separate diffuseTexture, then each part could use unique texture offsets and scaling... and make it LOOK LIKE the body is using a single material.  Phew... can it be done? 

What's that?  You say you need something "ridicululous"?  Ok, here ya go.    (thx to Michael Jasper for the spiro-code) (CPU-heavy) (I bet @NasimiAsl could do it on the GPU.)  Party on.

"It's a wonderful day... for PI" - Peter Griffin  (fragilite/thin-skinner warning - some material may offend)

[Wingnut]

Hi gang!  Fresh bobsled.  http://www.babylonjs-playground.com/#PBVEM#112

As you can plainly see, this one is sponsored by SCRABBLE® Bobsled Racing Team, Inc. 

Remember how I mentioned that the three bobsled BODY parts (nose, cockpit, tail) could be adjusted to LOOK LIKE it is one continuous texture, even though they are 3 separate mesh with 3 separate materials/textures (and no shared UVs)? 

I thought I could adjust the texture offsets and scales... to make things "align", even though each mesh had UVs for an entire texture.

Well, as you can see, careful texture offsets, scaling, and angling... allowed me to get "in the vicinity"  (fairly close).  Nose/cockpit "seam" is looking fairly good... with only SLIGHT issues on the bottom of the sled.  Looks tolerable.

The texture seam between the cockpit and the tail section... still needs work.  And the foils/fins need some adjusting, too.  They MIGHT use a completely different texture, anyway. 

But... the beast is coming along fine... looking better every version.  Quite a "grind", but I wouldn't have it any other way.  If you don't bleed enough on a project, there's no sense of accomplishment... in the end... while bandaging all the wounds.  Later, I may be able to formulate some formulas... to mathematically square-up the bobsled's pieces.  The sizes of the pieces... should match perfectly, somehow.  Currently, I have some slight size differences... piece-to-piece, and that affects my texture aligning.

Some of these texture offsets and scalings are super-sensitive.  Micro-adjustings.  It takes forever, doing it manually.  I think I can "derive" (calculate) these scalings and offsets, sooner or later (based-upon values used to "generate" the bobsled pieces).  My dog seems nervous. 

[JackFalcon]

Hi @Wingnut, and every1, great work. I'm following through the steps above, very helpful. 

I trace steps, and something came up... in the playground links, 

Seems related to the state-of-the-playground recently. I'm curious what it is.

Some of them work and some seem to have versioning error messages?

Clear cache (seemed) to have no effect in my case (and I do not understand what might be missing, or what to look for, etc).

Issue Description: Playground links (above):

Control Test -> this link works:

http://playground.babylonjs.com/#10JNZ8#1

But this link has some issue, 

http://playground.babylonjs.com/#1VITPM#29

-> it gives a good clue: 

       Line 106:26 - wheel1.setPhysicsState is not a functionine 106:26 - wheel1.setPhysicsState is not a function

setPhysicsState missing?

Is this a Playground  versioning issue .... cannon versions or Caching? I don't understand.

-> scratches head..

Do you know the fix?

Last example: createCompoundImpostor not a function: http://playground.babylonjs.com/#1VITPM#25

Did something change?

Thanksmuch, 

gr8workgents.

Line 53:26 - wheel1.setPhysicsState is not a function

[Wingnut]

Hiya JM, nice to see you, and thanks for reading my ramblings. 

Yeah, a few of the links have gone dead over the years. I guess that is to be expected.  Sorry. 

The two physics issues you mention... got broken recently in "The Great Deprecated Command Hose-Down"   

- SetPhysicsState is gone in the newest BJS versions.  It is now done like... sphere.physicsImpostor = blah blah blah.  Here are lots of examples... from our playground searcher.

- compound impostors went deprecated and eliminated, too.  You can still build compounds, but you do it with standard BJS parenting/childing.  The secret... is to put the impostors on the children FIRST, and lastly, on the parent.  This might change, someday.

When in doubt, read the book. 

We have also seen some indicators that scaling the parent should be avoided... but that needs testing. 

You may have noticed that sometimes... it is BABYLON.Mesh.CreateBox(), and sometimes it is BABYLON.MeshBuilder.CreateBox().  The MeshBuilder version allows you to enter parameters inside the constructor, such as width, height, depth... so you can create a box (and many other basic shapes)... with the precise dimensions that you wish (and therefore no need to set any mesh.scaling).  This is good policy for creating parents... for these "families" of physics objects (formerly known as compounds).

Let's see, I once made some particle PG demos using LOTS of custom code, and those playgrounds went stale, sorry.  I have made new versions of SOME of those.

Umm... I had a demo of some particles... radiating god rays (volumetric light scattering), but due to some changes in the depth rendering system (i think), particle materials can no longer produce godrays.

I'm sure there are more bad PG links... sorry for the inconvenience.  I guess I would suggest... don't read TOO FAR BACK into this topic thread.  Perhaps no older than 1 year, eh?    There will be less stale playgrounds, that way.  heh. 

Holler if you have more questions.  In a day or two, I will repair the train wheel demo, unless you beat me to it.  The de-rotated white wheel hub... has me a bit worried, considering recent work happened in our physics plugins... regarding rotation (uh oh).  Investigations ahead. 

Hope this helps.  I'll keep you posted on what I discover, and you feel free to talk about anything you like, anytime, here in this thread, too.  As you can tell, it is a yap-a-thon.    Thanks for pointing out the broken stuff.  Now you know a bit of history behind it all.  Our two 3rd-party-authored physics engines... CannonJS and OimoJS... are not always easy to tame.  They have been "grumpy" at times.

PS:  Want to see an unusual little secret... about OimoJS?  I knew ya did.  Here is a basic modern physics test-playground, currently wired for OimoJS.  Notice the motion is sort-of slow-motion?  *nod*.  Now remove the term 'new' from line 29.  RUN.  Did the motion get faster?  It does for me.  Quite a bit faster.  Cause:  Most people think it is The Ghost of Archimedes... who has built a small cabin in our Oimo physics plugin. 

[JackFalcon]

Yes, very helpful...

I didn't know about Playground Search. +1. I will use it. Still trying to get habit to craft playgrounds.

Backward incompatible deprecations -> make sense. (thank you for confirming). No inconvenience.

Comes with the territory.

I am almost at compound impostors. Love the details. 

Current status converting to cannon from checkCollisions=true. 

Tricky physics tango: need to switch gravity (with cannon) around a cube, got that working, however need similar behavior of moveWithCollisions() with cannon .... looking into that.

i.e. character falls over... and spins like a top.  : )

Your updates are gr8. MeshBuilder, parenting, and volumetric light scattering... are very helpful for people to catch up...

And, found that ghost. Wow, unexpected... constructor override (my best guess/without looking).

...

Cheers, 

 

[Wingnut]

Hi again @enwolveren, thanks for the kind words.  It sounds like you understand these systems quite well.  Good job.  Force-moving a mesh that has a physicsImpostor... has been a problem for a long time.  I say "force-moving" because... previously, there was only two ways to "position" a Physics-Activated Mesh (a P.A.M. ? heh)

1.    .applyImpulse(directionAndMagnitudeVector3, contactPointUponMeshVector3)
2.    impostor[.body].setLinearVelocity(directionAndMagnitudeVector3)

But recently, BJS superhero @davrous made some changes and told us about it... here.  Now, it appears that we CAN force-move the PAM shape/mesh, and the underlying physicsImpostor will obey.  Keep in mind, though, that the PAM's impostor... could STILL have linearVelocity and angularVelocity AFTER the PAM-positioning.  It might start moving again, after re-position... due to residual stored energy/inertia.

In this forum topic, I do some minor repairs to a physics playground.  Click on ground to tilt it, and start the ball rolling.  User issue was... ball is "violent" (out of control) after it is returned to starting position... after falling-off ground.

When the ball falls-off the ground, it has angularVelocity (rotational roll), and as it fell, the gravity caused it to highly-increase its downward linearVelocity, too.  It had LOTS of energy remaining upon the impostor... when it was re-positioned. 

SO, look at the render loop... lines 43-56 in that playground.  See lines 50 and 52 killing the impostor's energy?  It works.  When the ball returns to starting position, it falls straight down with no spin.  Yay!    

Physics pro @fenomas had an interesting idea for force-moving PAM's... too.  I've never tried it.  He said... loose quote... "It might be best if you use a physicsJoint to attach the PAM's impostor... to another .visibility = 0 PAM (possibly positioned directly above the PAM you want to move).   Then move the invisible PAM (not the visible one), and let the joint pull the visible PAM... to the new position."

This could be considered a "soft move" as opposed to a "hard move", because.... joints have some flex (slop in their bearings).    I thought his idea/info was interesting and worth consideration.

It has ALWAYS been difficult to make a PAM... move a CERTAIN DISTANCE with setLinearVelocity or applyImpulse.  When tried, they usually start with a fast velocity, and then the PAM's mass and friction slowly bring the PAM to a stop. - REAL slowly, depending upon mass (which can be adjusted as a PAM nears its move-destination). 

I repeat this... mass values can be changed WHILE the PAM is linearVelocity-moving.  THIS might be easier for you... than creating "gravity wells" around the PAM at move-time.

  ALSO... consider this.  A PAM with a continuous applyImpulse or linearVelocity from the bottom ... can LIFT the PAM a bit, and thus... reduce its friction against ground.  *shrug*  AS the PAM nears its move-destination, reduce the bottom-side thrust, and the friction will start increasing (but not for spheres... see below), bringing the "slightly-floating" PAM to a stop NEAR its intended destination.

No promises, though.  Davrous' new move-the-PAM modifications... MIGHT change all this.

In OTHER situations... SOME users have placed invisible PAMs at the destination point, and the moved PAM collides with them, and stops (sometimes with a small amount of bounce/restitution/recoil, unfortunately).  Stopper mesh.    

But sometimes, the users "register an onCollide function" on the impostor.  THEN, when the moved PAM collides with the invisible "stopper PAM", they immediately kill energy (in their added onCollide func)... to minimize recoil from the impact (and to sometimes change mesh color upon impact).  UNFORTUNATELY... we have seen indicators that these registered onCollide wedge-in functions... don't trigger on EVERY collide.  SO, we have seen inconsistency in using the registered onCollide.

A recent ping pong table/paddles project was undertaken by user @Abdullah, and you can find my posts about THAT onCollide inconsistency problem... by doing a forum search for 'onCollide'.  (Just read the first 5+ returns that were posted by me.)  In that project, we could easily see the inconsistency of the physics-registered onCollide... as the ball bounced across the tabletop.  SO... I'm not sure if a physics-registered onCollide is a good way to determine if a visible PAM has collided with an invisible (movement-stopper-) PAM.  (or for any other reason to monitor-for physics collisions)

Perhaps, setting restitution to ZERO on the moving PAM and on the invisible stopper-PAM... would eliminate any "recoil" from the collision, with no need to register an onCollide on the impostor.  No color-changes-upon-impact that way, though. 

There's one last thing you should know, which was also taught to me by Fenomas.  Spheres do not have enough surface-area-contact with the ground or other flat surfaces... to have any significant friction. 

Then physics pro @RaananW taught us that we can do something like... rollingball.setLinearVelocity *= .99   ...  INSIDE the renderLoop.  There's more to it than that... but perhaps you understand.  You want to slowly reduce all three Vector3 linearVelocity values... by a small amount in each renderLoop... until all three axes-forces are at 0.  The ball has stopped... due to... "fake friction" or "wind resistance".    Otherwise, them darned sphere impostors roll and roll and roll, no matter their mass, and no matter their friction.

Okay, how's that for a pile of TOO MUCH INFO?    Do you have a brain tumor, yet?  I hope not.  The good thing about all of this... the experimenting is usually pretty fun.  But these "anomalies" can sure cause hell for a production team on a budget, eh?  Sorry.  We're still blazing webGL trails and discovering new horizons, and perhaps YOU could discover the "breakthrough" that changes it all.  Please share your discoveries, when/where you can.  Thanks!  Make suggestions (and actual edits) for the physics docs, too.  We can use all the documentation and test-case help we can get.

And of course, write back, here, or in new forum threads... we're here to help.  We don't ALWAYS have the answers, but we usually have some ideas.  Be well, party on!

@Jaskar - thx for the likes.  It's good to see you again!  I hope things are going good for you.

[JackFalcon]

@Wingnut phenomenal.

Same page. Info is spot on. Thanks for insights.

Can run new experiments off link:

            // kill all positional movement
            sphere.physicsImpostor.setLinearVelocity(new BABYLON.Vector3(0,0,0));       
            // kill all rotational movement
            sphere.physicsImpostor.setAngularVelocity(new BABYLON.Vector3(0,0,0));       
            // kill the pad rotation with by 'newing' its .rotationQuaternion.  Goofy, but needed.
            ground.rotationQuaternion = new BABYLON.Quaternion();

 

Cheers,

[fenomas]

4 hours ago, Wingnut said:

Physics pro @fenomas had an interesting idea for force-moving PAM's... too.  I've never tried it.  He said... loose quote... "It might be best if you use a physicsJoint to attach the PAM's impostor... to another .visibility = 0 PAM (possibly positioned directly above the PAM you want to move).   Then move the invisible PAM (not the visible one), and let the joint pull the visible PAM... to the new position."

Whoa, a shoutout!

But yeah, if you need to control a simulation (other than by applying forces and impulses), you almost always want to use joints rather than manually changing a body's position or velocity. Like, if you want to drag a body around with the mouse, you should make the mouse move around a static anchor that doesn't collide with anything, and then attach the anchor to the body with a joint. 

Incidentally Jack, if you want to keep a character from rotating then you probably want

player.physicsImpostor.physicsBody.fixedRotation = true

(or whatever the current syntax to access a physics body is).

[JackFalcon]

Thanks @fenomas. I'll give it a try.

[JackFalcon]

SOLUTIONS:

Just wanted to feedback on the two solutions related to above:

A. for the links -> Looks like Playground  v3-alpha has the version dropdown with 2.5 populated. Thinking that will gradually give playground links that would work in this case. If I'm not mistaken?

    - Playground Search link was a big help: https://doc.babylonjs.com/playground I will try to PR update on docs there.

B. for the original physics query -> here is final variation that stopped the cannon character spin (used = new quaternion, as well):

    scene.registerBeforeRender(function(){
        if (characterMesh){
            characterMesh.physicsImpostor.setLinearVelocity(new BABYLON.Vector3(0,0,0));       
            characterMesh.physicsImpostor.setAngularVelocity(new BABYLON.Vector3(0,0,0));       
            characterMesh.rotationQuaternion = new BABYLON.Quaternion();
        }
    });

Other steps remain...

 

Thanks gents,

[Wingnut]

VERY cool pinball thingy!  hahaha... excellent! 

I forgot to tell you ONE thing... in my last barfing.  Physics engines have a "step" speed that can be adjusted.  It is my "theory" that this step speed changed... when the 'new' term was removed from that Oimo constructor.  (not a ghost)  heh

All in all, I don't know very much about this step speed... but keep an eye-out for it... as you tour physics playgrounds.  You can also cause a step... with physics world.step()... inside the render loop.  Tweaking the physics engine step speed...  has been known to have powerful affects.  (Wear safety gear, please) 

So... umm... have you thought about HOW to replace the non-physics-engine-based moveWithCollisions() ?

In theory, you should be able to translate your mesh to any position, using applyImpulse or linearVelocity, within a "smart function" - a continuously-position-monitoring function. 

Essentially, computer-controlled thrust management.  This function would thrust HARD, and brake HARD, too.  With some serious mass on your character, you will get automatic ease-in/out motion, too.

Perhaps, in a continuously-updating func, keep adding more forward linearVelocity... until half-way to destination.  Pseudo:

var changeAmount = new BABYLON.Vector3(xAdditionalThrust, yAdditionalThrust, zAdditionalThrust);
linearVelocity.addInPlace(changeAmount);  // until halfway

When half-way...

changeAmount = changeAmount.negate();
linearVelocity.addInPlace(changeAmount);  // until all axes are zero - mesh stopped.

In theory, the mesh should come to a stop at the destination.  That's one way to do a mover.  No stoppers and no joints needed, but you need great thrust management.    See our light.setDirectionToTarget for a line of code that creates a directionVector between two worldspace Vector3 .positions (it's a vector3.subtract thing).  Good luck.

[fenomas]

2 hours ago, Jack Morris said:

characterMesh.rotationQuaternion = new BABYLON.Quaternion();

I think you might want to steer clear of doing that - overwriting the mesh's rotation just makes the mesh render un-rotated, regardless of whether the simulation underneath thinks it's rotated. So if the simulation goes wonky later, that line may make it harder to figure out why.

(Of course if the character in question is a sphere or something you may not care if the model rotates, but...)

[fenomas]

1 hour ago, Wingnut said:

Physics engines have a "step" speed that can be adjusted.  It is my "theory" that this step speed changed... when the 'new' term was removed from that Oimo constructor.  (not a ghost)  heh

All in all, I don't know very much about this step speed... but keep an eye-out for it... as you tour physics playgrounds.  You can also cause a step... with physics world.step()... inside the render loop.  Tweaking the physics engine step speed...  has been known to have powerful affects.  (Wear safety gear, please).

Let me try to de-mystify this.  

Imagine you're driving in a car that only moves when you close your eyes. The only way to drive such a car would be in small steps - first you'd close your eyes and let the car move forward a bit, then you'd open them, pausing the car, to correct your steering, and then you'd close them a bit more, etc. The implications of driving a car like this would be:

1. Opening your eyes more often makes it easier to ensure you stay on the road
2. But the more often you open your eyes, the more the car is stopped, so it takes longer to get anywhere
3. On a straight road you can get away with closing your eyes longer, but but on a curvy road you'll need smaller steps

Stepping a physics engine works exactly the same way - first the engine blindly moves the simulation forward a bit, then it pauses, opens its eyes, and tries to correct anything that's gone off track. And as in the previous analogy:

1. Smaller timesteps always make the simulation more accurate
2. But smaller timesteps mean you must step the engine more often (assuming you want it to run at real-time speed)
3. Simpler simulations can get away with longer timesteps; more complex scenes will need smaller ones

Hope that helps take the magic out of things!

(Note though - all that theory is just for explanation. As a practical matter, since Babylon steps the physics once per render, almost everyone should almost always use 1/60 as their timestep, or else they'll effectively be running their physics in slow-motion or fast-forward. So when advising beginners, I'd encourage you to just tell people to set the timestep to 1/60 (if it's not set that way by default) and never ever touch it.)

[fenomas]

Last one  

2 hours ago, Wingnut said:

In theory, the mesh should come to a stop at the destination.  That's one way to do a mover.  No stoppers and no joints needed, but you need great thrust management. 

If you do this, you'll effectively be rolling your own ... ahem, implementing your own joint constraint.

(Which you can do, of course, but the scene will be more stable if you leave constraints to the engine - it can solve them more accurately because it knows about all the constraints in the scene, whereas your thrust management logic would just be trying to solve one constraint in isolation.)

[Wingnut]

hahaha... ahhh... rolling your own. 

Oh yeah, I completely forgot about constraints!  Yep, yep, yep.

And yeah, I sort of understand steps... because of particle update speeds for particleSystems.  But, for others... nice explanation, thanks for that.  Well-worded.  A fine on-the-fly tutorial writer.

Constraints.  Sure.  SliderJoint with constraint... moves a set distance.  You bet.  Good reminder! 

Invisible stoppers?  pffft.  Old school, eh?  It's a miracle my computer doesn't use vacuum tubes.    Or worse - steam powered.

[fenomas]

Yeah. The key to understanding physics engines - the thing the tutorials don't mention - is that real physics engines are about 10% physics and 90% constraint solving.

That is, it's really easy to move a thing around and and solve collisions between it and static objects - that's why "mesh.moveWithCollisions" can be done in a few lines of code. But once you have two things moving around, then solving one collision can create another - at which point the problem stops being physics and starts being constraint solving.

And this is why moving things around is best done with joints. When you move something around with a joint you're giving the constraint solver a constraint, which of course it knows how to handle. When you manually change a body's position or velocity, in general you violate constraints that the solver thinks it already solved, which is something it's not well-equipped to handle.

[Wingnut]

Cool, thanks.  Yeah, even if we needed a "custom constraint", start-with a base constraint-class object, and customize from there.  Even use equations (force rules) for it... that start-with base equation-class.  The engine is already familiar-with (and likely optimized-for) those things.   

Yep, yep, yep.  Good tips.  (Above links are for CannonJS.  I haven't seen an OimoJS api, yet... but I have an older "thing" that helps.)

[gryff]

12 hours ago, Wingnut said:

It's a miracle my computer doesn't use vacuum tubes.    Or worse - steam powered.

You could have worse Wingy - a hand cranked version

Mind you, the Lovelace Foundation is no longer providing updates to the algorithms - so use at your own risk

cheers, gryff

[JackFalcon]

All suggestions above correct. Gr8 analogies (lol), de-mystification of ghosts and magic >> 1.  

Yep, considering HOW: DirectionVector, matrix subtraction,negation, joint experiments... now, thanks!  

Catching up (gradually). Next part really cool. You might like...

Thinking Physics Constraints might be...

sphere impostor {mass:0.1,restitution:0.1,friction:0.1}

With effect of smart function

I will (tryto) create a playground...

Cheers,

 

[Wingnut]

The smart function was a "retarded wingnut idea" and was superseded by constraints and springs and similar.  Wiser, especially for punching bag/bop toy.

I think these physics engines have MOST of the tools to cover our wildest physics imaginations - already built-in.  Familiarizing and experimenting... I think that's what you and I both need, JM.    I DO really like your spirit, though.

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

Keypresses do that auto-repeat stuff, so they are somewhat good for repeating tiny impulses... which can be cumulative (mesh goes faster, the longer the key is held).  OnKeyUp, crank-on the friction, but maybe not mass... as mass == inertia, too.  Mesh might become MORE difficult to stop at keyUp... if mass gets increased at keyUp.

Test test test, you know.    Try it all.  I imagine you are finding TONS of broken physics playgrounds, though.  SOME may begin working if you choose version 2.5 (at top of playground).

I should go on a physics playground updating mission.  Big job.  I would probably make about as much progress on THAT... as I have with my labels tutorial (which is actually getting FURTHER from completion each day, quite an accomplishment for a project).  I am making good progress toward non-completion.  heh. 

Some of our best physics demo-making people... are actually MISSING.  There's rumors that they are all in mental institutions, now. 

[JackFalcon]

On 4/20/2017 at 7:45 AM, Wingnut said:

On 4/20/2017 at 9:54 PM, fenomas said:

And this is why moving things around is best done with joints. When you move something around with a joint you're giving the constraint solver a constraint, which of course it knows how to handle. When you manually change a body's position or velocity, in general you violate constraints that the solver thinks it already solved, which is something it's not well-equipped to handl

This is really well stated @fenomas, as wingnut said. Thank you. And thank you again @Wingnut. Very helpful. 

[JackFalcon]

@Wingnut, Lol.... all good.

I will make a run at converting local work into Playground Physics Experiments. : )

And if BeforeRender upward-orientation x&z rotations breaks constraints solver - cool to know. Worth a try. Will let you know...

It didn't work.

 

Bottomed out at Sphere Impostor radius seems to be much smaller than imported mesh.