How can I increase the physical realism of my simulation?

[haxmny]

I'm working on a physically based offline simulator with Bullet. My priority is physical realism; performance is a non-issue. I ran into some interesting effects when trying to decrease my simulation time step from 0.01s to 0.001s, namely that collisions stick rather than bounce. At the bottom is a minimal example that demonstrates what I'm talking about.

What should I do if I want to maximize the physical realism of my simulation? I understand there are different options for constraint solvers and whatnot; would using an alternate solver help? What can I do to get things bouncing to the height specified by their restitution coefficients?

Here's the code that demonstrates part of my issue:

Code: Select all

#include <bullet/btBulletDynamicsCommon.h>
#include <vector>
#include <iostream>

using std::cout;
using std::endl;
using std::vector;

class test {
private:
    btDefaultCollisionConfiguration     config;
    btSimpleBroadphase                  broadphase;
    btSequentialImpulseConstraintSolver solver;
    btScalar                            timestep;
    btCollisionDispatcher               dispatcher;
    btDiscreteDynamicsWorld             world;
    vector<btRigidBody>                 bodies;
    btStaticPlaneShape                  plane_shape;
    btSphereShape                       sphere_shape;

public:
    test(btScalar dt) :
        config       (btDefaultCollisionConfiguration()),
        broadphase   (btSimpleBroadphase()),
        solver       (btSequentialImpulseConstraintSolver()),
        timestep     (dt),
        dispatcher   (btCollisionDispatcher(&config)), 
        world        (btDiscreteDynamicsWorld(&dispatcher, &broadphase, &solver, &config)),
        plane_shape  (btStaticPlaneShape(btVector3(0, 0, 1), 0)),
        sphere_shape (btSphereShape(1))
    {
        world.setGravity(btVector3(0, 0, -9.80665));
        btRigidBody::btRigidBodyConstructionInfo plane_params(0, nullptr, &plane_shape, btVector3(0, 0, 0));
        btVector3 inertia;
        sphere_shape.calculateLocalInertia(3, inertia);
        btRigidBody::btRigidBodyConstructionInfo ball_params(3, nullptr, &sphere_shape, inertia);
        plane_params.m_restitution = 0.5;
        ball_params.m_restitution = 0.9;
        bodies.emplace_back(plane_params);
        bodies.emplace_back(ball_params);
        btTransform position;
        position.setIdentity();
        bodies[0].setWorldTransform(position);
        position.setOrigin(btVector3(0, 0, 50));
        bodies[1].setWorldTransform(position);
        world.addRigidBody(&bodies[0]);
        world.addRigidBody(&bodies[1]);
    }

    btScalar step() {
        world.stepSimulation(timestep, 1, timestep);
        return bodies[1].getWorldTransform().getOrigin().z();
    }
};

int main() {
    
    test t1(0.001);
    test t2(0.01);
    
    for (float i = 0; i < 10; i += 0.001) {
        cout << i << " " << t1.step() << endl;
    }
    
    cout << endl;

    for (float i = 0; i < 10; i += 0.01) {
        cout << i << " " << t2.step() << endl;
    }

}

Here's the resulting plots. Note that the only thing different between the two simulations are their timestep


EDIT: When I increase the restitution of the ground and ball to 1, the red ball bounces, but does not exhibit the correct rebound force like the green ball does. Here's the plot:

[johnsonalpha]

Turn on double percision and turn on split impulse see if that makes a change.

[haxmny]

I added these lines to the constructor after setting gravity

Code: Select all

world->getSolverInfo().m_splitImpulse = true;
world->getSolverInfo().m_splitImpulsePenetrationThreshold = -0.000001;
world->getSolverInfo().m_splitImpulseTurnErp = 1.0;

And am using double precision, the plots look the same.

[Basroil]

Have you checked the effects of damping on the system? If memory serves correctly, most damping components, mixing parameters, and error reduction parameters default to values acceptable for 60Hz operation, but are not always great once you cross into time scales 16x smaller than intended. Another interesting thing to test would be to change the drop height by just a bit (multiple times), I've seen restitution go wonky in certain cases where the penetration was essentially zero, though that might have been a fairly old copy of bullet.

Other solvers might also help, but they might bring with them quirks and less than stellar performance. It only takes 10min to completely set up a new solver (including reading up on options), so it's well worth it to try. Dantzig, NNCG, and the pivot version of PGS are all good places to start.

[drleviathan]

If damping were the cause then we'd expect the two descent curves to not align. According to the plots energy is lost on collision. As I recall there was a another recent post about how the measured accuracy of the simulation became worse on faster simulation steps. I don't have any theories as to why this happens.

[Ehsanizadi]

Yes, I also posted here : http://www.bulletphysics.org/Bullet/php ... =9&t=10694

about the problem. when the time step decreases, the accuracy becomes better, but lower amounts beyond 0.001s, makes worse accuracy.
I am not sure if it is an issue or not.

[haxmny]

Hmm, interesting post Ehsanizadi. In the mean time I'll try some of the other solvers and see if altering parameters makes much of a difference.

[Ehsanizadi]

Although there is a slight difference in our methods,
in your simulation, the system is highly dynamic and you get errors in positions,
but in my case, the position is correct, however, the system is not that much dynamic (the rigid bodies are moving calmly), but the error in my simulation emerges in force calculations.

[haxmny]

I tried switching to the Dantzig solver, with limited success. When restitution is set to 1, nothing changes between the two solvers. When set to the original restitutions of 0.5 for the static plane and 0.9 for the ball, the higher frequency simulation still sticks to the ground but the lower frequency simulation bounces a little more. Here are the plots of the same experiment as before using the new solvers.


Does anyone know enough about bullet internals to see why this might be happening? I really don't know enough about physical simulation to take a stab at the root cause.

EDIT: I started messing with the solver's ERP parameters. raising these seems to remove the final little bounce in the 100Hz sim, 1000Hz is still unaffected.

[Basroil]

Tried lowering ERP? It fixed some exploding joints I was getting at 500Hz+, and was pretty much a function of what fraction of 60Hz it was. It doesn't improve constraint accuracy (technically should make it worse), but improvements in collision detection should still make things better overall.

[haxmny]

I just tried 0.1, 0.01, 0.001, and 0.00001 for m_erp and m_erp2 and it doesn't change anything.

Is there any information on the meaning or use of the parameters in the struct returned by getSolverInfo? There are some parameters there that I'm not really sure what they do, but can't find any info on what they mean or what typical ranges would be. If anyone can link me to a discussion on the different solvers and their properties, that would be appreciated as well.

EDIT: I was looking through the MLCP solver directory for more options and found the PathSolver class which is #ifdef'ed out, what's the story behind this?

[haxmny]

Considering this question hasn't gotten much attention in the past couple days, I've switched to using the standard 1/60 time-step for the time being. Should I file a bug report somewhere related to this? I'm not a graphics/games person, so I'm unfamiliar with the methods bullet uses internally.