I see that the physicsbody attached to the joint swings forever.
I would expected it to slow down eventually…
Is there anything I can do to achieve that?
Thank you
p.s. Please mention somewhere in the documentation that jointData.mainPivot and jointData.connectedPivot are the offsets with respect to the two object centers, because from documentation this is not clear at all!
Good to hear from you
Yes now that I look more closely, I see that actually both Oimo and Ammo show some “damping” effect eventually, Oimo being more pronounced, but still incredibly tiny.
Cannon on the other hand stops almost immediately before even completing a half swing.
So my question would be, what is the property that controls that damping effect? I suppose it should have to do with air friction and possibly joint friction itself, although I don’t see how to control either of those…
Each engine defines joints and interactions a bit differently. Ammo has a lot of parameters and configuration variables (that i am sadly not familiar with). These are the default ones. I am sure you can define the damping in a better way. Cannon has a thing with joins and collisions. I remember i fixed it, but it looks present in this example. And Oimo is oimo! (fast, works, but who knows what will happen )
Cannon doesn’t have the hinge2 joint, so it is using the hinge joint class. Might behave differently
Also - those joints are motor enabled. So you can actually use it to slow the mesh down a bit:
The motor looks cool. I can definitely see uses for it but unfortunately I won’t apply much to what I am trying to achieve right.
I need to assemble a chain (a necklace actually) and the way I thought of is to have each ring connected with a joint. I think it could work, but I definitely need to limit the swinging between each ring otherwise it will look like a metal worm having a seizure
I see what you mean, but that is not what I am looking for. Allow me to expand on this.
When a ball is dropped on the floor it doesn’t bounce forever. It bounces less and less and eventually stops. The physics engines already take care of this nicely.
Same goes for an object sliding on the floor. I see that this too is taken care of by the engines, namely the object eventually stops sliding.
Now for joints, a pendulum in real life doesn’t swing forever, eventually it comes to a rest. I am very surprised to see that none of the 3 engines takes care of it. That pendulum in my example is basically a perpetual motion machine. Which… should not exist.
So what you are suggesting is to add something that we know works, which is force applied to an object in the opposite direction (bouncing, sliding) and “patch” the angular velocity of the 2 impostors with it.
Translating your suggestion to the bouncing ball, it would be like setting “damper” objects that move closer and closer to the ball to limit the height it can bounce at.
I mean, I guess it would work, but, bloody hell…
Having “googled” this quite a lot already, and found pretty much nothing I went ahead and added a brutally incorrect yet visually functional drag force to the pendulum. https://www.babylonjs-playground.com/#0GLP59#4
Now this looks right ish. But it is obviously not right . And no matter the effort I might put in I will never, ever get it actually right. I know nothing about physics. So I really would not wanna have to go down this path.
Now, sorry if I insist on this, but I just cannot believe that all 3 engines implement a physics world that is basically set in vacuum. Is every user then implementing their own limited/wrong version of drag force? Again… weird.
Is there anyone from the forum whom may have some experience with this I could try and bother?
https://www.babylonjs-playground.com/#0GLP59#3 My version is prettier.
I deleted the post where I told about it. You figged it fine on your own… in version 4… using linearVel instead of my angularVel. Both work.
Yuh, physics engines never claimed to be “oxygenated Earth-life simulators”. If ya want the winds to blow, code up the winds. Air molecule modeling and airfoils/aero-dynamics are certainly allowed to be simulated, but that would be leaning towards fluid dynamics sims. Got Cray?
Yes yours looks better Less code as well so a win win.
You shouldn’t have deleted your post, it would have saved me the trouble to figure that out on my own!!
Seriously though, so this is the way to go? Do it myself?
Having never before worked with physics engines, other than little experimenting with Unity3D, I was under the possibly wrong impression that they kinda did. As in, they would simulate physics behaviours most commonly found around us. So “air friction” to be there out of the box, possibly as a variable to be tweaked, like gravity.
Ok, I am a little disappointed now
But if this is indeed the way to go, then at least I know what I have to do…
Try not to lose sleep over it. It’s just damping… easily update-able later, as new systems arrive. The “poke 99% of peek” method (also called Raanan’s Leather Boot)… is universal… across all three of our honored physics engines/plugins. SO, if you want to change physics engines later, the damper comes along… working fine.
You MIGHT want to do some performance profiling… to determine if state-testing would improve your use-case: if (!imposter.isSleeping) or maybe if (hasVelocity(impostor)) (hasVelocity would be a is it moving checker-func that YOU code).
You know… maybe test isTheThingMoving? before doing a ‘poke 99% of peek’. Maybe not worth the perf-bother. Setting a zero velocity impostor (poke)… to 99% of it’s current value (peek)… continuously, in the render loop… probably not a big deal… unless you’re doing it to 100000 impostors.
You did a “wide-reach” with your #4 playground… with physicsEngine.getImpostors(). Whole-scene air-damping… nice. I wonder what the “under-water” setting would be.
I like the setMotor(0, small value) trick. Pretty clean.
On the downside I have no idea why it works, and it is Ammojs specific. Also I don’t understand the relationship between smaller max_force and smaller ang force damping. I would expect the opposite.
@Wingnut Yes I see the point about not adding extra work willy nilly on all scene impostors, but that is something for production. Here I am faaar from it
Also, air is everywhere, so whole-scene air-damping kinda makes sense if you think about it. Under-water would be less then 99% I guess? (of course not, fluid dinamics is a far scarier beast than that).
Now, I have updated the demo adding joints - because ultimately I am simulating a chain (rings with hinge joints) and I finding that the damping effect on angular vel get more and more inconspicuous as joints are added. Same goes for the setMotor trick.
Also, I had to increase the PhysicsEngine calculation frequency quite a lot because at its base value it almost unbearable to watch, it looks like a slowmotion video from youtube.
If you can still be bothered with this, does it make sense to you that angular velocity damping is pretty much neglected when a few joints are chained? Linear velocy damping doesn’t seem affected by it.
Nod… I did the same thing… back when I messed-with bead-chains. I increased the physics step speed in line 42.
But yeah, the shapes attached-to ends of hinge joints… are affected heavily by the shape hooked to the other ends. ie. shapes being attached above and below another shape… certainly affects motion/damping.
By now, you understand that mainPivots and connectedPivots… have values that are “localSpace” to the shapes (on each end of the joint). So, tiny adjustments of y-values of main/connected pivots… can likely have quite a bit of affect on the behavior and damping of the entire chain.
And, of course, link mass, too. Dog chains… wiggle pretty easily. Logging chains… not so much.
Have you tried using Ammo’s rope impostor, yet? https://www.babylonjs-playground.com/#CFL148#36 I’m probably using it wrong… but talk about SLOW! omg. It’s like watching old people eat. lol.
https://www.babylonjs-playground.com/#0GLP59#5 Your Ammo chain there… works pretty well. I’m bookmarking that puppy… nice work. Notice how that last link… acts differently? nod. No shape hooked to its bottom… so maybe double the mass on THAT puppy.
I shortened the conn-piv point in line 39… to -0.5 and ran it again… with “tight gaps”. I also set collisions = true in line 42. https://www.babylonjs-playground.com/#0GLP59#6 The chain looks a bit “stressed”. hehe. Fun!
Locally I am actually using ring meshes imported from Maya instead of crude boxes; that definitely helps in giving more realism. All in all the effect for now is acceptable enough to move to the next phase and start building the more complex stuff of the project
Ok so given your hint about the pivots (your demo looks like a worm with a seizure struggling to lift itself up ) I have tried a few values and that does make quite a difference in how the joints behave, swing-wise and damping-wise too.
I don’t have much of a choice with that because rings make only sense when attached at the extremities, but that’s ok.
Nice one! Didn’t see that yet. It will definitely come in handy later when I will have to sim a… rope
I was already looking at the tube parametric mesh, dreading the time when it will need to move under physics like the chain
I see in your demo you are using setPhysicsLinkWith rather then the whole Joint thing. Is there any reason for that? Would that be the equivalent of some Cannonjs joint?
Yes, and btw, I understood that “the hard way” (trial and swearing) because the documentation is super cryptical about it. Nowhere it is mentioned that pivot are offsets in local space…
Old old stolen code… from the original Oimo demo used to “introduce” Oimo… for BJS users. Very stale, old… rusted. Generally, I never code stuff… only steal others’ code. (did I cover my butt?)
Cool… you’re rolling. I hope we all get to all see your physics chain someday. Will the chains hold pretty clickable wooden signs that blow in the wind, in a nice xmas scene, perhaps? Or maybe hang some bleeding-out gut-drying moose carcasses… keep them out of reach of the wolves? Just curious.
A long time ago… I tried 4 button-signs… hanging from each other by hinge joints. I bailed eventually, but… it was fun for a while. GUI changed systems at that time, and I lost interest in the “button-signs hanging by twin chains” endeavor.
Dragging MeshWriter fonts (sps particles)… attached-to chains of sphereImpostors… across physics-active heightMap… with a standard particle sprayer at the end of the chain. What kind of sicko tries stuff like that? And without a helmet! heh. Ahhh fun.
maybe 
)
Less code as well so a win win.
) I have tried a few values and that does make quite a difference in how the joints behave, swing-wise and damping-wise too.
