by Rajshree Chabukswar, Adam T. Lake, and Mary R. Lee, Intel® Software Solutions Group
Introduction
Learn how to decouple rendering and physical simulation in a multi-threaded environment with a simple physical simulation demonstration. The sample code provided with this paper can either be used as an example or adapted directly into your game engine.
This paper demonstrates bouncing spheres within a cube with sphere-sphere and sphere-plane collision detection mechanisms implemented using Newtonian physics. Initially, spheres collide with each other and the walls of the enclosing cube. After collision is detected, collision response code is executed to calculate the new velocity. The user has an option to run either a multi-threaded or single threaded version. Threading is implemented to compute physics equations in a separate thread while rendering takes place in the main thread.
The goal is to showcase how to use separate threads to perform CPU intensive physics computations independent of the actual rendering process. It is beneficial to use multiple threads to perform different tasks since future processor architectures are moving towards multiple cores. Hence, the performance of an application can be increased by having multiple threads work individually to take advantage of available CPU cycles. The paper first discusses the basics of this implementation followed by the physics concepts used in our demo. Future work and reference section is also included.
Download Source Code
View entire article (PDF 432KB)
Comments
wrong source code download link
I want to download the source code for this article "Multi-threaded Rendering and Physics Simulation", but the source code link is wrong. Could you send me the source code directly through my emial? Or can you fix the wrong link?
The source code link has been corrected. Thank you for bringing this to our attention.
What is the purpose of this design? First of all, the system runs in lockstep with just 1 other thread, so there is no benefit of having another thread. I would only see the benefit in having multiple threads (scaled based on the quantity of cores) to simulate physics, and then return to rendering. There is no point in having 1 extra thread jump in, pause the previous thread, do its' thing and resume the initial thread. Absolutely pointless, Intel - this article was written by an intern, I presume?
At least could have made it useful from the start by using a thread pool, as it stands this is a pointless example of threading - no benefit!
Otherwise, add something interesting - like another thread that does something which would alter sphere's velocity/position, like a "Wind" thread (parallel to physics and rendering sim with direct interference). This way you could demonstrate at least some decoupling or synchronization technique (avoiding using a mutex).