I have extended a GhostControl that implements PhysicsCollisionListener to do terrain collision checks. I did this same thing with RigidBodyControl prior and had same results as follows.
Rigidbody is set to Kinematic = true with mass of 1.
The stock Sinbad model and Oto models perform as expected whether just adding the RigidBodyControl to the model and using a separate control to do the calculations and movement, if I extend RigidBody with a Physics listener, or extend a GhostControl with the listener and just add it to the model. They hug the terrain going up and down hills and mountains. All animations work fine.
I created a low poly model myself, first with no skeleton, just the mesh. It hugs the mountains and hills going up them but the motion is jerking like going up steps. The stepping conforms to the grid spacing when using debug. When the model reaches the peak of the hill or mountain, rather than hugging terrain on the downside the model just glides towards the next target.
I then rigged the model and same results. It always glides to the next target from the last highest point. This happens whether exporting using ogre or importing the blend file.
To do the testing between all 3 models all I do is simply change the assetloader to point to the next model so it looks like there’s something I am missing in my model that would make it work right. When I examine the models in the SDK everything looks identical except for vertices and triangles.
I have 1965 verts compared to oto at 3563 and Sinbad at 5534 is only major difference.
Not that anyone cares but I tracked it down to several things.
Extending RigidBodyControl implementing a PhysicsCollisionListener and updating the scene graph from collision override is stupid and a basic noob mistake.
Although you can achieve the desired results extending ghostcontrol this is also stupid, see number one.
If you use a PhysicsCollisionListener make sure your filter it down to only give you the results you are after at the start. I was allowing the spatial the control was added to into the collision results. Wasn’t affecting anything due to filtering the collision results except for unneeded processing but why even go there.
Pairing the PhysicsTickListener with the PhysicsCollisionListener and extending an AbstractControl is a better way to do it. Makes life so much easier.
Heh, if you want to see a “really dumb” moment, check out my ultimate blonde moment in the “Is PNG suitable for textures?” thread.
At any rate, I’ll be finishing implementing physics in my server/client soon, and I’m sure the “bottom line” you found here will be useful to know - especially since the server isn’t a jME app (the physics come from direct use of the PhysicsSpace, and I handle the ticks myself).
The resulting discussion was great - anytime @nehon and a few of the other posters in that thread chime in, you know you’ll learn something worth knowing. In hindsight, my initial embarrassment was well worth it… now I know that PNG is great for normal textures but not heightmaps and that I might be able to do on-the-fly DXT compression on hardware that supports it.