applyForce() / applyCentralForce() ignored in tick callback?

[Night Elf]

Apparently, applyForce() / applyCentralForce() are ignored when called from inside the tick callback. Skimming over Bullet's source code, I think this is because the tick callback is invoked when velocity calculations have already been performed.

Is this behavior intended? If so, at what time should I apply forces?

[Helius]

Hello!

Sorry for bumping this thread but I am having the same exact issue.

I have a world with zero gravity. There are objects floating around. To move the objects I apply them force for a period of time in response to player input (while he is touching the screen).

If I apply the force (applyCentralForce) outside the tick callback it works as expected, but I read in several posts that it's better to apply forces inside the tick callback.

If I apply the forces inside the tick callback they are ignored, but when the framerate drops below 60 the forces are applied eventually.

I am confused

[bradclancy]

Hey Guys,

In the tick callback is probably not the best place to be doing any real processing. On my project we cache off the contacts we are intersted in and then after all sub-steps are done (i.e. after stepSimulation returns) go through and apply forces; as btDisreteDynamicsWorld.cpp::stepSimulation calls clearForces at the end. Your tick callback happens before this call to clear forces. But if you are only getting 1 sub-step per frame you'll add your forces and they will then get cleared.

Helius, the reason for what your seeing is that once you drop below 60fps the simulate function is probably allowing a second sub-step (I assume not every frame but eventually). Which is resulting in your forces applied from the result of the first sub-step getting used in the second sub-step.

So, I'd suggest caching off your contacts inside the tick callback, but processing them after stepSimulation returns.

Cheers,
Brad

[Helius]

Thanks, I'll apply the forces outside the tick callback then

[ejtttje]

So, what is the current advice for what should be called from a dynamics world tic callback?

btHingeContraint.h has the following documentation for setMotorTarget:

// extra motor API, including ability to set a target rotation (as opposed to angular velocity)
// note: setMotorTarget sets angular velocity under the hood, so you must call it every tick to
// maintain a given angular target.

Although looking at the code, setMotorTarget sets m_motorTargetVelocity, not a direct call to btRigidBody::applyTorque, so really that comment should say call it as often as you need to update the motor velocity, not strictly every tic to stay in motion.

So if I want to implement my own motor controller (which I do), should I do this from a physics tic callback, or immediately prior/after each dynamics world step call? (Which would imply disabling any internal sub-steps so my motor controller doesn't miss updates.)

[edit: from the sound of it, the obvious conclusion from above posts would be that I should apply forces outside of the tic callback, so I guess the root question is what is the tic callback good for?]

[Erwin Coumans]

so I guess the root question is what is the tic callback good for?]

The main purpose of the tick-callback is to check for contact points, useful for AI/logic.
Some contacts come and go within a call to 'stepSimulation', so if you don't use the tick-callback,
you might miss them.

It is ok to change the target velocity of motors in 6DOF, hinge constraint etc within this callback.
Hope this helps,
Erwin

[Jodi]

Um, could you apply your forces in the pre-tick callback?

Looking at the code, if you do that, then if you only have 1 sub-step, the forces will still be applied.

(yea, sorry for the necro, but this topic is relevant to a problem I'm having).

[Erwin Coumans]

A pre-tick callback should work indeed. It was added after this discussion topic was there, I guess.

Thanks,
Erwin