According to the way an Articulated system should be designed, it seems that the base joint has to be connected to a static node and the root Dynamic Node.
In my system, I have 4, dynamic nodes connected to each other [L0]-.-<J0>-.-[L1]-.-<J1>-.-[L2]-.-<J2>-.-[L3]. But I need [L0] a Dynamic node to be connected to a StaticNode with one more joint…
- How can I do it in JmePhysics, since a Joint now can connect only two Dynamic Nodes, or a single Dynamic node…?
setAccuracy fixed my Jitter with the joints… I had to set the accuracy to (.001f). Also once I did this I had to reduce the magnitudes of all the AngularVecocities I was applying also…
How would you find the current accuracy? I haven't been able to locate the variable or a getAccuracy() method.
Connect it to the single dynamic node. The other "end" of a joint, attached to only one dynamic node, is attach to the static environment.
Thanks… that removes my confusion…
Also since you are looking at this… I have one more question regarding this joints…
My articulated charcters when totally falls onto the ground like dead weight, whne I zoom in little closer to it. I see that all the joints are not stable, they continusly jitter and its welll noticible? Seems like the system is not stable and about to explode…
The only difference I see against the "Simple RagDoll example is " it uses node.generatePhysicsGeometry(); where as I use node.generatePhysicsGeometry(true)
- What might be wrong in my setup? I have all Rotational Joints, constrained in Z axes
- Do you think its is some thing to do with he way, by bounding volumes are setup?
- Or it might be the problem with time step? I basically modified the same Ragdoll… :?
-Thanks in advance…
You can increase the accuracy (smaller time steps) to avoid that jitter, yes. Generally using trimesh accuracy (generatePhysicsGeometry(true)) is less stable and slower than using boundings. You can also play with the auto disable feature to get the doll rested.
It's possible that you cannot read it.
Okay then, I assume because of permissions (private, protected, public). Out of curiosity is the default accuracy 0.01f?
It's implementation specific. Have a look with the debugger or in the source of OdePhysicsSpace (if you're using ODE impl).
Maybe in 2.0 you could have a setAccuracy() that sets a percentage variable, then the implementation could do whatever the heck it wanted and we could still (safely) manipulate it with ease. But then again if no one uses it, there is no point.
Thanks for the suggestions I will take a look.
Hmmm thats sounds good, I will try that and see
Thanks for the info so far [irrisor, and basixs]… I like this forum, ppl are so helpful :mrgreen:
Take a look at your framerate drop now
That is going to tax the processor pretty hard, I am pretty sure the ODE default accuracy is 0.01f. I switched mine to 0.008f and it causes a noticeable drop in framerate.