chore(rendering): migrate chunk mesh generation Flux #4786
Conversation
github-actions
bot
added
the
Type: Refactoring
| for (int i = 0; i < vertexBuffers.length; i++) { | ||
| int id = vertexBuffers[i]; | ||
| if (id != 0) { | ||
| GL15.glDeleteBuffers(id); |
There was a problem hiding this comment.
Why use GL15 but change other occurrences to GL30?
There was a problem hiding this comment.
they end up mapping to the same call.
|
What's the difference between this and #4783? |
Just trying something different. |
pollend
changed the title
…actor/migrate-chunk-mesh-generation-flowable
…hub.com:MovingBlocks/Terasology into refactor/migrate-chunk-mesh-generation-flowable
|
This also works quite well, and I don't see any noticeable stuttering or delays. However, the overall performance seems to be lower than of the previous PR, as I can easily reach the border of generated chunk (with I tested this together with #4773 in a Metal Renegades world. |
try increasing the parallelism. I have it at 4 but we could go with 5/6 |
…hub.com:MovingBlocks/Terasology into refactor/migrate-chunk-mesh-generation-flowable
…hub.com:MovingBlocks/Terasology into refactor/migrate-chunk-mesh-generation-flowable
They are beginning to look readable.
…hunk-mesh-generation-flowable
github-actions
bot
added
the
Type: Chore
…est/chunkmeshworker
As it is now, being able to pass a different source flux there did not improve testability.
Every usage of setMesh had this, so it seemed safer to make Chunk responsible for this operation.
…ration-flowable' into test/chunkmeshworker
… optimizations we probably don't need
…hunk-mesh-generation-flowable
…est/chunkmeshworker
…r-independent Because they run in parallel, if there are only two of them, either one may return first.
…hunk-mesh-generation-flowable
…est/chunkmeshworker
|
Oh boy: it's just over six weeks until this PR's birthday. Reviewing the comments above, it looks like the blocker here was that it either didn't have tests or the tests it had weren't passing in CI. Now I've merged #4987 and we have passing tests! I'm sure there are follow-up things I would have liked to do (following a "make tests to pin down behavior, then change implementation while supported by tests" pattern), but I don't remember any of those things being necessary for this pass. I think it's time to re-review this, do a little more hands-on testing to make sure merging #4987 didn't foul things up too badly, and maybe we can finally wrap this thing up. |
|
This looks good to me. I don't see anything wrong per say. |
This is a rework of the chunk generation logic with Project Reactor. I do away with ChunkMeshUpdateManager and remove pending mesh from Chunk since all the state information is contained within the Observable. I also added a way to sync the mesh updates back onto the main thread so all the mesh data is generated on a background thread and passed back over to the main thread to upload the data to opengl.
Contributes to #4798