Visibility Buffer

1 year ago by mpollind

Share this post:

I've spent a bit of time working on implementing a visibility buffer. I've been in the progress of moving the engine to be bindless. I allocate 2048 descriptors and have a scheme of moving textures in and out of the pool when they are needed. As long as the material doesn't change the texture is still in the pool; not the most optimal solution but haven't run into any issues yet, when loading a new map materials should be recycled in the pool as soon as they are freed.

For geometry I have a single large opaque geometry set for the geometry in the scene. I'm using a library to manage sub allocation of vertices from these buffers. I've chosen not to interleave the data just for the sake of flexibility, not sure about the performance benefits of interleaving in this scenario. makes access fairly easy, I just bind these in my constant set and access them in my main pass. quite a lot of added flexibility without worrying about binding and constantly updating descriptor sets. CPU spends very little time for the main render pass so the render becomes more GPU bound.

https://github.com/sebbbi/OffsetAllocator

The fragment pass that produces the color image in short is a process of looking up the triangle/object/material and fetching the textures to render the fragment. gradients are lost but they are re-deriving knowing the position of the fragment relative to the triangle. something something barycentric coordinates and partial derivatives. I'm currently not doing much optimization with building the visibility buffer and will probably just use the visibility buffer as apart of my pre-z pass. the cost of encoding the object and triangle is a trivial cost. this lowers a lot of the memory pressure with the original deferred renderer. should be a lot easier to run the game at a much higher resolution since I forgo needing a lot of very frame buffers.

The hi-z buffer I was using to test against introduced a massive stall in the pipeline waiting for the data to resolve in a roundtrip from the GPU back to the CPU when I was trying to filter objects from drawing. This replaces the 4 targets with a single R8G8B8A8 target to encode the object + triangle. might be of use to also think about merging meshes since everything is available in my single large buffer. could also just generate the tries on the fly in a more compute driven system but I would rather re-implement all the features I lost with this direction change. Lot of preparatory changes had to be made to get to this stage. there are a lot of really neat possibilities with ditching a deferred pipeline.