I noticed that there appears to be a difference in the transform values (position, rotation) returned between PhysicsRigidBody.getPhysicsTransform and PhysicsRigidBody.getPhysicsLocation / Rotation.
There seems to be some kind of small lag of getPhyiscsTransform being behind the current simulation step.
I thought getPhysicsTransform should basically output the same data as individual calls to getPhysicsLocation, just in another data structure.
In my case I thought it would be a little bit more efficient to just pass the whole transform directly from rigid bodies to spatials, because these operate with transforms anyways.
As of now I have only tested this with @sgold’s Bullet Physics implementation in his Minie Library.
I can’t say about your original problem but this premise may be off. A Transform is internally just a translation Vector3f and a rotation Quaternion. So at best, maybe you save one call to refresh the transform flag in Spatial… at the cost of either creating or maintaining your own (unnecessary) Transform object to pass things around.
PhysicsRigidBody.getPhysicsTransform() is Minie-specific; there’s no such method in jme3-bullet or jme3-jbullet.
I believe the discrepancies you saw are due to PhysicsRigidBody.getPhysicsTransform() extrapolating the location and orientation of the body between physics ticks. In Minie, getPhysicsLocation() and getPhysicsRotation() return the location and orientation as of the most-recent physics tick, without any extrapolation.
Thanks for bringing this up. I’ll investigate further and clarify the documentation.
Okay, thanks for the hint! Without looking to deep into the source I thought translation and rotation would be combined into a transform matrix before rendering anyways, so I was trying to avoid this step by passing transforms myself (from physics to spatials).
Ah that explains the difference, thanks for the info!
Maybe it would make sense to then rename getPhysicsTransform to something like getPhysicsTransfomExtrapolated? Or at least mention the extrapolation in the javadoc?
Because not knowing users like me could be confused
OK so I will stick to just using individual calls to getPhysicsLocation and getPhysicsRotation to poll physics state. Thanks for the help!
I am open to renaming methods and/or adding new methods, but first I want to make sure I understand exactly what the code is doing, both in Minie and jme3-bullet.
Feedback like yours is essential to improving Minie. Thanks again!
By the way: in jMonkeyEngine, a Transform actually has 3 components: translation, rotation, and scale. In Bullet, however, a btTransform has only translation and rotation. PhysicsRigidBody.getPhysicsTransform() reads not only the translation and rotation of the object, but also the scale of its collision shape. Which may or may not matter to you.
It’s your library and you can do what you want, of course… but I thought I’d mention naming just in case.
Modern convention is to treat methods as “verbs”. So in this case, getExtrapolatedTransform() or just extrapolateTransform()… with the latter being a better indicator that “work is being done” to return the value. Versus the former which most would consider is just returning a value that already exists (or close to it, assuming correctly or incorrectly.)
I prefer to reserve get-names for methods that return pre-existing objects, though in the context of Minie, retaining compatibility with jme3-bullet often overrides that preference.
In this case, the method doesn’t exist (yet) in jme3-bullet. I like extrapolateTransform() and will rename the method accordingly. Thanks for the suggestion, @pspeed!
