[solved] Long delay before simulation starts

[KTCopache]

I've just started using Bullet, so I'm new and probably making some stupid mistake, but I thought I'd try out this forum thingy.

I have a few rigid bodies set up with btBoxShapes, and they're supposed to fall on top of each other and stack up. Nothing happens for the first -- like -- 30 seconds, then the physics kicks in and they fall on each other exactly like they're supposed to. Also, if I set a breakpoint before starting the main simulation loop -- so it just initializes everything then stops -- that time spent waiting counts toward the delay. So I could break for 30 seconds, then come back and everything would work immediately.

I'm using my own code to render everything, getting the transform every frame from a btDefaultMotionState to update my own objects. The timesteps I'm sending to stepSimulation are about the same both during and after the delay.

Nothing weird like this happens when I run the demo apps.

Anyone know what's going on?

[ouch67]

Have you tried setting each object to active? they could just be turning themselves off if they are touching something.

also, gimpact objects may cause strange things like this too.

[KTCopache]

Yeah, I tried calling setActivationState(DISABLE_DEACTIVATION), activate(), and activate(true) on the btRigidBody objects (every frame, even). Same problem.

One box starts out touching a static rigid body, the others start out touching nothing.

I'm not using Gimpact objects as far as I know.

[KTCopache]

Aww... no more ideas? I'm very close to switching to ODE or something.

[ouch67]

do you have any source code you could provide?

I don't anything like that for basic objects.

[KTCopache]

Well, I found the problem while I was putting together some code to post here.

I had sent one negative time step of about 30 seconds to stepSimulation.

[ouch67]

so putting a negative time step causes the simulation to pause for that duration, interesting... that might actually be useful...

[KTCopache]

I wouldn't count on it. It's undefined behavior (I assume), and probably should be fixed so that a negative timestep gets clamped to zero or something.