Outerra Engine > Technology

Threading and process modularity?

(1/1)

thumbedmonkey:
This is a question that broadly covers multi-player and modularity of your code.

Have you given any thought to how the different functions such as the Bullet physics and JSBSim could be run on separate cores, or even separate servers? While your demos look wonderful, I would like to see what happens when you have a dozen ground vehicles running around and INTO each other.

The first and most obvious way to optimize this is to run each vehicle on a separate machine. Could one or more machines serve as an image generator while other entities are driven (on separate machines) via waypoints and other software-driven behavior handlers? Many of the multi-entity simulations I have used have very few humans in the loop.

cameni:
Well the engine was designed with modularity in mind, there is an engine thread that manages view-dependent terrain processing, and a renderer thread that feeds the graphic card using the data from the engine thread. Terrain generation and asset loading are all asynchronous, running in their own job processor threads or in allocated time slices in the main thread.

The physics isn't really tied tightly to it - it can run in a separate thread or be a part of the engine thread processing or the object state updates can come over the network (as would be the case with Aerowinx 744 sim, for example).

One thing that is open is how a remote physics processing is going to handle terrain collision data. The terrain is refined by fractal algorithms to obtain a good precision, and the collision meshes are asynchronously read back from GPU after they've been generated. So it would have to be delivered to the remote machine dynamically. Alternatively, the remote machine could generate the same data by itself.

Navigation

[0] Message Index