[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=#333333]And how does synchronization between game logic and rendering work to prevent writing and reading game state at the same time?

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.

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.