Author Topic: Support for shapes other than cubes  (Read 891 times)

JSwigart

  • Newbie
  • *
  • Posts: 16
    • View Profile
Support for shapes other than cubes
« on: December 06, 2018, 04:36:40 PM »
It'd be great to have support for chunk level block types other than cubes. I don't know where the ultimate trade-off is with regards to choosing what to include in the chunk pipeline versus what to use custom voxels for (even when instanced), so I'll just explain the functionality that we have in our game.

We have support for something like 10 or so geometry types at the chunk level. These geometry types are ultimately baked into the chunk mesh and support configurable chunk occlusion. It's a little crude to configure, but that aspect can be simplified for the user with a bit of editor work.

We support the following shape types, and there is always a desire to add more, but it comes against heavy resistance since there is a whole pipeline of code modifications that often have to come with each one. we're not very data driven at all right now.
cube, sixteenth(vertical), half, slope, slope_inner, slope_outer, stairs, stairs_inner, stairs_outer, sixteenth(horizontal), fourth, eighth

The reason we did these more at the chunk level and not with a separate object like the custom voxels is because these shapes all support face occlusion, and since they were ultimately baked into the chunk, their final rendering cost was kept low, even though the chunk build process was complicated to support them. The part I'm unsure of is how suitable a small set of extendable 'base shape' meshes could be supported at the level of the build process(geometry shader, etc). Or how scaleable it would be to do all these shapes not as chunk data but as custom shapes instead. Like, how necessary is this process? I suppose the first step might be to attempt to get a worst case world build prototyped in VP with the special blocks all as custom blocks, and then see where performance is with instanced rendering and batching being the only things available to reduce the cost.

In order to facilitate the occlusion information with these custom shapes, we had the ref meshes subdivided into a directional identifier and a bitmask that representing the occlusion conditions of that face.

For instance, see attachment. Each submesh of this reference mesh has a bitfield associated with it that configures its occlusion settings. I would do this on a component rather than how we did it with a naming convention sort of thing(screenshot example)

With this occlusion information, the chunk building process, and presumably in VoxelPlays case, the geometry shader, etc, could build out a good chunk with varied shapes with visible faces culled.