Physics - applyAngularImpulse()

[gopher]

Hi awesome BJS people, thanks for this awesome work! I had a quick question about applyAngularImpulse(). It seems to be missing!

I can produce similar results by two applyImpulse() at an offset in opposite direction or by setAngularVelocity() or by using a joint and setMotor() but it would be great to have applyAngularImpulse().

[RaananW]

That's mainly (or better yet solely) because both physics engines we are working with don't really support it

setAngularVelocity is your friend in this case. I know the physically speaking, it is not the same. But this can be easily emulated with the setter. 

A better choice would be, as you wrote, using motors, but this is a bit more complex and sometimes a bit too much just to rotate an object.

[Wingnut]

Hi gopher, welcome to the forum!  Thanks for your kind words/thoughts!  Thx for reply, Raanan!

    Yes, I've used the double-impulser method, AND the setAngularVelocity... both work fine.

Gopher, if YOU were to code-up an applyAngularImpulse() function, how would YOU accomplish it, programmatically?

What would you do... inside that function?   Perhaps use setAngularVelocity?  Or maybe use a dual linear impulser (a twister)?

I think you'll find... that you would simply be "wrapping" setAngularVelocity.  It can be done... of course, but I'm not sure how much it would be used.

It is pretty simple to make your own, inside your project.

On a related topic, I am working on a physics scene myself, and I decided I needed some "tools" (widgets).

https://www.babylonjs-playground.com/#1ND6TH#57

The little PULSing ARrows are called Pulsars.  The little rotation widgets (with 6 click-zones on each) are called Quasars.  (QUAternion Symmetrical Axial Rotaters).

Although nobody has shown any excitement over them, nor is there any push to create a PhysicsTools library, I like them.  They are handy, imho.

Perhaps you would like to use them in your projects.  Freely use them, improve them, do whatever you like with them.  All required code is inside that PG.

PS:  Using a motor, it would need to be turned ON, and then instantly turned OFF... to sim a rotational impulse.

[gopher]

@RaananW Thanks for explaining that. Interesting that the physics libs doesn't support that (API feels a bit incomplete to me without it). Maybe it is less used by game developers or maybe angular velocity is easier to work with for common scenarios.

@Wingnut  Cool demo! I think that it can be implemented if needed using either methods. A pair of impulses or by adding to the angular velocity.

In the first case, we can calculate change in angular velocity assuming we know the change in angular momentum we are after (based on the desired angular impulse) and the moment of inertia of the body (I assume this is available already from the underlying physics objects or we can calculate this for simple shapes easily). change_in_angular_momentum = moment_of_inertia * change_in_angular_velocity.

In the second case, we can apply two co-planar linear impulses perpendicular to and at an arbitrary non-zero offset to the axis of angular impulse in opposite direction. The magnitudes of each of the impulses can be calculated as 0.5 * angular_impulse / offset.

In my case, I went with the second option as I can calculate my axis and points of application easily. Having an applyAngularImpulse() would be very handy however for general cases.

[Wingnut]

15 hours ago, gopher said:

at an arbitrary non-zero offset

Yep.  And the amount of offset... is the "twist amplifier" 

https://www.babylonjs-playground.com/#PBVEM#160

HELD control-arrows apply dual-impulse 'twister' impulsing.  (It uses held-keypress natural repeating... to accumulate the micro-pulsings)

Control-pageUP and and pageDown WERE once operational too, but are now broken for some reason.

Control-numericKeypad +/- keys still works for that broken axis.

You can see the arbitrary offset in line 17.  Lines 164 - 510 are the 6 'twister' rotation funcs, documented at kindergarten levels (to remind me how they work, 4 years after initial coding).  I wrote that impulse controller when I was < 1 year old, BabylonJS-wise.    I would use an accumulating setAngularVelocity system... if I re-coded it these days.  I didn't know about setAngularVelocity back then... too noob.  heh.  All 6 twister funcs... could be done in a single func, of course.

Shifted arrow keys and shifted pageUP/pageDown are for translating the craft (translating its master parent/handle).

BJS-wide, all physics rotation is done with Quaternions and not Vector3 Euler.  (mesh.rotationQuaternion instead of mesh.rotation).  Notice the cool func at lines 157-163.  It is called in EVERY rotation and translation function.  If the craft is rotated at a strange angle, or inverted around some/multiple axes, THAT func lets translations STILL happen in the correct localSpace directions. 

That magic func is also called for setting the 'arbitrary offset' contact-points... for the rotations.  It is difficult to know which directions to set the offsets on the craft's handle, because it could be upside down or oddly rotated.  That function is used in the twisters... to make sure the arbitrary offsets are aligned along the correct axes on the handle/flyer.

A bit difficult to explain, but you seem to have a reasonably good grasp on impulse twisting, and translating-per-current-'quat-rot'. 

The first 650 lines of code... are all controller.  Jquery is used, and 3 different areas of the keyboard are allowed to control the craft (arrow keys, numpad keys, and around "L" key).  Gruesome.  Serious over-kill.

I bet a guy like you could code a much better impulsing controller.  My controller was also ready for 24 thruster ports (3 on each corner of the craft), and their particle systems.  It actually all started... with the flying bedframe...

http://urbanproductions.com/wingy/babylon/thruster/t26/flyer26.htm  [zip, slightly fresher]

(Yay, now we have some buttons to click/hold.  All previously-mentioned 'hot keys' are also active.) 

You can see the 24 thruster ports and their particle systems, there.  There's 4 particle systems available on each port, one for fire, one for smoke, one for soot, and one for ice particles.... for a grand total of 96 particle systems.  WOW!  Overkill extraordinaire! 

hehe.  The grand intent was to allow users to parent ANY model to the 'flyerframe'... and instantly make that model into a flying machine.  I haven't ever finished, and there is little interest from others.  Someday, perhaps it becomes part of Babylon.PhysicsTools or something. 

At this point, now that you have seen the thruster ports on the ends of "arms"... you might be thinking IK (inverse kinematics).   It would be nice if the impulsing was ACTUALLY happening at the positions of the thruster ports, and that energy was transferred through the flyer's frame... and to its central 'handle'/mass. 

But no, there is no IK happening in the flying bedframe.  It's all faked, and all impulsing happens ONLY upon the flyer's 'handle'/parent, which is a simple box.  But wouldn't it be cool to have IK?  Yum!

IF impulse WAS actually happening at the thruster ports (IK), and you accidentally broke-off one "arm" (3 thruster ports) of the flyer, you'd have one hell of a time trying to get the flyer to fly straight, eh?  We might need to call a Jamie Davis heavy wrecker tow-craft... in order to get home.   

MacGyver type folk... would space-walk, and install a temporary repair, using a broomstick with 3 cans of hairspray duct-taped to it.    (Cans of hairspray work great for rescuing space-walkers that become un-tethered and float-off)    A "fishing reel gun" (with line tied to station) could also be fired-at float-away spacewalkers, and I had a Silly String rescue method almost invented, once, too.  (Like MY ideas ever get heard.)

It wasn't so dangerous when the space walks happened from the shuttle, because the shuttle could possibly 'fetch' the float-away space-walker.  But space walks that happen from the international space station... that's a different cup-of-tea.  Not much 'flying around' (fetching) allowed for THAT big pig. 

The flying bedframe is somewhat based-upon NASA MMU and SAFER systems (for spacewalkers), and upon basic 'flyer' satellites such as the Spartan.  Current space-walker SAFER units still use 24 cold-thrust (hair spray - heh) ports, I believe, and every space-walker wears one, as far as I know.

WAY more prattle than ANY of us really needed to know, eh?  heh.  I like this subject, though.  I like precision zero-G flying and gentle docking challenges.  I used to be a NASA TV junkie.

Can I ask... what you're planning/dreaming?  Something... space craft-ish, by chance?  If it's a secret, just ignore me.  In fact, you might want to ignore me, in general.  heh

[gopher]

@Wingnut Thanks for sharing! And not at all a secret. I am trying to simulate a combination of flight dynamics and orbital dynamics. Realism or correctness is not the objective but the movements should look appealing visually. It's a side project I am working on during my abundant free time and the objective is to see if I can evolve visually correct avionics with machine learning (NN, GA, RBM, etc.).

I don't need IK yet but I agree, IK would be great to have!

You seem to have a lot more experience building for space/flight. Have you done much lift+drag simulation (or maybe voxel based approximation)? My current thoughts are to apply a force proportional to the cross-sectional area opposite to the direction of movement to simulate drag for example, but that is a crude approximation. Voxels are much better but looks complicated to implement unless there libraries to help with that.

[Wingnut]

Cooool!  That's sounds great.  I haven't done lift or drag sims/calcs... but... lift is essentially thrust, mass and gravity, as you know.  Me...I need 3rd grade math and below. 

Some of the "hot" physics guys 'round here... were once talking about wind resistance, and how to stop spheres from rolling forever.  (Spheres have NO significant surface area with ground, so friction parameter is essentially worthless.)  They came up with the "multiply .99" method... where... in the render loop...  (pseudo code)

    if body has linearVelocity { linearVelocity multiplyInPlace( vec3(.99, .99, .99) ) }

You get the idea.  We constantly downScale the velocity vector.  (That sure is a pile of fancy words that I likely mis-used). 

Essentially, the above is a .01 drag. And that drag value can be constantly changing, of course (various scene conditions/locations). 

It's not .01 Newtons, it's... gopherUnits.    .01 gophers of drag.  heh.  I like it.  You just became famous, G-man.   

I say that for a reason... and I'm glad you don't want "scientific precision" and actual Newtons.  Some people get 'hung up' on trying to get scientific and micro-precise.  Although it is a fun "branch" to play-with, it can also bog and frustrate.  The physics engines are xxx precise and predictable, and there's a "good enough" line that should be respected, I guess.  I have troubles getting my "good enough" line to stay in-focus.   

"Abundant free time", he says.  hmm.  Allow me to introduce you to professional train engineer @JohnK - who drives trains for the "Doc Island Line" railroad.  (JK recently COMPLETELY overhauled our docs system, and he could use helpers to do proof-reads and test examples, as well as build a new thing called Playground Based Tutorials. 

All in all, learn and help-with our docs system if/when you get a chance.  (thx)

And... thanks for the peak at your plans!  Yep, you're either headed down Rocketry Avenue, or you're going to open a Frisbee factory.    I can smell it.  heh.  Maybe a helicopter builder.

Share whatever ya can... demos and conversations... we love that kind of stuff 'round here. 

[gopher]

I write code for a living but frisbee factory summarizes it really well

Rule 23: The words "abundant free time" is never used in that order together unless it implies sarcasm. I am just messing around with JS 3d and physics libs at this point but I will try to make time to contribute if I spend enough time/learn enough.

Scale by 0.99 is a perfectly valid trick. That said, although I am not after accurate numbers, I would love for the simulation to "look" realistic. I am wondering if we can derive a bit more detailed "air related" forces based on shapes+orientation+velocity so that a piece of plywood will not fall straight down through the air. I would like it to experience the "wrath of pseudo fluid dynamics" and be taken for a flappy ride. NB: Catching fire is out of scope for now!

I am not assuming this is a BJS concern by the way. In fact, it makes sense for it to be a different lib (or a class/piece of code). Maybe the forces returned from this can then be applied to the world to integrate with the rigid body physics? How would you do it @Wingnut?

Although not JS, this KSP plugin looks interesting: https://github.com/ferram4/Ferram-Aerospace-Research/

Drools about writing a small JS library of this kind. Lift and drag by themselves look simple enough to do for small assemblies but might need some work to generalize. Any takers?