Sign in to follow this  
ccherng

Game logic thread, rendering thread, animation/inverse kinematics, and synchronization

Recommended Posts

ccherng    165
[color=#333333]In a multithreaded setup with a game logic thread and a render thread, with some kind of skin mesh animation with inverse kinematics plus etc how does animation work? Does the game logic thread just update a number saying time T in the animation and then the render thread infers Who owns the skin mesh animation, the game logic thread or the render thread? How is it stored in the scene graph if it is stored there at all? When the game logic updates does it do the computation of the skin mesh animation and the computation of the inverse kinematics and then store the result directly in the scene graph or is it stored indirectly and the render thread does the computation[/color][left]. [/left][color=#333333]And how does synchronization between game logic and rendering work to prevent writing and reading game state at the same time?[/color]

I know that similar type questions have been asked but I've never been satisfied with the answers. I would be very interested in seeing how the game architecture components of a multithreaded triple buffered animation with inverse kinematics all fits together to ensure no race conditions.

Share this post


Link to post
Share on other sites
Ashaman73    13715
You will not get a clean answer for your question. Multithreaded applications are really hard, especially when you are developing a real-time application like a game, where you need to omit most useful standard OS features due to the heavy performance impact.

[quote name='ccherng' timestamp='1341436024' post='4955743']
And how does synchronization between game logic and rendering work to prevent writing and reading game state at the same time?
[/quote]
There're several ways to do it (lock-less,mutex,critical-section,buffered), each has its advantages and disadvantages, but which way to go depends heavily on your multithreading architecture of your engine. You can't just pick a single feature out and create some multithreading solution for it. You need to consider the whole architecture first before going into detail.

Share this post


Link to post
Share on other sites
Daivuk    413
The way to do it is not to thread rendering and updating simultaneously, but instead threading operations that cost a lot before proceeding to next operation.
Instead of threading big modules against each others (update, rendering), thread the tasks into those modules.


Update()
Thread all entities' physic.
wait that they are all complete

Thread path finding. Like calculating path for 4 units at the same time, in 4 different threads? (i.e.: if 20 paths to calculate, split evenly 5 in each threads)
wait that they are all complete

Thread the next big job
wait the threads for that job are complete.

Render()
Thread the culling of all entities
Wait that culling is done computing.

Maybe thread the swap buffer to start updating the next frame? (It might stall there to wait for vsync, you could update next frame during that time!)
I did that in a game we did and it worked greats, we gained speed on lower spec PCs.


It's a more intelligent way of using threading in games. And also what I like to do, is count the number of cores/processors available and use that as the number of threads to start for each big jobs.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this