Discussion Burst Occlussion Culling

Hi,

Burst Occlusion Culling is now included with the experimental release of ECS for 2022.
You will find more information about the experimental release of ECS for 2022 here:
https://forum.unity.com/threads/experimental-entities-1-0-is-available.1341065/
We will post in the forum in the upcoming week to give more information specific to Burst Occlusion Culling.

Our new occlusion system is planned to be a standalone feature, but is currently tightly integrated into the Entities Graphics package.
GameObject support is planned for the future, which requires it to be decoupled from the Entities Graphics package.
The only dependency for the updated Burst Occlusion Culling system is Burst. It is completely separate from the GPU Driven rendering initiative.

We are very eager to get feedback from developers.
Experimental Burst Occlusion Culling in experimental ECS for 2022 still requires manual occluder creation.
Both the fully conservative software rasterization and occluder generation pipelines are incredibly complex.
So our plan is to provide first a very robust heavily optimized software rasterization system with manual occluder generation.
We then plan on integrating developers' feedback in more refined workflows in the future.

Auto Generated occluders, which are in fact in progress, are also part of our next priorities, and they will be out in one of the following releases.

 

Hey there! We've just released Experimental Entities 1.0 for 2022.2 Beta, which allows users to test ECS for Unity and provide us with feedback. We've also shared some customer stories of ECS for Unity being used in production in this post. That being said, experimental packages are not recommended for use in production, so do look forward to the release of ECS for Unity!

 

Currently, only PC and Console are supported, as it uses low level Burst intrinsics (SSE/AVX) for heavy deterministic optimizations. Neon support is in progress, where we are specifically optimizing our method for mobile platforms. Mobile support is very high priority.

The benefit of occlusion culling is very scene specific (sofware rasterization overhead versus draw overhead reduction plus GPU performance improvements), and it is even more specific on some mobile hardware, as some vendors provide an implicit visiblity pass for hidden surface removal. These platforms will still benefit from the draw overhead reduction, but GPU performance imporvements will be reduced, specifically only when the hardware binning is active. Some tiled based deferred renderers actually have an immediate/direct rendering mode that is implicitly enabled for specific scene configurations (and their resulting draw heuristics), so when that mode is active, they will also potentially significantly benefit from our occlusion culling.

 

Game Object support is a very high priority for us, and it is being investigated. The only dependency for our new occlusion culling system is Burst. Though we are prioritizing mobile platform support first, as well as creating a very robust conservative software rasterizer, and having a well defined developer workflow with extensive debug tooling. The Entities ecosystem provides a gateway for us to release our new culling system that is not bound to the performance limitations of game objects, so we can properly optimize and profile our new system, while also getting early developer feedback, which is critical for us so that we can be sure the interface for our new system is well defined based on your feedback.

With regards to Entities versus Game Objects, there are inevitably going to be games that are better suited towards one or the other, but ideally, both can potentially live in concert eventually. Should Entities be hampered by the same performance limitations that are introduced by the dependent feature support of every single rendering feature of game objects?

 

Our in progress auto occluder generation does not support planar surfaces. However, there is no reason we can't just raster the original plane into our encoded depth. This is a feature we are currently trying to investigate the best workflow to support. Though a simple approach is to just give the plane a thickness value for the implict representation so that it can be combined with non-planar geometry. The definition of the simplest representation possible for any mesh that is fully view consistent (inscribed) is incredibly challenging, especially in generalizing this to all geometry in the wild. One thing which is often forgetten with Umbra is that meshes need to be watertight for it to work properly.

There are other challenging geometry, such as terrian that needs to cutout holes for caves. A slight crack can completely kill occlusion coverage. Our inscribed geometry generation can close open (non-watertight) geometry as well as handle degenerative meshes, but how we provide hierachial selection and developer control of occluder generation requires significant feedback, discussion, and further design. We need to make sure it works well in unicence with DCC import workflows so that it doesn't impact tech artist iteration speed.

 

The GPU driven rendering initiative is seperate from Burst Occlusion Culling as Anne mentioned, but ideally, these will work in concert together for broad platform and scene support for optimal and generic occlusion culling, ideally with explicit developer control. The workflow for this and other scriptable culling improvements are being discussed.

 

Not at this time, though full customization leveraging components of the optimized rasterizer and intersection engine modularly is something we would like to drive towards. Can you provide any more feedback in terms of the interface and workflow you would like to have?

With regards to forceRenderngOff, there was a regression in 2019 with regards to using GetForceRenderingOff that has been fixed which landed in 2021.2 and backported all the way to 2019.4, which is a pretty significant performance improvement.

 

We consider this to be critical, but the CullingGroupAPI in it's current form, is not something that we want to support, as there are many issues with the design and implementation of it. There are several issues with the visibility determination with the onBecameVisible event broadcasting, and also the distance checking is not even dependent on occlusion but it is currently locked in the culling results synchronization in the current design. While we are working on fixing the CullingGroupAPI as well at the moment, we would ideally not support this with the new system with regards to the visiblity determination. There will obviously need to be an alternative, which is something we are considering, and we would love any further feedback you might have on this!

 

Currently, in Entitites 1.0, VFX is not yet supported with the experimental occlusion culling. Particles are something that would definitely benenfit very significantly from occlsusion culling. Would you be able to add a comment on the Burst Occlusion Culling product board card in regards to this? It helps a lot with the prioritization of the task.

Terrain is also something we are continuing to discuss the best workflow to handle. It is easy enough to give terrain an implicit thickness to generate an occluder, and while our prototype auto occluder generation can close holes from caves (as well as other non water tight or degenerative geometry), this isn't an ideal approach. There needs to be a proper workflow for merging cave scenes with the terrain height map, which we have been discussing with our environment team as well as tech artitsts, etc. Any further feedback or discussion on this is very appreciated!

Can you provide any more detail about the specialized terrian tiles that are not supported with forceRenderingOff? While this doesn't impact our new Burst Occlusion Culling, it is something I am discussing internally, as I would like to better understand the legacy reasons why that cannot be handled with the exisiting terrian system so that we can further investigate to see if this is something we can support going forward.

With regards to the supported list of renderers, this is something we have added to the in progress development guide, which will be shared with an upcoming pre-release.

 

Sorry for the delay. I was on extended parental leave for a few months.

The Burst Occlusion Culling system is a hand crafted heavily optimized custom design and implementation of masked occlusion culling using the low level Burst intrinsics, jobs, and collections:
https://docs.unity3d.com/Packages/com.unity.burst@1.8/manual/csharp-burst-intrinsics.html

The implementation is explicitly vectorized to maximize performance and minimize added latency, and requires both SSE/AVX and Neon backends for full platform support. The system supports dynamic objects and it is fully conservative (zero popping), which are both very challenging requirements.

Also, automatic generation of occluders is being investigated, which ideally would support degenerative (and even potentially non water tight) meshes. The automatic occluder generation system is as complex as the culling system itself. Umbra requires water tight and non-degenerative geometry, so if you want Umbra to actually work, you need to properly process your meshes before using them with Umbra, which can require a lot of manual mesh processing, and causes a lot of problems if not done properly.

We are also building up test frameworks, samples for validation, continuously profiling, conducting user interviews, and writing the manual documentation, while also supporting the entire legacy culing system.

For updating very large sets of dynamic state, ECS is a requirement. This question is better asked in the Dots forum, as this post is specific to Burst Occlusion Culling, which isn't actually specific to DOTS, but there is a lot more work required to support game objects, as the feature support is much broader.

The new Burst Occlusion Culling system is still in experimental. It should not yet be used for developing production systems. There is a lot more discussion on workflow that needs to be done to improve the usability and iteration time. We have been conducting user interviews to get more feedback in terms of expectations for supported workflows.

The collections package is specifically the most general and powerful.

I really recommend posting some of those questions in a new thread in the Dots forum, as Burst Occlusion Culing, while the system supports Entities Graphics, it doesn't have any dependency specific to ECS.

Though there are inherently games that are much more well suited to ECS (games with a huge amount of dynamic state) or games that are better suited for traditional game objects. There is not just one path for all games. You need to think about the initial design and the evolution of the game to know if you should leverage ECS in some way.

Entities Graphics is built on top of the new BRG API, which is independent of ECS:
https://forum.unity.com/threads/new-batchrenderergroup-api-for-2022-1.1230669

 

Hi Avol,
We are still supporting Umbra for now.
You should definitely make a report with a test project or steps to reproduce it so we can try to find the origin of the bug.

 

Hi @CaseyHofland
We have provided an update in the latest DOTS development status and next milestones on Burst Occlusion Culling.
After doing a lot of testing, even though we are satisfied by the approach taken, we have not yet reached our performance expectations. While we are still working on improvements, we have decided to remove it from general availability.

But I recommend that you take a look at the GPU occlusion culling that will be available in Unity 6.
It is displayed in Unite 2023 keynote in the demo from Mathieu and Elaine.
You have a thread available here also that provides more information on GPU Resident Drawer in general.