Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement a more efficient voxel renderer #14674
https://github.com/mono/sysdrawing-coregraphics/blob/master/Utilities/ClipperLib/clipper.cs implements polygon intersection, which would make this much simpler.
There are two problems with the proposal above:
I've come up with a slightly convoluted way to split the required data across our normal vertex, sprite, and palette locations. This means we could in principle render sprites and voxels using the same shader if we are happy to deal with wildly different branches in the FS.
Add 3 new floats to the vertex format, then define the instance-specific data as:
X, Y, Z: position in the world (as normal).
The voxel data is flattened to a 1D buffer that is concatenated together in a sheet layer. The first three bytes are reserved to hold the width, length, height of the model, followed by the color and then normal data.
The offset to this data (i.e. the u,v,channel coord of the first pixel) is stored together with the normals palette row in the "metadata palette" referenced by the J,K coords in the vertex data. The buffer is read by scanning across the sheet, stepping to the next row when the edge of the texture is reached, for a length of 2 * W * L * H + 3 per voxel section.
When rendering a fragment we use J,K to look up the palette and then use that to look up the voxel data header. The header is used to define the mapping from voxel x,y,z coordinates to the color and normals index in the sprite sheet. We then step along the vector defined by S,T,U,V,P,C to find the first non-empty voxel, and then use the mappings to look up the color and normal values from the palette. The normal vector is then rotated by the inverse of V,P,C to get it into screen space before dotting it with the global light vector stored in a uniform. The lighting-adjusted color is written into FragColor, and Z + <length walked along the vector> is written into FragDepth.
@chrisforbes do you see any issues with this?