Tiogra System Integration

System Overall Architecture

One of the key principles to the client is to have multiple background tasks that assemble and prepare for rendering. Communication between the client tasks is typically via FIFO queues. Volatile data such as rendered class information may be thread locked for operation.

The queue system extends to network communications with the server. For example, if the player tries to move via the user interface, the UI sends a request to the client physics engine. The client physics engine requests the move locally (to PhysX) and sends the request to the server. The server will evaluate the request and send a response with a potential correction. This response is marshalled to the physics engine and it will handle any updates.

PhysX is one of the client weaknesses. This is because I do not have direct access to it's compute shader. Rather than being able to use the height map for example, I deserialise a seperate collision map. There are also several other reasons why PhysX will be phased out. The physics engine, which encapsulates PhysX controls all movement and has the closest thing to a traditional Update function.

The storage worker class has several large streamed files locked open. These files provide height, diffuse, normal information etc. The files are monolithic but ordered into chunks so that a 'chunk' can be read sequentially. This information is streamed striaght to the GPU.

The persistent game information is stored on a SQL database on the server. There is currently no snapshot or rollback system. The Physics and AI on the server do not communicate directly, they act upon the database independently. All server side requests are marshalled by a Web API service.

Deferred render commands are the key to render preparation. For example, if the player moves and needs to load new area information, this is streamed from the storage system (if not already cached). The operations required to update the GPU maps and buffers are built as a command list. The render thread will run these commands when it is ready. This operation involves a thread lock toggle. The background assembler will pause some operations while rendering is being carried out. It will also stagger some requests that have potential performance impacts if attempted all in one render pass.

Thread Locking System