Physics Accuracy Issues...

[Danthekilla]

Hey Norbo, we are going though all the objects in our game editor (about 150 now) and bug fixing them and improveing them greatly...

I have been fixing the "Steerable Wheel" today and have made it totally awesome as it now has suspension amonst other improvements (like jumping and variable gear support) but i'm having lots of in accuracy issues sadly with the joints...

Here is a video of the problem...

But also even stacking 5 boxes ontop of each other causes lots and lots of jittering, what am i doing wrong with the engine?

Here is a video
http://www.youtube.com/watch?v=6smF6GbOz58

Anyway the details you may want are:

space = new Space();
space.SimulationSettings.MotionUpdate.Gravity = new Vector3(0, -8f, 0);
//space.SimulationSettings.collisionDetection.collisionDetectionType = CollisionDetectionType.fullyContinuous;
//space.SimulationSettings.collisionDetection.useContinuousDetectionAgainstMovingKinematics = false;
//space.SimulationSettings.motionUpdate.useRK4AngularIntegration = true;
//space.SimulationSettings.motionUpdate.conserveAngularMomentum = true;

space.SimulationSettings.Deactivation.NumEntitiesToTryToDeactivatePerFrame = 20;
space.SimulationSettings.Deactivation.LinearVelocityClampingTime = 0.5f;
space.SimulationSettings.Deactivation.LinearVelocityClamping = 0.1f;

space.SimulationSettings.CollisionDetection.BouncinessBlendMethod = PropertyBlendMethod.BiasHigh;
space.SimulationSettings.CollisionDetection.FrictionBlendMethod = PropertyBlendMethod.BiasLow;

space.SimulationSettings.CollisionDetection.CollisionDetectionType = CollisionDetectionType.DiscreteMPRGJK;
space.SimulationSettings.CollisionDetection.ContactInvalidationLengthSquared = 0.025f;
space.SimulationSettings.CollisionDetection.DefaultAllowedPenetration = 0.01f;
space.SimulationSettings.CollisionDetection.DefaultMargin = 0.05f;

space.SimulationSettings.CollisionDetection.UseContinuousDetectionAgainstMovingKinematics = false;
space.SimulationSettings.CollisionDetection.UseContinuousDetectionInNoResponsePairs = false;
space.SimulationSettings.CollisionDetection.UseOneShotManifolds = true;

space.SimulationSettings.CollisionResponse.Iterations = 16;
space.SimulationSettings.TimeStep.TimeStepDuration = 1 / 60f;

if (Environment.ProcessorCount > 1)
{
for (int i = 0; i < Environment.ProcessorCount; i++)
space.ThreadManager.AddThread();
space.UseMultithreadedUpdate = true;
}

space.SimulationSettings.TimeStep.UseInternalTimeStepping = true;


Does anything jump out at you as being a problem?

Oh and the platforms are about 6 by 6 by 1
And the wheels are 0.5f for width and have a radius of 1
The wheels cube that they use for there spring is 0.5f by 0.5f by 0.5f and is connected with a point on line joint and has another joint for limiting the 2 rotational axis's for the wheel.

The wheels are locked in the video so it didn't just roll away.

The wheels weight is 35 there attach cube is 20 and the platform on the cars top is 20 (any heavyer and it gets way worse)

The stacked platforms weights are all 20 too.

At the start of the video i move the car around a bit to just show the springs working, but all the rest of the jittering is not me moving the car.

They are all sitting on a fairly complex static tri mesh with a verts in a 3 by 3 grid

The issue also happens if they on static objects...




Anyway if you have any ideas that would be great as we are trying to polish everything off and get it ready for release.
Thanks again.

[Norbo]

Yikes! It looks like the actual joints are handling themselves okay, but the contacts are going bananas. That stack of boxes should be rock solid.

How well does this work for the setup:

Code: Select all

space = new Space();
space.SimulationSettings.MotionUpdate.Gravity = new Vector3(0, -8f, 0);

space.SimulationSettings.Deactivation.NumEntitiesToTryToDeactivatePerFrame = 20;

space.SimulationSettings.CollisionDetection.BouncinessBlendMethod = PropertyBlendMethod.BiasHigh;
space.SimulationSettings.CollisionDetection.FrictionBlendMethod = PropertyBlendMethod.BiasLow;

space.SimulationSettings.CollisionResponse.Iterations = 16;
space.SimulationSettings.TimeStep.TimeStepDuration = 1 / 60f;

if (Environment.ProcessorCount > 1)
{
for (int i = 0; i < Environment.ProcessorCount; i++)
space.ThreadManager.AddThread();
space.UseMultithreadedUpdate = true;
}

space.SimulationSettings.TimeStep.UseInternalTimeStepping = true;

It gets rid of some of the default value setting lines, and also reverts some of the others to the default values. Tuning contact generation can be finicky, though I don't know if it can explain all of that behavior. I'm most suspicious of one shot manifolds. They are a semi-experimental old feature that may have gotten broken at some point (it's actually being removed in v0.15.0, possibly temporarily).

[Norbo]

I went ahead and did a little test. All other settings set to the default, enabling one shot manifolds does indeed harm simulation quality substantially. Not quite as bad as what was in that video, so maybe the other settings changes will help too.

[Danthekilla]

I played around with the settings and set them all to the ones you suggested.

I had thought that one shot manifolds would improve stabilty as the cost of some performance... Like its comment said. I never thought that it could harm the simulation.
I have uploaded a little video with the new fixes, that shows the next problem i am have having.

Its just a quick 2 min video of me building and testing a little car in our editor, and you will see the problem at around about the minute mark when i move the box onto the car. Oh and the car jumping at the end is my test jump funcion.

Anyway let me know if it looks like i could be doing anything better.

Heres the video
http://www.youtube.com/watch?v=r2Mdb93TwgY

Thanks again.

[Norbo]

I never thought that it could harm the simulation.

It certainly wasn't intended to At one point, it did help, but it's apparently been broken quite badly since then.

you will see the problem at around about the minute mark when i move the box onto the car.

That's pretty strange- it looks like the entities involved have high bounciness. Assuming they aren't bouncy, and assuming the objects are Boxes, and assuming that the Box-Box special case is being used (it would be unless it's been removed from the special case handlers), one possible cause that I can think of is high frequency jitter. If this is the case, the car body should be oscillating at a high rate. I notice it's moving a little bit in the video, but I can't tell if it's really jumpy or not.

Another possibility is collision response tuning, specifically penetration correction stiffness and speed. If the stiffness is high and allowed speeds are high, collisions would overcompensate. However, none of the settings you posted change the penetration correction behavior.

To narrow down the causes, try increasing the collision response iterations to something unreasonably high (100), and maybe even set the CollisionResponse.MinimumImpulse to 0 to prevent it from ever doing any shortcuts. This should make the solver extremely stable. If the wheels still wiggle excessively and the boxes still bounce, then something else is probably wrong (some fighting constraints could cause it, maybe). If the behavior is fixed, it might be due to joint configurations still, though it would likely have more to do with the difficulty of the simulation rather than fighting constraints and other joint property tuning might fix it.

[Danthekilla]

Ok well i tryed setting the CollisionResponse.MinimumImpulse to 0 and the iterations to 100 and that made no noticeable change...

the bounceiness of the 2 objects are both 0.1f.
By setting the bounce to 0.0f on the "car body" it compleatly removed the problem however... So for now that will do.

Let me know if you can think of why this is happening, i dont think it is because of fighting joints as i think i have them all set right...

Also the slight jittering (or slight moving really) is that just because of the non perfect nature of the joints? is there any way to increase joint accuracy or update them more often?

Thanks.

[Norbo]

Also the slight jittering (or slight moving really) is that just because of the non perfect nature of the joints? is there any way to increase joint accuracy or update them more often?

When you increased the iterations to 100 and set the min impulse to 0, that increased the solver accuracy a huge amount, which is what is responsible for joint/constraint stability. If it was still wiggling, that implies the problem is not due to a lack of accuracy. The real solution that the solver is finding includes 'the wigglies.'

That implies the configuration is actually encouraging it to behave that way. What specifically is doing it, I do not know. You may want to try modifying individual joints' stiffness/damping coefficients. By default they are extremely high, it could be that the 'rigid' solution the solver is finding involves wiggling, whereas if some offending joint was made weaker, it would stop.

[Danthekilla]

When i set the iterations to 100 the jiggling on the wheels stops completely (the surface was just still crazy bouncy) sorry i should have specified.

Here is a little video of how my wheels are put together.

Heres the video:
http://www.youtube.com/watch?v=-RFGorWdl1s

Basically there is a wheel (cylinder) and a 0.5f cube above it, these are held together with a point on a line joint.
The wheel also has a revolute joint on it with the positional part turned off. To limit 2 axis's of rotation.

The small cube as part of the wheel raycasts to an object above and attaches itself to it with another revolute joint (with nothing disabled) so that it holds the box to the car body and lets me steer the 0.5f box and therefore steer the wheel.

Is there any way that i can get all the same things and events happening without the use of the top cube and the 3 total joints?

I assume that since the cube has to rotate first and then the wheel lags behind etc... There might be lots of inaccuracy’s that build up...

The less joints and bodies the less chance for odd behaviours right? It could also help performance ya?

Any idea on the simplest way to do this?

[Norbo]

The less joints and bodies the less chance for odd behaviours right? It could also help performance ya?

Any idea on the simplest way to do this?

In general, yes, that is correct.

I've attached a modified version of the ReverseTrikeDemo. It now more closely resembles your car, and avoids the usage of the intermediate steering block. It uses a PointOnLineJoint, LinearAxisLimit, LinearAxisMotor, SwivelHingeAngularJoint, and two RevoluteMotors per wheel. Even when using only a single solver iteration, it behaves quite well.

I should be able to get one working even with an intermediate steering block for demonstration purposes. I'll see what I can do and post it here in a few minutes.

[Danthekilla]

Cool thanks heaps for help ill try implimenting this now.

[Norbo]

Here's the version with a steering block if you're wondering.

This version definitely needs more than one iteration (it starts dancing itself into oblivion at that few), but it works fine with 10.

[Danthekilla]

Thanks ill try getting the simpler version working as that should be fine for what i need it for.

Thanks again. Hope all this doesn't distract from .15 too much.

Oh yer one other thing, is there anyway to rotate an object internally without setting its orentation quterinan? I have been putting my wheels into a compound body of one pre rotated so later when my level editor code rotates everythings orentations everything still works.

Just wondering.

[Norbo]

Hope all this doesn't distract from .15 too much.

Building quick little re-usable samples is a good investment of time, since they can help more than one person Plus, it's a nice break from the regular 'hard' coding before bed.

Oh yer one other thing, is there anyway to rotate an object internally without setting its orentation quterinan? I have been putting my wheels into a compound body of one pre rotated so later when my level editor code rotates everythings orentations everything still works.

The orientation quaternion properties are the primary way to change it, along with the orientation matrix/world matrix properties. I'm not sure exactly what you're looking for though- are you looking for a way to rotate objects around some non-center of mass location without using compound bodies? If so, you could do what the compound body does internally: compute the offset vector from some rotation origin O to your object's position P, rotate it with your rotation R, and add that R-transformed OP to O to get your new position. You'd also need to apply R to the object's orientation as well.

Edit: The offsets in question in the compound body are computed once and put into local space, and then transformed using the full orientation of the parent body rather than incremental rotations. This helps prevent numerical drift.

[Danthekilla]

Hey i have been trying to get the simple one working in my game and the wheel aims in the wrong direction so i changed to this

MyServo.TestAxis = Vector3.Transform(Vector3.Right,Bodys[0].InternalOrientationQuaternion);
MyServo.Basis.SetWorldAxes(Vector3.Transform(Vector3.Up,Bodys[0].InternalOrientationQuaternion),Vector3.Transform(Vector3.Right,Bodys[0].InternalOrientationQuaternion),Vector3.Transform(Vector3.Forward,Bodys[0].InternalOrientationQuaternion));

instead of the defaults you gave me and now its points in the right direction but does the flip thing when it hits the max.

Theres a 20 second video here that shows it and the axis that i am trying to get it working on, my engine supports rotation so i have to be able to rotate the wheels (which is why i set the axis to use the wheels (bodys[0]) orientation.

Heres the video
http://www.youtube.com/watch?v=XfUbODpD5WM

[Norbo]

I've attached another sample showing an arbitrary starting orientation.

I generally prefer configuring everything in local space and positioning/rotating the end product, but doing it in world space just requires being consistent with every single piece of the initialization.