Hello,
I am trying to determine where I should put the computation and application of torques/forces that I have computed for my rigid body.
Right now I am putting it before every physics tick in the Bullet Physics pretick callback.
I am detecting collisions after every tick, in the Bullet physics post tick callback.
Is this the best place to put it?
I ask this because I can only reasonably get a real time simulation if I use a bullet physics simulation tick of 0.002 (500hz) I'd like to make it smaller since I experience some slippage between rigid bodies. (Any ideas to stop this would be greatly appreciated too). I have an idea where I can maybe compute torques at 500hz and then have a physics step of 2khz or something.
Thanks for all the help.
Also, does utilizing callbacks make the processing time for each tick longer?
Best place to compute and apply forces/torques
- drleviathan
- Posts: 849
- Joined: Tue Sep 30, 2014 6:03 pm
- Location: San Francisco
Re: Best place to compute and apply forces/torques
jchen114, one way to do it is to implement a custom "action":
(1) derive MyCustomAction class from btActionInterface
(2) implement MyCustomAction::updateAction() to do all of the per-substep calculations and velocity/force/torque adjustments
(3) add each action instance using btDynamicsWorld::addAction()
The updateAction() method will be called once for each action every substep (inside btDiscreteDynamicsWorld::internalSingleStepSimulation()).
Other tips:
(4) You probably want to bail early in updateAction() when the relevant RigidBodies are not active, unless you have logic therein that would activate them. Whatever the case, be sure to check the RigidBody's active state before applying force or changing the velocity.
When it comes to stopping slippage: I assume you've already set the friction coefficients of the objects high. Note that you can use friction coefficients that are larger than 1.0 in Bullet. Also set the restitution (bounciness) of at least one of the objects to 0.0 which makes for less separation velocity on collisions.
(1) derive MyCustomAction class from btActionInterface
(2) implement MyCustomAction::updateAction() to do all of the per-substep calculations and velocity/force/torque adjustments
(3) add each action instance using btDynamicsWorld::addAction()
The updateAction() method will be called once for each action every substep (inside btDiscreteDynamicsWorld::internalSingleStepSimulation()).
Other tips:
(4) You probably want to bail early in updateAction() when the relevant RigidBodies are not active, unless you have logic therein that would activate them. Whatever the case, be sure to check the RigidBody's active state before applying force or changing the velocity.
When it comes to stopping slippage: I assume you've already set the friction coefficients of the objects high. Note that you can use friction coefficients that are larger than 1.0 in Bullet. Also set the restitution (bounciness) of at least one of the objects to 0.0 which makes for less separation velocity on collisions.
Re: Best place to compute and apply forces/torques
Does that make the time for computation a lot faster than using pretick callbacks?
- drleviathan
- Posts: 849
- Joined: Tue Sep 30, 2014 6:03 pm
- Location: San Francisco
Re: Best place to compute and apply forces/torques
No it is not computationally faster. The btActionInterface API is just a hook that Bullet provides whereby it will call your custom code once per substep.
When you say "pre-tick" do you mean "pre stepSimulation()" or do you mean "pre substep"? Bullet will take multiple substeps per step, but only if you supply step times that are different than the specified substep. This is just a convenience to allow games to step forward at constant width increments while still adjusting to variable delta time of the program's main loop. Bullet will only move forward one substep at a time and accumulate any remainder for the next step. All of this would not apply to your project if you supply exactly one substep's worth of time each call to stepSimulation().
When you say "pre-tick" do you mean "pre stepSimulation()" or do you mean "pre substep"? Bullet will take multiple substeps per step, but only if you supply step times that are different than the specified substep. This is just a convenience to allow games to step forward at constant width increments while still adjusting to variable delta time of the program's main loop. Bullet will only move forward one substep at a time and accumulate any remainder for the next step. All of this would not apply to your project if you supply exactly one substep's worth of time each call to stepSimulation().
Re: Best place to compute and apply forces/torques
Currently I do something like this:
So this takes exactly one bullet time step for numsteps. I'm not sure if this causes any performance issues though.
The way I was applying my torques was by calling
That would calculate all the torques before every simulation substep happens according to the docs.
Is this the standard architecture to use when calculating and applying torques? When I run the simulation, the amount of time it takes to calculate and apply torques caps me to about 9 steps of 0.002 if I want to keep the simulation real time.
Any suggestions on how I can make more steps of smaller step times?
Code: Select all
for (int i = 0; i < numSteps; i++) {
m_pWorld->stepSimulation(BULLET_TIME_STEP, 0);
}
The way I was applying my torques was by calling
Code: Select all
m_pWorld->setInternalTickCallback(InternalPreTickCallback, 0, true)
Is this the standard architecture to use when calculating and applying torques? When I run the simulation, the amount of time it takes to calculate and apply torques caps me to about 9 steps of 0.002 if I want to keep the simulation real time.
Any suggestions on how I can make more steps of smaller step times?
Re: Best place to compute and apply forces/torques
You know that you break determinism of your simulation by using stepSimulation(BULLET_TIME_STEP,0)?
http://bulletphysics.org/mediawiki-1.5. ... _The_World
This causes the actual time step to be variable and therefore the way your simulation runs might randomly change.
http://bulletphysics.org/mediawiki-1.5. ... _The_World
This causes the actual time step to be variable and therefore the way your simulation runs might randomly change.