Game thread, render thread, animation/inverse kinematics, and synchronization

Question

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?

Answer 1

First of all, the question is too complex and unclear, but I'll try to answer it anyway.

"How does animation work?" - you can design however you want.

"Who owns the skin mesh animation, the game logic thread or the render thread" - what do you mean? Threads are just execution contexts. If you want to, with caution you can share data across threads, since all threads share the same address space ( -need to ensure no race conditions i.e. harder to design and debug; +saves RAM).

"stored indirectly and the render thread does the computation" - you can design however you want. The correct answer depends heavily on the CPU and RAM usage. If the computation is really cheap, but produces huge data set - you'll probably want to compute it on the main thread to save RAM. If however the computation is expensive but produce small dataset - you'll probably want to compute that on some other thread, store the result somewhere in RAM, and have the renderer thread get that result and update your scene graph with the new data.

P.S. I suggest you to read the following article: Designing the Framework of a Parallel Game Engine, esp. section #2. And this one: Multithreading the Rendering Pipeline for 3D Model Animation - as you can see, they choose to duplicate the modified data across threads.

Answer 2

Don't design your threading like that. The idea of giving each system its own thread is not a good way to actually utilize the system. Game play and rendering really do work in lock step (if there's no gameplay update, there's nothing new to render). More importantly, there's only a few subsystems to a game engine, but there are a lot of cores in today's machine, and the core count is only increasing.

A better approach is to use a batch/job system. Run each system in lock step, but split up the work of the systems into threads. For rendering, that'll mostly be occlusion culling. For gameplay, it will often be path finding, and maybe ray casting and AI occlusion tests. For physics, it'll be various islands of separated objects.

One of the only systems worth giving its own dedicated thread is audio, and that's only because audio is super ridiculously sensitive to latency and stalls, far far more so than any other part of a game.

Once you design threads around batches instead of parallel systems, the ownership problem becomes much simpler. Instead of worrying whether gameplay or rendering owns a mesh, you instead know that only one or the other is touching the mesh at any given time. Your rendering jobs are then split into completely isolated batches of objects, so again there's very little contention to even think about.