How can I implement better collision detection for rolling?

[Spankenstein]

Sorry, that slipped my mind; moving the analysis between the NarrowPhase and Solver will allow you to see the most recent contact state combined with the pre-solving velocity state.

What method do I need to override to so that it is called between the NarrowPhase and Solver and get the correct state?

The impulse is a direct readout of the accumulated impulse applied by the constraint. For it to be wrong, the simulation would have to be noticeably broken as well.

That is correct, sometime the box bounces on first contact (like it should) and other times it almost sticks to the ground. There is definitely something amiss. I can demonstrate with a short video?

Also, watch out for that & operator- it won't allow short-circuit evaluation.

Late night typo, apologies. Thanks for letting me know.

[Norbo]

What method do I need to override to so that it is called between the NarrowPhase and Solver and get the correct state?

Hook an event on one of the space stage's Starting/Finishing events (perhaps Space.NarrowPhase.Finishing or Space.Solver.Starting), or by creating a IBeforeSolverUpdateable and adding it to the Space. If you decide to go the IBeforeSolverUpdateable route, you can inherit from Updateable and implement IBeforeSolverUpdateable and that will handle most of the boilerplate code related to updateables. The event hook may be easier unless you want to take advantage of the threading abilities of the updateables.

That is correct, sometime the box bounces on first contact (like it should) and other times it almost sticks to the ground. There is definitely something amiss. I can demonstrate with a short video?

That might help, but if there's truly something wrong with impulse calculation, it is unlikely that I'll be able to solidly identify it visually- it would probably require a reproducing demo for me to debug. That said, could it be the CollisionResponseSettings.BouncinessVelocityThreshold is high, preventing bounces from occurring?

[Spankenstein]

That said, could it be the CollisionResponseSettings.BouncinessVelocityThreshold is high, preventing bounces from occurring?

CollisionResponseSettings.BouncinessVelocityThreshold = 1.0f

Have said that it might be affected by my attempts to try and increase stability to prevent tunnelling. That process has only involved setting the following:

Code: Select all

            BEPUphysics.Settings.CollisionResponseSettings.MaximumPenetrationCorrectionSpeed = 10f;
            BEPUphysics.Settings.CollisionResponseSettings.PenetrationRecoveryStiffness = .5f;

Other ideas along this avenue would be very welcome. Limiting all forces to a maximum possible force would be good.

[Norbo]

The bounciness velocity threshold may be need to be higher or lower depending on your expectations for bounces and the involved objects speeds/sizes. Another possibility would be differing material settings which blend to different bounciness coefficients. (If an object lands and does not go through the object, that means impulses were computed 'correctly' for a lack of bounciness. If the impulse calculation fully failed, it would be extremely noticeable and horrible, like rocketing off the screen, dancing uncontrollably, or ignoring the obstacle entirely. That's why I suspect something stopping specifically bounciness from being used, as opposed to a general failure.)

Have said that it might be affected by my attempts to try and increase stability to prevent tunnelling. That process has only involved setting the following:

Those two penetration-related settings would not eliminate bounces- in fact, they make bias-sourced bounces more likely.

Other ideas along this avenue would be very welcome. Limiting all forces to a maximum possible force would be good.

That would give objects a way to fall through the ground if collision response is limited; do you mean something else?

[Spankenstein]

Here's what I have hooked up to the Space.Solver.Staring event:

Code: Select all

        private void Solver_Starting()
        {
            int numEntities = space.Entities.Count;

            for (int i = 0; i < numEntities; ++i)
            {
                var o = space.Entities[i].CollisionInformation.Tag as AudioObject;

                if (o == null)
                {
                    continue;
                }

                // Collision filtering method
                o.DetectValidCollision();
            }
        }

I'm open to suggestions for better approaches rather than casting each entity to the type of object I am dealing with and then running the same collision filtering method (as written in previous posts) if it is not null.

That would give objects a way to fall through the ground if collision response is limited; do you mean something else?

I would like to prevent all objects from tunnelling at high velocities when contained within DoubleSided triangles. I thought that by limiting/clamping their momentum this could be a brute force approach to achieve that goal?

[Norbo]

I'm open to suggestions for better approaches rather than casting each entity to the type of object I am dealing with and then running the same collision filtering method (as written in previous posts) if it is not null.

If there's a known set of objects which you want to test, you can keep that set handy and sample it directly just like when it wasn't in the space stage. The context of the event handler does not prevent the usage of external data.

I would like to prevent all objects from tunnelling at high velocities when contained within DoubleSided triangles. I thought that by limiting/clamping their momentum this could be a brute force approach to achieve that goal?

Clamping velocity could help, yes, but just setting the fast entity's PositionUpdateMode to Continuous would stop it from going through a wall unless there's lots of speedy rotation or if it's already in contact and being forcefully shoved out.

Having a strong penetration correction helps too; it's not screwing up the bounciness or anything like that (unless you feel the collisions are too bouncy).

As a last resort for situations where there's high speeds, large forces, and fast rotation such that continuous collision detection can't save you, making the mesh into a solid MobileMesh could help. That way, when an object starts to escape and enters the 'shell,' there will still be a contact pulling it back in rather than the infinitely thin wall alternative.

[Spankenstein]

The context of the event handler does not prevent the usage of external data.

Good point. I'll update the code to reflect that.

Once again many thanks. I'll report back should I come unstuck after implementing your latest suggestions