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.
Well I fixed it. How I fixed it makes no sense to me.
The tutorials say,
•Set the mesh’s origin point in the bottom of the mesh (see the image below).
•Set the armature’s origin point in the bottom of the armature (see the image below).
I deleted the root bone and set the armature and models origin to center on geometry. Now my model works perfectly.
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.
What’s really dumb is I knew better than to update from anywhere other than AbstractControl, BetterAppstate or SimpleUpdate and I still did it anyway without realizing it.
A bad java habit of do what you want, where you want, how you want.
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).
Well, the total outcome of that thread isn’t dumb at all. We’re getting very distilled knowledge here on forum, that saves huge amount of time, even in response to very basic questions sometimes
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.
