Refactor Meshing/Rendering communication #13

EmaMaker · 2023-10-04T13:51:10+02:00

EmaMaker commented

2023-10-04 13:51:10 +02:00

The refactor decouples the updating thread and the rendering thread.

The latter should not use any information about the chunk itself, only about the mesh. Previously, some information about the mesh needed for rendering was stored in the chunk itself (VAO, buffers, number of vertices). Synchronization between the meshing and the rendering thread is needed because communication with the OpenGL context can only happen in the main (rendering) thread

With this new system:

The meshing thread prepares a struct containing buffers and other mesh info
The struct is sent to the rendering thread using a lock free queue (concurrent_queue)
The render thread holds a table (concurrent_hash_map) which associate a chunk index (only the index, not the chunk) with its mesh.
The rendering thread consumes an element from the queue. If it's a new element, buffers are allocated on the GPU. In any case, the mesh is updated
The update thread can communicate with the rendering thread to request the deletition of the mesh of chunks that were already deleted. Again, only the chunk index is used, never a reference to the chunk itself.

This also avoids storing mesh data inside the chunk, which now effectively only holds data about the world

Also refactor the file structure for more organization and to keep things where they belong (e.g. ChunkMeshData should be initialized in chunkmesher, not in chunkmanager)

The refactor decouples the updating thread and the rendering thread. The latter should not use any information about the chunk itself, only about the mesh. Previously, some information about the mesh needed for rendering was stored in the chunk itself (VAO, buffers, number of vertices). Synchronization between the meshing and the rendering thread is needed because communication with the OpenGL context can only happen in the main (rendering) thread With this new system: - The meshing thread prepares a struct containing buffers and other mesh info - The struct is sent to the rendering thread using a lock free queue (concurrent_queue) - The render thread holds a table (concurrent_hash_map) which associate a chunk index (only the index, not the chunk) with its mesh. - The rendering thread consumes an element from the queue. If it's a new element, buffers are allocated on the GPU. In any case, the mesh is updated - The update thread can communicate with the rendering thread to request the deletition of the mesh of chunks that were already deleted. Again, only the chunk index is used, never a reference to the chunk itself. This also avoids storing mesh data inside the chunk, which now effectively only holds data about the world Also refactor the file structure for more organization and to keep things where they belong (e.g. ChunkMeshData should be initialized in chunkmesher, not in chunkmanager)

EmaMaker added 6 commits 2023-10-04 13:51:24 +02:00

d0ddf2256f move chunkmeshdata into its own file

And let it be managed by chunkmesher instead of chunkmanager

1822911845 chunkmesher: use goto for error handling

7786d4f04d renderer: use ChunkMeshData from rendering thread

This system decouples the Secondary threads from the Render thread. Once a chunk is meshed, only the mesh data is sent to the rendering thread, which does not use any direct reference to the chunk itself

7c82a71dd0 chunk: vram buffers are managed by renderer now

ba95db4678 renderer: also delete meshes of old chunks

78b65894b7 chunkmesher: compiler flag to not show borders at world limit

EmaMaker added 1 commit 2023-10-04 13:52:13 +02:00

a4f1e5fc1f Merge branch 'main' into multithread-refactor

EmaMaker merged commit 8544620899 into main

2023-10-04 13:52:34 +02:00

EmaMaker referenced this issue from a commit

2023-10-04 13:52:57 +02:00

Merge pull request 'Refactor Meshing/Rendering communication' (#13) from multithread-refactor into main

Sign in to join this conversation.

No reviewers