VoxelMesh API: SetVoxelData


This function allows you to pass the voxel data in a specific format to avoid calling SetVoxelBox multiple times.

Proposed data structures:

  1. Three-dimensional table containing the voxelasset references where indexes represent the position of the specified voxel multiplied by 25 (one voxel size).
    Optionally we could also pass an offset vector as a second argument

    Example: Drawing of a 3x3x3 cube of sand with water voxel in the center would look like that:

local sand = self.properties.primaryVoxel
local water = self.properties.secondaryVoxel

      {sand, sand, sand},
      {sand, sand, sand},
      {sand, sand, sand}
      {sand, sand, sand},
      {sand, water, sand},
      {sand, sand, sand}
      {sand, sand, sand},
      {sand, sand, sand},
      {sand, sand, sand}
  1. Another approach will be a table of tuples where the first element of the tuple is the Vector and the seconds one is the voxelasset reference.

  2. As the third approach we could pass two arguments where the first one is the voxelasset reference and the second one is the table containing Vectors describing where this voxelasset has to be applied.
    This approach will require slightly more calls of this function but allow creators more control and visibility over voxel material positions.

I am aware that there might be some limitations over the amount of data we could set in one go and this functionality might not be easy to implement but I believe that is a necessary step toward getting more sophisticated voxel builds that might be relying on the external data like voxelised 3d models or prebaked procedural terrain.


Sincerely I don’t understand why not simply asking for an proper importer.
The real issue about importing data is the lua runtime limit of 1 second and the fact of not being able to save mesh done in lua and it’s not a fault of the api.

Staying in the no proper importer zone and this kind of api for a manual import, I would not rely on uncompressed data also slow to parse for the interpreter, but on some precompressed run lenght encoding / box data.

A possible modification of the api could be the introduction of modification transaction so you can signal when you start and end your modification for that mesh on that frame so that the engine can start mesh generation jobs as soon as you end your modification and not at some fixed point of the frame pipeline.This is however very implementation specific and even if can help performances doesn’t help at lua side.

Your point makes perfect sense to me but I was asking specifically to have that function so we could do procedural manipulation of the mesh at runtime using slightly more complicated shapes to dramatically reduce the number of operations.

Every time you call SetVoxelBox it has to recalculate collisions and sync the mesh with clients. And it can get very slow and fall over 1s limit if you don’t utilize Schedule/Wait (even then it is hard to make sure your code won’t timeout)

The importing part was more of a selling point for other creators :).

BTW, as far as I’m aware the Lua runtime limit is not set in stone and we could potentially ask to increase it. It used to be 5 seconds when I was working on my terrain generators.

Ok got your use case now. and now that you make me think that transaction api should also help in your case as it would sync only after the modification ends and as soon as it ends.

Another possible solution to your use case could be to have premade voxel mesh and stamp it at position with a function like this:
Entity:VoxelMeshStamp(vector position,vector rotation, voxelmesh you want to stamp)
In the case of rotation the engine naturally should then snap it the outer mesh at nearest 90degree snap)
another version of the function could just have position and orient stamp in outer entity space.
With mesh stamping you could skip the part where lua mess with voxel data completely.

1 Like