Problem with BEPU'S collision system

[rc183]

I currently have a problem with BEPU'S collision system.

Here is the setting:

- I have a ball rolling horizontally on the ground from left to right on a platform (rectangle). These two objects are associated to BEPU physics models ("Sphere" for the ball and "Box" for the platform).

- The ball jumps at a certain height with a certain speed.


Unfortunately, the ball sinks into the platform upon landing instead of properly colliding with it. Is there any way to fix this problematic issue?


Here is the how the jump mechanic work:

- In the ball's method "update ()": I apply a vertical force on the physics model ("Sphere") via the "LinearVelocity" attribute, which corresponds to the jump speed (30 in my case) until the ball reaches a certain height on the y-axis.

- Then, I apply the same negative force to bring down the ball until it collides with the platform.
To check if the ball collides with the platform I use the event: "InitialCollisionDetected".

Here is an example of how I do it (pseudo code):

Code: Select all

sphere.EventManager.InitialCollisionDetected += HandleCollision;

void HandleCollision(EntityCollidable sender, Collidable other, CollidablePairHandler pair) 
{ 
    isJump = false;
}

public void jump()
{
	isJump = true;
}

public void update()
{
	if(isJump)
	{
		if(currentHeight < jumpHeight)
		{
			sphere.LinearVelocity = new Vector3(sphere.LinearVelocity.X, 30, sphere.LinearVelocity.Z);
		}
		else
		{
			sphere.LinearVelocity = new Vector3(sphere.LinearVelocity.X, -30, sphere.LinearVelocity.Z);
		}
	}
}

I attached a few pictures to the message so that you can clearly understand the problem.

jump 1.JPG (7.77 KiB) Viewed 6215 times

jump 2.JPG (14.32 KiB) Viewed 6215 times

jump 3.JPG (14.64 KiB) Viewed 6215 times

Thank you for your time.

[Norbo]

I'd need a runnable sample, video, or more description to get an exact idea of the behavior, but if you want jumping, I'd recommend doing it more physically.

Instead of forcing the velocity to a specific value up and then down, just change the velocity once (at the time of the jump), and then let gravity return the object to the ground. This eliminates the need for complicated per frame management.

The problem as-is could be related to the object being continually rammed into the ground by bad velocities or possibly other issues. An object that gets into a penetrating state will very quickly resolve to a touching state; if it doesn't, there is something interfering or otherwise set up incorrectly.

[rc183]

Hi Norbo and thank you for your answer,

I will try your your solution of changing the velocity once instead of forcing it and feed you with feedback.

As for the ball going into a penetrating state upon landing, it is true that it rapidly returns to a touching state (almost immediatedly). The thing is that I want to absolutely make sure that the ball never sinks into the plateform since accuracy is my main concern in this design.

[Norbo]

There will be some amount of overlap; it is practically unavoidable. Contacts are created based on the overlap between two shapes; an object resting on another is actually penetrating it a very tiny amount.

The cause of the initial larger penetration is that the engine simulates discrete steps. If the sphere moves X units in a single frame of simulation, it's possible that it will be very close to X units penetrating another object in the following frame.

You can mitigate this by updating with smaller, more frequent timesteps; the default space.TimeStepSettings.TimeStepDuration is 1/60f. Setting it to 1/120f will halve the timestep length, halving the possible penetration for a given velocity. To keep up with real time, the space will have to update more often and this can be expensive. To try it, you can pass in the elapsed frame time to the space.Update method which takes as many internal timesteps as are necessary to keep up with real time. If you go that route, you may want to look into using interpolated properties as well. This documentation has some more information about it, just skip the bits involving setting up separate update threads: http://bepuphysics.codeplex.com/wikipag ... umentation

Another option is activating continuous collision detection. This will be cheaper, but it still doesn't guarantee zero penetration (by design). Having a bit of leeway provides a smoother simulation. To try CCD, set an entity's PositionUpdateMode to Continuous. You can change the amount of leeway CCD uses by changing the MotionSettings.CoreShapeScaling to something higher than 0.8f, which will avoid more penetration.

[Seleste]

To compound on Norbo's suggestions with some of my own experiences:

I've managed to avoid penetration altogether by using some of the raycast logic found in the sample SimpleCharacterController.

The jist of the idea is to throw a raycast downwards, ahead of the character shape (in your case, the sphere), and preempt the collision if the raycast hits something. In the case of the character controller, the raycast is fired from the base of the character, and its maximum length is limited by a predefined support margin. My personal approach was instead to throw the ray from the body's center of mass, and scale its maximum length according to the velocity's Y component * dt.

In other words, at each update, you're checking with a raycast if the body can collide within this update, and if so, just place it where the collision would've happened instead of letting it run its course.

[rc183]

Hi Norbo and Seleste. Thanks a lot for your answers!

I've tried a few solutions this weekend but I'm still facing some collision issues. The last solution you proposed Seleste is an interesting one.
You were talking about a sample called "SimpleCharacterController". Where can I find it?

Again, thank you both for your help

[Norbo]

The BEPUphysicsDemos project, which is a part of the main source download (http://bepuphysics.codeplex.com/SourceC ... changesets), contains the SimpleCharacterController. It's used by all the demos in the project. There's also a non-simple CharacterController, but it's in the process of being phased out for a new version, so the current version is lacking some basic things. The SimpleCharacterController does all the basics without much complication.