Bounciness/Elasticity

[ShreeK]

I'm in the process of porting over from JigLibX, which creates composite bounciness by multiplying the two colliding objects. I've created my own bounce blender, and it seems to be working just fine. The problem that I'm having, is with the default bounce blender, and my customer bounce blender, the player (a ball) doesn't ever stop bouncing if my composite is greater than about 0.6. My level object is a trianglemesh, my player is a sphere primitive, both the level and the ball have varying bounciness, but the bounce jitter seems to occur at 0.6+ (maybe slightly lower) bounciness. I stuck a breakpoint into the blender and checked the player's velocity, and every time he collided, his downward velocity was about the same (-2.77ish), and this was with 0.64 bounciness; unless I'm mistaken, I should only have a constant collision velocity if my bounciness is ~1.0.

[Norbo]

unless I'm mistaken, I should only have a constant collision velocity if my bounciness is ~1.0.

That is correct. Can you reproduce the problem in a simple scenario (like in the CoefficientsDemo.cs)?

[ShreeK]

I created a test level with just the player (a glorified sphere primitive), a platform (a kinematic box primitive), and a detectorvolume to teleport the player back to his spawn point should he fall off.

The player's physics properties change based on items he picks up, and the variables include, but are not limited to: mass, gravity (the player should be the only object affected by gravity, so I just change the space's gravity), friction, and bounciness.

In order to test some factors, I created a data set that kept everything constant except gravity and bounciness, which I tested separately. I normally use a composite bounciness function that looks like this:

Code: Select all

        float compositeBounciness(Entity entityA, Entity entityB, float bounceA, float bounceB, object extraInfo)
        {
            float retVal = bounceA * bounceB;

            return retVal;
        }

But instead opted to use it to specify a specific bounciness for the testing.

Gravity Set
To test gravity, I had compositeBounciness return 0.5f. I tested gravity in the set Vector3.Up * {-1 ... -20} in whole number increments. With the ball at rest, it would begin to jitter when gravity hit -13, and would continue to jitter until it dropped back down to -6. When dropped, the ball would jitter when gravity was stronger than -6 (-7 ... -20).

Bounciness Set
To test bounciness, I had compositeBounciness return my control variable, which ranged from 0.1 to 0.8, and tested 2 different values of gravity (-5 and -10). With the ball at rest, no amount of bounciness (within my test set) would generate jitter. When dropped from a height, gravity of -5 would generate jitter with bounciness > 0.5, and gravity of -10 would generate jitter with bounciness > 0.3.

My simulation settings look like this:

Code: Select all

            space = new Space();
#if XBOX360
            //Note that not all four available hardware threads are used.
            //Currently, BEPUphysics will allocate an equal amount of work to each thread.
            //If two threads are put on one core, it will bottleneck the engine and run significantly slower than using 3 hardware threads.
            space.threadManager.add(delegate(object information) { Thread.CurrentThread.SetProcessorAffinity(new int[] { 1 }); }, null);
            space.threadManager.add(delegate(object information) { Thread.CurrentThread.SetProcessorAffinity(new int[] { 3 }); }, null);
            space.threadManager.add(delegate(object information) { Thread.CurrentThread.SetProcessorAffinity(new int[] { 5 }); }, null); 

            space.useMultithreadedUpdate = true;
#else
            if (Environment.ProcessorCount > 1)
                for (int i = 0; i < Environment.ProcessorCount; i++)
                    space.threadManager.add();

            space.useMultithreadedUpdate = true;
#endif
            space.simulationSettings.timeStep.useInternalTimeStepping = true;
            space.simulationSettings.timeStep.timeStepDuration = 1 / 60f;
            space.simulationSettings.timeStep.timeScale = 5f;
            space.simulationSettings.collisionDetection.collisionDetectionType = CollisionDetectionType.linearContinuous;
            space.simulationSettings.collisionDetection.bouncinessBlender = compositeBounciness;

I didn't notice I was a few versions behind, so I just updated to 0.14.1, and am still having the same issues.

[Norbo]

With a timeScale of 5 and timeStep of 1/60f, the actual time being integrated per step is 1/12f. This is too long for a stable simulation. The necessary update rate depends on the content of the simulation. If there are tiny objects, high speed, or very high gravity, smaller timesteps are usually a good idea. I wouldn't recommend for something larger than 1/30f, with 1/60f being ideal in many simulations.

I'm thinking about getting rid of the 'TimeScale' option so the consequences of changing integration length are more obvious. All TimeScale did was multiply the TimeStepDuration internally. Without it, the TimeStepDuration can still be changed (though it is not recommended except in controlled cases, and the length must not be excessive to ensure stability). Additionally, when using internal time stepping, multiplying the input value by some external time scale would integrate the engine forward by an appropriate number of TimeStepDuration-length steps, accomplishing the same goal with better stability.

[ShreeK]

Ahh, that makes sense, I'll fiddle around with timings and see if I get better results.

Thanks again!