Refactoring Fluid Mesh Rebuild Time

[lucasdamianjohnson]

So, this will be something I work on after the release of Alpha 1.0. But it is just something that I noticed after I increased the size of the "Dream Space" world and tried removing fluid source blocks. The rebuild time is very slow with a bigger world. The reason being is that the fluid mesh is totally rebuilt every time a change is made. The chunk template that describes the resulting mesh data is cached and then used to rebuild the entire mesh. This is so the fluid mesh can be one big mesh and allow for the fluid shader effects to properly work. So, here are my ideas going forward with this:

1. See if there is a way not to have to combine the fluid mesh together for the shader effects to work (though I doubt this would work I could be very wrong though and will need to do more research)
2. Create a way to parallel process the chunk templates and build the resulting fluid mesh.

How would I go about the second option?

• First, after each chunk mesh is generated cache all the sizes of the resulting arrays.
• Second make sure all chunk templates are synced in the multiple fluid builder threads.
• When it comes time to build the mesh build the new one first, then create an array with a Shared Array Buffer that would be big enough to store the needed mesh data [positions, indices, colors...).
• The world thread would send to each fluid builder what chunk to rebuild and the index and length to start adding to the shared mesh data array. The size of the array would only be calculated after rebuilding the new fluid meshes.
• Once complete it would just send the data over to the render thread like normal.

Either way, I will need to do so more research and thinking before I start on this. I just wanted to get this as an issue to let people know that I know it is problem and that I am working on solving it.

Also, another big problem to consider when dealing with the fluid mesh. How will the engine handle building the fluid mesh when on a server and giving that data to a client? Maybe the mesh is built per-client connected rather than one just per world. But that is something I will have to deal with later.

[lucasdamianjohnson]

Currently, the only thing that I can find related to not combing the meshes directly is this: Seamless, endless, and performant custom water using skinned meshes and PBR

[lucasdamianjohnson]

I asked a question about this on the Babylon.Js forum about this: Link To Question

I guess I will see if anyone has an answer before I dive into my other ideas.

[lucasdamianjohnson]

So, I did get an answer and with that, I was actually able to do what I wanted to do. I can actually totally get rid of the Fluid Builder thread! The problem was that I was using the mesh space position now the world space position for the noise function to produce the waves. I am pretty happy and will include this update in the Alpha 1.0 release. I will close this issue once I make the engine no longer use the Fluid Builder thread.

[lucasdamianjohnson]

All right I got rid of the fluid builder in the latest commit. I updated all the examples with the new code So, I am closing this out.