rendering and simulation in different Win32 threads

[XMight]

Hi, I have a question,
I want to render my scene graphically in the main thread of the application, but to do the simulation in a separate Win32 thread.

I managed to separate this, and it works, but not very well.

When I pick up an object, and I want to move it, applying a centralForce, this force is now applied the moment I pick the object, but seconds later, and it seems like an impulse, that is applied from time to time, and not continuously, as I want, when moving the object with the cursor.

However, the same principle works if the rendering and the simulation are done in the same thread.

Some ideas?

[dumbo2007]

I have tried this before. You may need to sync the 2 threads using some basic windows synchronization primitive.

[XMight]

Hi, what I did to be able to run at least my code, is to apply a lock.

My app has 3 threads:
1. Main app. thread, in which I do the rendering
2. 100Hz thread, where I apply the forces
3. The simulation Thread, that runs at the 60Hz step, or whatever. I can restrict it to 30 if I want.

When the graphic rendering is done, the lock is acquired, and no advancement in simulation can be done, and the same thing applies if stepSimulation is called. In the forces thread I did nothing, i.e. no lock.

Some suggestions?

[bimmy47]

I am certainly not an mp expert, but I think the typical way of doing this is to compute a single step of the physics world while rendering a single frame and sleep whichever is faster until the slower catches up. I don't believe you can get by with just a lock, because the faster thread might simply monopolize the lock, thus punishing the slower thread even more. I'm not sure really though. There are definitely answers out there, maybe search for multithreading on gamedev.net?

[dumbo2007]

faster thread might simply monopolize the lock

Yes exactly. How about making it such that the physics thread runs 1 step and then sleeps until signaled by the graphics thread to do 1 more step ? This way everything runs at the rendering frequency.

To independently check if they are always in sync you can increment a variable in each thread and check whether they match at all times(they should)

[XMight]

Hi,
actually I managed to get a solution. It is not high fidelity (you feel some delay in the forces that you pass and when these are applied), but works somehow. I use the lock that I applied, but at the same time, I do not apply the forces on the selected object in the 100 Hz thread, but instead I store the sum of the forces (force and torque) in a static variable, and in the simulation thread, before I step the simulation, I apply the forces, since I know the object.

faster thread might simply monopolize the lock

Yes exactly. How about making it such that the physics thread runs 1 step and then sleeps until signaled by the graphics thread to do 1 more step ? This way everything runs at the rendering frequency.

To independently check if they are always in sync you can increment a variable in each thread and check whether they match at all times(they should)

Also, how will you assure that the next graphic rendering will not start meanwhile bullet will be stepping the physics, so anyway this is a lock mechanism: graphics must wait the physics, and physics the graphic. The only solution I see to synchronize them, to force both to run at the same frequency, one after another, and not both at the same time.

[Kanttori]

I'm doing something similar where I use a motionstate to store the transforms coming from bullet. This insulates the simulation from the engine/visual objects and allows the drawing and simulation to run concurrently. I use a lock per thread which they must gain and which is released by the other thread.

When starting the Simulation is locked and Engine lock is free.

Simulation thread:

Code: Select all

while do_simulation:
    get Simulation lock
    if do_simulation:
        dynamicsworld simulation step
        release Engine lock  // Allows Engine to update animations, read motionstates and draw visuals

Engine thread

Code: Select all

while do_engine:
    get Engine lock
    update animations
    read transforms from motionstates
    release Simulation lock  // Allows Simulation to do next step
    draw visuals

The advantage is best on a multicore system, but often even on singlecore systems drawing graphics can leave the CPU with little to do but wait so this time can be used to run the simulation-thread.

Ideally I'd set up a buffering system where both animation updates and the simulation thread would run a few frames ahead and store results. It won't do to run the animation (kinematic objects etc.) in sync with visual frames instead of in sync with the simulation because then there'll be collisions with kinematic objects where they used to be. The problem is compacted by my animation system clumping objects, bones, materials, lights etc. in one and doing them at the same time.