Orientation to floor

[MashOMatic]

I'm new to BEPU so sorry if this is a common question I can't find the answer for, perhaps i'm looking for the wrong thing.

Anyhow, I have a Spider mesh with a walk animation and I can get BEPU to make it sit nicely on my terrain (and walk around etc) what I want to be able to do is manipulate the spiders world matrix to make it "sit" on the ground when the ground moves up & down with the terrain. I guess I need to find the angle of the ground where my spider is currently sitting ( is this ray tracing?) and rotate the spider to match? Can anyone point me to an example to some clues on what to search for.

Thanks for any help possible.
Alan

[Norbo]

I assume that this is the general situation you're dealing with:

surfacefollowing.jpg (100.89 KiB) Viewed 12239 times

If dynamic entities are left to rotate all by themselves, the right option will occur. In this case, additional logic isn't needed to get the objects to eventually align with the surface, but they will act like what they are- tumbling and sliding physics objects.

By locking the rotation of the physics entity, you can get the left option. This can be done by setting the desired rows representing the axes of rotation or all of the LocalInertiaTensorInverse to zero. In this case, the entity WorldTransform will never have a different orientation unless you change the entity's orientation directly.

For the graphical effect of latching the mesh orientation to the ground, you could either look at the contacts of the entity with the ground (each pair in entity.CollisionInformation.Pairs has a Contacts list) to check for the normals, or ray cast ("ray tracing" typically refers to a graphical method) the ground from the object's position. The normal you get from either operation can then be used to compute an orientation. There are a variety of ways to do this computation. Remember that a single direction does not uniquely define a rotation, so you'll need to make some choices. One simple way is to use something like the Matrix.CreateLookAt.

In the end, this would just be a graphical effect on top of the locked entity rotation. I would not generally recommend trying to nonphysically rotate an actual entity to match the surface every frame. This amounts to teleporting the object and interferes with regular physical motion and collisions. If for some reason the collision geometry and physics of the actual entity need to rotate arbitrarily, consider going the full physical route- maybe use a vehicle or something.

[MashOMatic]

Thanks for an awesome response, I'll go and have a play with my code and see if I can work it out, but it does sound good that I may need to do very little to make it work. I'm new to this kind of code (I'm a database developer by day (boring)) but I'm learning quick.

I'm using some demo code from SynapseGaming as a start point so much of the BEPU is already in place but I need to get my head around how it all works.

Thanks again, I'll be back.
Alan

[cjhazard]

Hi Norbo,

I have a similar requirement so I'll join this thread if no-one minds.

My terrain is pretty flat so I just want my character to stay upright at all times. Therefore I set the LocalInertiaTensorInverse to an empty matrix....

Entity.LocalInertiaTensorInverse = new Matrix3X3();

However, I find that while the character remains upright while moving, once I stop he falls over. Am I doing something wrong?

Thanks.

[cjhazard]

Ah... just had a thought... could it be some residual angular momentum causing it to tip over?

[Norbo]

Ah... just had a thought... could it be some residual angular momentum causing it to tip over?

An entity with infinite inertia cannot change velocity due to collisions, so some pre-existing velocity is indeed most likely the culprit. Either that, or its velocity is being changed directly.

[cjhazard]

Ah! I'm setting the LinearVelocity property in order to move my character. Is that not the correct way to do things?

I'm sure this must have been discussed a thousand times so I'll try searching a bit more. If you can point me toward an appropriate thread that would be great!

Thanks again.

[Norbo]

Using LinearVelocity is fine and recommended. However, if the entity has a nonzero AngularVelocity prior to having its inertia locked, it will still have a nonzero AngularVelocity afterwards. It will tumble forever or until damping removes the velocity.

However, no impact or constraint will change the angular velocity after the inertia is locked. Only setting the AngularVelocity property will have an effect.

[cjhazard]

Hmmm... I'm a bit confused then because locking the inertia is the first thing I do so I wouldn't expect there to be any residual angular velocity. Yet when I move the character by setting LinearVelocity it falls over when I release the control (i.e. stop moving).

So to clarify, I:

a) set up a box prefab.
b) set the LocalInertiaTensorInverse to Matrix3X3().
c) Move the entity by setting LinearVelocity when a key is pressed.

When I release the key, it falls over.

Thanks for your help.

[Norbo]

It sounds like something is interfering and resetting or forcing a recomputation of the inertia. If BecomeDynamic is called afterward without explicitly specifying a locked inertia or relocking the inertia, it will end up with an unlocked inertia.

[Norbo]

By the way, I'll be locking the forums briefly and moving them over to a new host in a minute. Might want to hold off on posting until the forums at http://bepu.nfshost.com/forum (a temporary domain) are up and running.

Edit: The transfer is now done!

[cjhazard]

You might be right.

Should I have to set LocalInertiaTensorInverse every frame? Because if I do then it works correctly. Like you say something must be forcing/resetting a recomputation of the inertia. I'll dig a bit deeper. It might even be something like I'm setting BecomeDynamic every frame accidentally.

At least I now know I'm moving the object in the correct way.

Thanks again.

[Norbo]

Should I have to set LocalInertiaTensorInverse every frame?

Just one time should do it.

[cjhazard]

Sussed it! Well I wasn't calling BecomeDynamic every frame, but it turns out it was being called (accidentally) after I had set LocalInertiaTensorInverse and so recomputed the inertia. I just shifted the inertia lock to happen a bit further on and hey presto, it works!

Many thanks Norbo. What would we all do without you?!