EveryCulling VS gl_occlusion_culling

And I have been trying to make game engine faster. So I implemented SW ViewFrustumCulling(https://www.ea.com/frostbite/news/culling-the-battlefield-data-oriented-design-in-practice) and SW Occlusion Culling ( Masked SW Occlusion Culling, https://www.intel.com/content/dam/develop/external/us/en/documents/masked-software-occlusion-culling.pdf ), Distance Culling from unreal engine. You can see source code at here ( https://github.com/SungJJinKang/EveryCulling )

And Data layout is defined for multithreading. You can see at here https://github.com/SungJJinKang/EveryCulling/blob/main/DataType/EntityBlock.h. Every entities's datas is stored in this EntityBlock. EntityBlock has 16 ~ 24 entities datas. Then Each threads work on a entity block. It makes no requirement for lock to prevent data race. And It prevent false sharing because threads works on different cache line.

A low-latency (and frankly better) alternative to hardware occlusion queries is to make your own using indirect drawing. Simply draw a chunk's bounding box against the depth buffer and set the instance count of the indirect struct to one if any fragments are drawn. The next frame you can use these indirect commands to draw the actual chunk geometry and repeat the whole process. This has a guaranteed latency of one frame. More info here.

One approach is to use occlusion queries, draw chunks which were visible last frame and then occlusion test the bounding volumes of chunks which weren't rendered and render the ones which pass using a shader based occlusion approach similar to this NVIDIA sample: https://github.com/nvpro-samples/gl_occlusion_culling

For occlusion culling, specifically, there’s this reference implementation: https://github.com/nvpro-samples/gl_occlusion_culling