Help with deciding best Parallel Terrain Generation implementation (or none at all)

I have been working on make my voxel terrain generator and I was thinking of utilising Parallel Luau to make it performant. However, it is difficult to find a suitable compromise between performance, and storage efficiency. Here are my options:

  1. Stick to serialised generation, using buffers to store a chunk’s data, so that chunks are more space efficient and performant to read and write to. However main thread is overworked and other threads are not utilised.
  2. Use parallel Luau where each worker thread has a local buffer it writes to, then use a bindable event to send that buffer from the worker thread to the main thread to keep all chunk data in one place. Downsides: Bindable event may be slow (i’m not sure tbh). Advantages: Chunks are stored in buffers, saving space.
  3. Use parallel Luau where each worker thread writes a string of voxel data in a shared table, so no bindable event needed and seemless data transfer. My only concern with this implementation is the storage and performance implications of using string rather than buffer, however I don’t know much about strings in luau to know its drawbacks (if anyone could shine light on this topic I would greatly appreciate it)
    I would love if buffers could be values in shared tables but alas roblox did not implement that :pensive:

How frequently are you going to access the buffer? :derp:

After a chunk and its neighbouring chunks has been generated, the buffer is accessed basically every time a player breaks or adds stuff, or destruction happens (which is usually the player’s actions that cause it).
I haven’t implemented entity pathfinding yet so idk yet if I would use roblox built-in pathfinding or utilise A* pathfinding using the buffers.

If you’re going to add functionality where items can also cause chunk updates (like minecraft) you should go with serial. :arrow_forward:

Going with parallel luau may make it difficult to do tasks where items have to signal chunks.

If you’re not adding complex logic though and updates don’t happen that much, you should go with parallel luau!

I guess you could also use the buffer.tostring() method to store buffers in sharedtables?
Could be kind-of inefficient though wouldn’t actually recommend using this.

hmm alright I see, I would stick to serialised for now until I can design proper coordination between multiple workers for chunk manipulation.

1 Like