How to check if a box is colliding with the level mesh

[DoctorWhy]

I am trying to implement a simple jumping algorithm where I created a box that is at the bottom of the player to check if they are touching the ground. I looked in the Demos provided, and you do something similar, but with ray casting and seemingly more complicated. I just want to simply check if the box is colliding with the level mesh. If it is, the player can then jump. How do I simply check this?

[Norbo]

The entity.CollisionInformation contains a list of Pairs, and each pair in that collection has a list of Contacts. If there exist contacts which can be classified as supports, then the character has a support. Generally, for a contact to be classified as a support, it needs to be on the bottom of the character, have a surface normal which is sufficiently flat, and a few other tiny details that depend on the implementation (optionally avoid negative penetration depths to avoid speculative contacts, collision rules, etc.).

The SupportFinder classes used by each of the SphereCharacterController and the CharacterController use this approach and show how to handle the little optional details in the UpdateSupports method.

[Norbo]

I should explain the UpdateSupports raycasting, too. All of that is designed to provide support continuity when the character is walking around rough terrain or down steps. You don't need to include that part unless you seek to solve the same issues.

[DoctorWhy]

Does the collision with a mesh count as collision in the Pairs? Mesh created like so:

Code: Select all

            Vector3[] vertices;
            int[] indices;
            TriangleMesh.GetVerticesAndIndicesFromModel(levelModel, out vertices, out indices);
            for (int i = 0; i < vertices.Length; i++)
            {
                vertices[i] = vertices[i] * 10f;
            }
            StaticMesh mesh = new StaticMesh(vertices, indices, new AffineTransform(new Vector3(0, 0, 0)));

            //Same space the character ball is in
            space.Add(mesh);

When checking to see if a block is colliding with the mesh, Pairs.Count is never greater than 0, when the only thing it can collide with is the level mesh, even though I can see clear collision between them. The cube is created and positioned like so:

Code: Select all

//Create the collision box. Positioned based off of indicated camera up vector (this positions the object right below the character circle collision)
SupportCollisionBox = new Box(character.mEntity.Position - camera.up * 10f, 2,2,2);
.
.
.
//In the update method. Keeps the box below the player
SupportCollisionBox.Position = character.mEntity.Position - camera.up * 10f;

I add the SupportCollisionBox and a copy of the mesh into their own space so the box can only collide with the level mesh. I then check this:

Code: Select all

if (player.SupportCollisionBox.CollisionInformation.Pairs.Count > 0)
{
	...
}

But the code never enters the if statement, even though I see the block go through the level mesh. I no doubt am doing something wrong. This is my first time messing with physics, and this has proven to be significantly harder than the networking for the game I already have done, so I am sorry for seeming stupid with these questions.

[Norbo]

The SupportCollisionBox is kinematic. Kinematic and static objects belong to a collision group by default which prevents pair creation with other kinematic and static objects. This is because kinematic and static objects have essentially infinite mass and will happily ignore all collision response, so there's no point trying to find contacts under normal simulation conditions.

To make use of a kinematic object as a 'detector' that creates contacts with other kinematics or static objects, the collision rules will need to be modified.

For example, by setting the entity.CollisionInformation.CollisionRules.Group = new CollisionGroup() or CollisionRules.DefaultDynamicCollisionGroup, it will once again collide with everything. The CollisionFilteringDemo shows some examples, and a smattering of other demos also include collision rules usage (though they generally have a different primary focus).

If you just want to control collision relationships, it's best to use the collision rules system. Using separate spaces to do something similar is a much larger hammer that also breaks open the door for issues if you plan on making use of any kind of multithreading.

By the way, creating a robust, full-featured character is one of the trickier projects one can undertake for reasons that aren't always obvious until corner cases and unforeseen issues start piling up. I would recommend using either the CharacterController or SphereCharacterController if they can do what you need.

[DoctorWhy]

Thanks for the help. I was thinking of using SphereCharacterController, but I will have to modify them to allow for different gravity directions for each object, which may save some time on the jumping and proper movement. The problem is convincing my team to give me the proper time I need to do this, since I will have to redo the player class.

[Norbo]

Modifying the SphereCharacterController for different gravities and 6DOF motion will indeed be a bit tricky depending on how the 'up direction' changes.

If it needs to be able to do it on the fly based entirely on support contact data, getting a robust and smooth solution will take some fundamental changes to the support finder.

If there's always an external hint, like a gravity field defining the up/down direction, it becomes a lot easier. Most of the systems already have stubs for modifying the down direction. Tracking them all down can be a bit of a pain, though. The HorizontalMotionConstraint in particular will require some work to move it over to arbitrary up support rather than a horizontal plane based 2D vector.

If it is between modifying the SphereCharacterController to support only the external hint version of the above versus implementing all of the support/motion handling of the SphereCharacterController, I'd guess modifying the SphereCharacterController would turn out to be less work unless you could get by with a much-restricted version of support/motion handling.

[DoctorWhy]

Right now, we have 3 vectors that indicate the orientation and gravity of the player; up, forward, and right. Those 3 vectors will change depending on the gravity they are given, which is all already done (this changes the orientation of the camera as well, with smooth transitions). I will go through the SphereCharacterController (it has to be the sphere, or changing the gravity would cause the characters to get stuck in the wall) and see what I can do to combine our already created system with the new character controller. This will also be a networked game, so hopefully it won't be too difficult to separate all the physics from the drawing.

[DoctorWhy]

After working on it all day today, I did it! The hardest part was making the movement work on the 4 sides (the default and opposite worked great, the 4 "walls" took some time). I technically changed the "HorizontalMotionConstraint" and made it not so Horizontal. In other words, instead of only sending the X and Z movement, I converted the Vector2 for movementDirection into Vector3, subtracted the players "up" vector, and then sent it to the HorizontalMotionConstraint class. It wasn't that hard... after I took 3 hours finding what needed to be changed. I would like to give you serious thanks. Without your help, without this whole engine, I would be doing significantly more work.

I do have one more question though. Using the SphereCharacterController, the player slides around the level mesh quite a lot. I want the movement to speed up quicker (almost instantaneously) than it does, be more precise in the movement, and stop (almost instantaneously). How you have it in the Demo is great, and I am guessing I just need to set a few things to fix this. Considering the mesh gets scaled up 10X the size, I actually had to change the speed in HorizontalMotionConstraint to 400 to feel right (with a relatively large level), which is quite high. I probably need to change other things to fit this as well, I just don't know what.

[Norbo]

The MaximumForce property of the horizontal motion constraint controls how much force (and thus acceleration) the character can put out. Increase it until it feels right; note that since it's force-based, changing the character's mass will affect the rate of acceleration also.

I would like to give you serious thanks. Without your help, without this whole engine, I would be doing significantly more work.

You're welcome