Unrealistic behavior of stacked objects

[nasskov]

I am doing some tests with the engine, and it works great, however I noticed a bit strange behavior in situations when you have a stack of objects.
I am attaching screenshots of a small piramid of cubes, base is 10x10, total 380 cubes. I leave a small space (.05) between the horizontally placed cubes.
What happens is that cubes in the piramides are making constant small movements, and the piramid itself slowly falls apart, this can be seen on the screenshots, the last one is taken after approximately 3 minutes.

1.png (10.86 KiB) Viewed 10410 times

3.png (11.5 KiB) Viewed 10410 times

5.png (16.08 KiB) Viewed 10410 times

[Norbo]

I am unable to replicate this behavior; could you try recreating it in the latest BEPUphysicsDemos for me to look at?

Even when:
-forcing the boxes to always be active (box.ActivityInformation.IsAlwaysActive = true),
-setting linear and angular damping of boxes to 0,
-disallowing deactivation stabilization effects (box.ActivityInformation.AllowStabilization = false),
-setting Space.Solver.IterationLimit = 1,
-and setting CollisionResponseSettings.Softness = 0 (rigid collisions tend to be harder to solve),
the behavior does not occur.

For reference, here's the base replication attempt:

Code: Select all

            float boxSize = 1f;
            int bottomBoxCount = 10;
            
            Space.Add(new Box(new Vector3(0, -.5f, 0), bottomBoxCount * boxSize + 40, 1, 40));


            float spacing = 0.05f;

            float offset = -0.5f * ((bottomBoxCount - 1) * (boxSize + spacing));
            var origin = new Vector3(offset, -boxSize * 0.5f, offset);
            for (int heightIndex = 0; heightIndex < bottomBoxCount - 2; ++heightIndex)
            {
                var levelWidth = bottomBoxCount - heightIndex;
                float perBoxWidth = boxSize + spacing;
                //Move the origin for this level.
                origin.X += perBoxWidth * 0.5f;
                origin.Y += boxSize;
                origin.Z += perBoxWidth * 0.5f;

                for (int i = 0; i < levelWidth; ++i)
                {
                    for (int j = 0; j < levelWidth; ++j)
                    {
                        var position = new Vector3(
                            origin.X + i * perBoxWidth,
                            origin.Y, 
                            origin.Z + j * perBoxWidth);

                        var box = new Box(position, boxSize, boxSize, boxSize, 20f);
                        
                        Space.Add(box);
                    }
                }
            }

The expected behavior is for the stack to deactivate in around one second.

[nasskov]

Hi Norbo, and many thanks for your assistance.
I am testing it using Unity for visualization, so I compiled the dlls for .NET 3.5 and without compilation symbols(WINDOWS;ALLOWUNSAFE)
This must be the reason for the problem...

[Norbo]

Using .NET 3.5 without the symbols does not seem to reproduce the issue on my end.

[nasskov]

I just sent you a PM with source code of my project and some additional info.

[Norbo]

For anyone visiting, here's my PM response to explain the situation:

Unfortunately, at the moment, I don't have the time to do a wide-scope debugging effort.

For now, I'll need to leave this one up to the community to dig into. I've issued a request on twitter in an attempt to find more affected users.

If anyone has any more data, reproductions, or theories, toss them in here for public debug-consumption.

[nasskov]

Hello Norbo,
It was my bug after all, while playing with settings for my demo I had set default bounciness of the cubes to .3f, that was the cause of the problem...
Thanks again and sorry for wasting your time.

[Norbo]

Don't feel too bad! This issue has directly/indirectly uncovered three separate issues:

1) the duplicated usings from the last merge,
2) a fairly severe simulation island bug which caused all pairs to be deleted when a stack was activated,
3) and an extremely severe fundamental bug in the solver that breaks any constraint which measures velocity in the pre-update phase- like bounciness, among other things . Having the bounciness set to 0.3 shouldn't cause it to jiggle apart like that. I'm currently working on this one.

[Norbo]

The bounciness bug should be fixed now.

[nasskov]

Yeah, actually it was problem and I am glad I helped to discover it, although my initial suggestion was wrong.
Thanks Norbo