Graphics [RELEASED] Perfect Culling - Pixel Perfect Occlusion Culling

Thanks for the help, I pulled the trigger and got the asset, going to try it in depth right now. Sure it will bake slowly on my old machine but I don't care too much, it's all good as long as it works. Reaching you out in a moment!

 

I just submitted version 1.1 for review:

Code (CSharp):

1. FIXED: Exception caused by ToggleRenderer during scene changes
2. FIXED: Renderers that use sub-materials failed to render correctly in some configurations
3. FIXED: Harmless error spam caused by URP Lights when bake performed using Unity Renderer
4. FIXED: Camera aligning to wrong cell in multi-volume setups
5. FIXED: LODGroups not correctly taken into account when added to volume (please clear your renderers and re-add them)
6. FIXED: Potential baking issues caused by rotated volumes
7. Parallelized Merge-Downsample step to make it significantly faster
8. General bake performance improvements
9. Custom handls for more user-friendly volume scaling
10. API to exclude cells from bake by placing volumes and/or custom scripts
11. Added tag object to exclude renderers from culling
12. Bake API allows to pass in additional occluders
13. Ability to perform baking on the CPU (not recommended but should help for less powerful devices)
14. Added option to change the out of bounds behaviour for volumes (cull the entire volume instead of clamping to nearest cell)
15. Show error message when invalid renderers are detected
16. Many smaller quality of life changes
17. Additional documentation

I also tried to update the documentation and create some new documentation as well. Since I got some requests for reading the documentation to learn more about how it works and what it can do I also attached the current documentation to this post. So maybe this is helpful for some of you.

I will let you all know when the update is available. Feel free to reach out to me if you want to get it ahead of time.

EDIT: Version 1.1 is live. I'm already working on a 1.1.1 release though

 

Hello,

Before purchase I have a question, how occlusion data are linked to renderers in the scene? I have a big prefab with child renderers, but between these renderers in the hierarchy I have some dynamic game objects (like player, particle systems, audio sources, etc), which can be destroyed, spawned or reparented in runtime (or in Awake). So will culling work after these changes in the hierarchy?

 

The asset directly references the Renderer itself. Concluding that hierachy changes shouldn't be a problem.

I hope this answers your question. Definitely feel free to reach out to me if you run into any issues though.

EDIT:
I also just finished uploading an updated tutorial video for the upcoming version 1.1.1:

Should definitely be more helpful than the very old and outdated video tutorial. Though in general I'm definitely not great at making these, I'm afraid.

 

just watched the video looks great, does this work with non static Gameobjects that move around such as NPC's or spawned players say in a multiplayer or would I need to add my own layer to manage there occlusion.

 

You need to bake the occlusion thus I'm afraid that fully dynamic objects such as players need you to add your own layer to manage there occlusion.

I'm also experimenting with culling fully dynamic objects but I haven't found a good and performant solution yet. If you got any ideas how the asset could help you here please let me know. Maybe the ability to get a callback when a Renderer becomes visible could give enough information to implement an additional layer that could cull dynamic objects? I'm very open minded for new ideas here.

 

Hi.
I am getting an error when loading a scene. Both scenes, the previous and the new are using perfect culling.
The new scene always starts paused showing a render error. If I unpause the scene in the editor all goes normal again. It seems to be an initialization error on Perfect Culling. The problem is the builds always freezes on this point.
It is VR using Quest and XR setup.
Any ideas?

 

Just downloaded the update and it seems to resolve the problem.

 

Glad the update resolved the issue for you. I can confirm that I fixed this specific issue in the updated version. Sorry about the issue.

Definitely let me know if you run into any other issues

 

Also if you updated Perfect Culling from a version earlier than 1.1 and you make use of LODGroups you want to clear all renderers from your volume and re-add them after you updated to version 1.1. There was an issue that would result in renderers getting culled for no reason because the other LOD levels had not been added to the volume correctly. This was fixed but requires to re-add them for the fix to take effect.

If you are not using any LODGroups this is not necessary though.

I hope this helps. Anyway always feel free to reach out if you run into issues.

 

Hi! Love the tool so far, it was incredibly easy to get setup, and even to use the API to collect bake groups and to bake occlusion through my own tools and workflow. However, I have a couple problems I'd love your insight on.

I have a case where I can't seem to get Perfect Culling to cull a renderer even though it is clearly occluded by another renderer. However, this case occurs when the camera is very close to the cullable renderer--separated by only a wall and a short distance. When the camera moves slightly away from location, the cullable renderer is culled. Is there a minimum distance at which the occlusion logic just won't work? (I tested this with increasingly tiny cell sizes for the volume, and it still didn't make a difference. Also, for the record, the camera's "Include Neighbor Cells" field was set to zero.)

Secondly, I have a multi-scene setup, and am currently using one occlusion volume per scene, and baking that scenes' renderers to that scene's volume's bake data. However, the bake process always closes every scene and opens just the active scene, once baking is complete, which really interrupts my multi-scene workflow. (the culprit is line 157 in the PerfectCullingBakingManager). Is there a reason the scene needs to be "refreshed"? I've commented this out in your code, but worry some weird Unity "gotchya" will happen if the scene isn't re-opened.

I appreciate the support! Thank you!

 

Hey,

Glad you like it so far. Happy to answer your questions.

There is no minimum distance.

What is your Merge-Downsample iteration count on the PerfectCullingVolume? It basically is performing the same as Include Neighbor Cells (on the camera) but it bakes it into the data itself.

Generally this is how I'd debug this problem:

• Enter Play Mode and move your camera to the problematic location
• Select the PerfectCullingVolume and press "Replace scene material with bake material"
• Select the PerfectCullingCamera and press "Align with clostest grid cell"
• Check if your renderer is visible

If your renderer is visible this way that is already your issue and you need to figure out why.
If your renderer is not visible it should be culled and it might be a bug (assuming that you are not making use of Include Neighbor Cells nor Merge-Downsample iteration).

Some situations I could imagine:

• Renderer is picked up being transparent (add pc_opaque to the material name to force it to render as opaque and rebake).
• Sampling position is inside your wall and the backface is culled thus allowing the camera to see through it (add the PerfectCullingRendererTag component to the renderer and check double-sided and rebake). This is my current bet what is most likely happening.

I also attached a Troubleshooting document that I will include in the upcoming 1.1.1 update. Maybe that also gives you some additional ideas.

I'm still working on official multi-scene support but the way how I implemented it during my testing was to just merge all the scenes into one and save it as a temporary one. As a matter of fact you can find this code in PerfectCullingMenuOptions.cs still. It is disabled because it is not ready yet but maybe you can use this approach, too?

The baking process might add or change objects in the scene. Thats why the scene is reloaded in the end to just clean all of that up. I just added to my todo list to investigate a different approach that doesn't require a scene reload.

Definitely let me know how it works for you. I'm always happy to help

EDIT: There is a chance that some of these features are mentioned in my comment or the Troubleshooting document are not available to you yet. I already submitted version 1.1.1 but it is still pending review. I can provide you the updated package if you need it ahead of time. Just let me know.

Changelog for version 1.1.1:

 

I've been messaging Patrick privately, and thought I would share the fruits of our discussion with the forum.

So the problem I was encountering was that the sampling position of the object I was trying to cull was slightly inside the wall, with the side facing the camera not having a backface, thus allowing the camera to see my cullable object! The solution was to mark the PerfectCullingRendererTag on the wall as double-sided (available in 1.1.1).

My solution to my second problem, which is that I have a mutli-scene setup and don't want the baking process to close every scene, was simply to edit the PerfectCullingBakingManager code to: mark the path of the active scene, close that scene, then re-open the scene using the path, additively. As it turns out, not refreshing the scene is super bad! There's a bunch of unwanted scene changes, as Patrick points out.

One-last thing, and this would have solved my first problem: I didn't realize that the only objects that are culled are ones that are visually obstructed by other cullable objects! I had assumed PerfectCulling grabbed every Renderer and performed the culling against that, but that is not the case! To solve this, you can pass in additional (non-cullable) occluders into the bake:

Code (CSharp):

1.  
2. PerfectCullingBakingManager.ScheduleBake(new
3.    PerfectCullingBakingManager.BakeInformation()
4.    {
5.          BakingBehaviour = behaviour,
6.          AdditionalOccluders = additionalOccluders // Provide additional occluders here
7.    }
8. );
9.  

However, it's easier to just cull all the things; and afterall, why not? More optimization isn't a bad thing right?

Anyway, everything works really great now. In the Troubleshooting documents in 1.1.1 Patrick writes "assume the asset is always right". As it turns out, it was right. But the newer version is even more right.

 

Hello! I'm thinking about buying your asset. I got almost all answers I need by reading the forum and watching videos, but still have one more question.
I'm assembling a scene with a bunch of bundles. I got that all of them could have their own PerfectCullingVolume. But these bundles are close to each other in could intersect the view. So my question is:



On the picture I sent there are 3 bundles: blue, green and red. Blue is for floor and that under it. Green and red are different objects. Yellow is the character camera. Will red be culled in this case or not? And should cells of red PerfectCullingVolume cover the space of all blue area? Same for green...

I hope I made it clear enough

 

There is no official multi-scene support just yet. However the Bake API already supports what you would need to make this work:
1) Load all your individual scenes
2) Merge all scenes into a single scene
3) Use the Bake API to pass in all renderers as additional occluders of the other scenes for each PerfectCullingVolume

Code (CSharp):

1.  
2. // 1) Load all scenes
3. int sceneCount = UnityEditor.SceneManagement.EditorSceneManager.sceneCount;
4. Scene[] openScenes = new Scene[sceneCount];
5. for (int i = 0; i < sceneCount; i++)
6. {
7.     openScenes[i] = UnityEditor.SceneManagement.EditorSceneManager.GetSceneAt(i);
8. }
9.  
10. // 2) Merge all scenes into a single one
11. for (int i = 1; i < sceneCount; i++)
12. {
13.     UnityEditor.SceneManagement.EditorSceneManager.MergeScenes(openScenes[i], openScenes[0]);
14. }
15.  
16. UnityEditor.SceneManagement.EditorSceneManager.SaveScene(openScenes[0], "Assets/Temp.unity");
17.  
18. // Just collect all renderers referenced by the baking behaviours
19. PerfectCullingBakingBehaviour[] bakingBehaviours = GameObject.FindObjectsOfType<PerfectCullingBakingBehaviour>();
20. HashSet<Renderer> renderers = new HashSet<Renderer>();
21. foreach (var b in bakingBehaviours)
22. {
23.     foreach (var g in b.bakeGroups)
24.     {
25.         foreach (var r in g.renderers)
26.         {
27.             renderers.Add(r);
28.         }
29.     }
30. }
31.  
32. // 3) Pass in additional renderers as occluders
33. PerfectCullingBakingManager.BakeNow(bakingBehaviours, renderers);
34.  

However you need to bake with quiete a bit of overlap here to make it work. If you world is pretty large this might not be worth it. It is very hard to say.

Furthermore if you are not fluent in C# you might want to wait for official multi-scene support.

I hope this helps. Please let me know if you still got questions.

 

Those bundles are prefabs, that will be instantiated into one scene in runtime.
I'm pretty good in C# so I hope there won't be any problems. Correct me if I'm wrong
- From your code, I could start from the 18th line, since it's already one scene?
- 33rd line is a total rebake? So there is no point in prebaked volumes in prefabs?

 

Yes. The bake is done through the Bake API because you cannot pass in additional occluders without it at the moment. So this would replace the Bake button and you'd always go through this script.

This really just makes sure that the volumes knows about all the other renderers (that could block visibility) in the scene so it can cull accordingly. Just make sure to bake with sufficient overlap or otherwise it might not have information for the positions that are further out and it will look at the closest cell instead (and that might not have the most accurate information).

 

And this bake will be done on every start of that level? Or it's cached somewhere and could be reused?

 

All the baking happens in the Unity Editor and is saved to an asset file that is used at run-time.

It sounds like you are working on a procedurally generated level. In this case you can add a PerfectCullingVolume to your prefabs and bake the individual pieces. Every prefab would have its own occlusion data and instantiating the same prefab multiple times would just reuse the data for all of them. However they will not have any information about other level pieces. So if your level prefabs are very simple this might be overkill and not the way to go.

I attached an image of a scene that uses prefabs with Perfect Culling. There is also an option to disable all renderers if the camera is outside of the PerfectCullingVolume bounds. You can see that the prefabs are still partially visible because the bake only contains information about the prefab itself but not the surrounding level pieces.

 

Hi Patrick,

This looks like a great occlusion solution, and it’s something we really missed from Unity and other assets. Also awesome to see it should support big world by allowing a floating origin. I have some questions to see if this asset can actually work for our use case.

We have a large open world and would ideally use it with our cities or other dense areas. However, we currently have a system in place that allows us to load and unload buildings and its interior. It works by only having an impostor in the scene. When the player gets close, the impostor gets disabled and we spawn in the actual building. When the player gets even closer, we start spawning in the interior. If the player moves away again we can unload all these things and re-enable the impostor.

We do all this to keep our memory usage low and to improve the loading times of our scene by only loading what’s close to the player at the start.

So I don’t really expect this asset to be able to handle this situation out of the box, as it is quite unique. What I am wondering though, is if the API would maybe allow such a workflow.

In editor we are able to enable all objects, so baking it should be no problem. But the system will not be able to resolve the buildings and interiors when we spawn them in. Would the API allow us to add the meshes we spawn in to system. Or would this maybe be a feature we could add ourselves without too much trouble (I know, that’s relative).

Thanks.

 

Hey,

I think there is a couple of options how you could handle this. Internally the asset stores an array of PerfectCullingBakeGroup which also contains an array of Renderers. You could add or remove your Renderer from this array and thus take away control over this Renderer from the asset.

Another option is to keep the Renderer component alive, unload your mesh, disabe the GameObject. Or in other words you just need to make sure that whatever is referenced in this Renderer array is always valid or you'd run into a NullReferenceException and the asset expects the Renderer to be valid (checking for null is expensive).

What you also could do is iterate over all the PerfectCullingBakeGroup, remove all the renderers but keep track yourself what group that Renderer was referenced in. That way you can use that information at run-time to remove or add that renderer from the Renderer Array. It might also be a good idea to make the Renderer Array a List for this reason.

For the baking process I'd also recommend to exclude the impostors because they probably do not represent the scene as well as the actual geometry.

Concluding that for now you will have to implement that yourself but I already got this on my todo list to make this easier and an official API.

I hope this information helps. Let me know if you got any other questions or need assistance. Always happy to help and also very open minded for making changes to the asset (for instance making the Renderer array a List if the performance difference is negligible sounds like a good idea).

 

This sounds really good. Unfortunately we are migrating our project at the moment so I have no time to dive in it for now, but hopefully I will a bit later this year.

The index of the renderer is something we could probably serialize ourselves so we can insert it in the array at the correct index. So, very excited to try it out. Very hopeful this should do the trick for our project.

What makes you say checking for null is expensive though? It's one of the cheaper checks there is. Are you maybe confusing it with type checking?

For example, here is a test null checking 1.000.000 objects. So when the max is 65535 it should have an impact close to 0.

 

The plot twist here is that Renderer inherits UnityEngine.Object and UnityEngine.Object overrides the == operator to perform additional checks. Here is an older blog post that goes into some more detail: https://blog.unity.com/technology/custom-operator-should-we-keep-it

So you are right that null checks are not really a concern when it comes to pure C# objects but they are a concern when UnityEngine.Object is involved.

EDIT: Checking for null 65535 times for UnityEngine.Object took ~3 ms on a high-end system (in the Editor though). However it shows that there definitely is a cost to it that I don't want to introduce to the asset.

 

Yes, I stand corrected. For some reason I forgot about the overridden equals check.


So no, you should not do this in a loop if it can be avoided.

 

Just a quick note that a new version was approved. Here is the changelog:

This update also adds the first iteration of multi-scene support. If you open multiple scenes and use the "Bake all" option in the Perfect Culling menu it should automatically trigger a multi-scene build. There is also an API call for this. Talking about the API it was centralized into it's own static class to make it easier to see what is available and supposed to be public facing.

 

I made kind of MapEditorScene for desiner.
And they made multiple map prefabs(like map-1.prefab, map-2.prefab.. etc).

In Unity sytem, occulusion data is dependent on scene.
The problem is It require scenes as many as maps prefab.

But, I want to handle the map Prepabs with occulusion data on one PlayScene, like loading prefab with occulusion data and unloading and switching.

I wonder this asset can support what i want.

Thank you.

 

This should be very possible because the occlusion data is just a reference on the PerfectCullingVolume. So each of your prefabs would have a PerfectCullingVolume that references its own occlusion data.

 

Quick question.

I have a map with hundreds of objects.
Do I just import Perfect Culling and bake, or do I need to be adding scripts to every object to mark it as occluder, occluding, etc?
Just want to know (although simple), how time-consuming it is to setup a scene for baking?

Thanks,
Bruno

 

Generally the setup process should be very simple and fast and you don't need to add scripts to every object and you also don't need to tag them as occluder or occludee.
I attached the Quick Start Guide that comes with the asset. It shows how to get a scene up and running and should give a good overview.

Here are also two video tutorials to see it in action (one of them is a bit older and outdated though):

I hope this information helps you to get a better understanding how the setup process works. Feel free to ask more question though!

 

I got it, and in my first tests it works very well

 

Awesome. Thanks for giving it a chance. Really appreciate. If you need help or got ideas for improvement or any other feedback really just let me know. I'm happy to help.

 

I'm looking at this asset for our Quest game, and I have a few questions. Our scene setup is a bit odd -- do you think Perfect Occlusion would support this?

1. We have two scenes loaded at any time. One never changes, and one that is swapped out. (Think like a car mechanic swapping out the car in the center of the workshop).

2. We run a custom mesh batching pass during IProcessScene. This pass takes existing MeshRenderers and manually merges their meshes into new MeshRenderers. This happens just before entering play mode, or while making the build.

Is it possible to redirect the baked occlusion data so that it applies to these new mesh renderers, instead of the ones used during baking? The meshes themselves don't move at all. Or failing that, is it possible to run a bake synchronously, such that we could run it before entering play mode, or during a standalone build?

 

1. I'm not exactly sure what the implications of that are because I don't know how you plan to use culling in this situation. However you can bake the occlusion for each scene invidiually and it would be fine but occlusion would be independent from the other scene.

2. Each PerfectCullingVolume stores an array of PerfectCullingBakeGroup and each PerfectCullingBakeGroup stores an array of Renderers. You could just replace the reference to the old renderer with a reference to the merged renderer.

However depending on your scene complexity you might be wasting memory this way because you suddenly store redundant data because it all is pointing to the same renderer. If you know in advance how meshes are supposed to be merged you could make use of the PerfectCullingSceneGroup and that already merges renderers into the same group for the baking process.

Depending on your scene complexity and bake fidelity that might not even be necessary and not result in any significant gains. Furthermore if your scene is not too complex and you can get away with a low amount of baked cells you could make it part of your build process as well.

Doing it every time before you enter play mode sounds pretty annoying for the programming team though and I would not recommend unless you could cache the result so you only do that on change.

So yeah I think you got a couple of options here. I think the cleanest, easiest to debug and most efficient solution is to just perform your mesh merge step, bake occlusion and save it as a new scene and new bake data asset. Maybe add a game option to load the cached scene or the source scene.

I hope this helps.

Edit: The bake is always asynchronously because it would lock up the entire Editor otherwise. However there is callbacks that fire when the bake is finished, etc.

I also added some relevant documentation.

 

Thanks! That does help. Sounds like we could make it work.

Last question, does it naturally support LODs? We use LOD aggregate meshes (ie. Hierarchical LODing) fairly aggressively to reduce drawcalls.

 

It should work just fine. Basically all meshes that are part of the LOD are turned into a single group and enabled/disabled together. This makes sure that the LODGroup is back in control when any of the meshes inside the LOGGroup are visible.

Now during the baking process only LOD0 is used and in theory there is a chance that you'd see some artifacts if a mesh changes significantly in the other LOD levels. In practice I have never seen this cause any issues because you'd usually want to apply one iteration of neighbour cell merging and that automatically compensates for such a behaviour as well.

So yeah I think you should be fine.

 

Hi，
I have a big city with 200k object inside, and it take a big CPU cost at SceneCullingDynamicObject. If I using Unity Occlusion Culling, this will fixed, but Unity Occlusion Culling have a lot problem when loading scene.
So I try Perfect Culling system, I Think this system is working, but this dont resolve my probem of CPU cost at SceneCullingDynamicObject.
I dont see the renderer is disable when culled, is there any suggestion？

 

Hello developer,

My project is built in a server, so I upload the project using github to a server where that machine creates the build.

Do we need to install this asset in that machine in order to work when the project is built, or it only needs to be in the project when I bake the occlusion culling?

Regards,
Carlos

 

Is the renderer still visible in the Scene View?

Also try the following: Open PerfectCullingConstants.cs and replace the line:

Code (CSharp):

1. public const PerfectCullingRenderToggleMode ToggleRenderMode = PerfectCullingRenderToggleMode.ToggleShadowcastMode;

with

Code (CSharp):

1. public const PerfectCullingRenderToggleMode ToggleRenderMode = PerfectCullingRenderToggleMode.ToggleForceRenderingOff;

Maybe this setting works better in your use-case. Its only available in Unity 2019 and newer though!

Are all 200k objects inside your city static and have been included in the bake?
Did you clear the Unity Occlusion Culling bake?
What does your PerfectCullingVolume setup look like?
Do you have multiple cameras in the scene?

There also is a Troubleshooting documentation in the Docs folder. It should provide additional information how to debug culling issues.

 

You can bake your project and commit the locally baked occlusion data to your repository. No need to bake it on the server but of course the Perfect Culling project needs to be part of your project (like any asset you want to use).

If your server features a GPU you could however also bake occlusion on the server as part of your build process. However baking only when needed is better for iteration times so I'd recommend to just bake locally and commit the baking results.

Edit: I also tried to answer your mail but I received a mailbox not available when I tried to reply so you might want to stick to the Unity forum until you looked into your mail issues.

 

Hello PatrickKA,

Thank you for your response. I appreciate it very much!

Regards,
Carlos

 

Hi,
in your 1.1.2 message on this thread:

but I see no further mentions of multi-scene support in newer release notes,
does that mean we can start using Perfect Culling with a multi-scene project and it's fully supported ?

Or do you advice us to wait a little longer for next iterations to come ?

 

Hey,

Are you refering to multi-scene support as a single level made out of multiple scenes or being able to use the asset in multiple independent scenes? I noticed that this might be a bit ambiguous because the latter (multiple independent scenes) was always fully supported.

The multi-scene setup that means constructing a single level utilizing multiple scenes should also work at this point. However not all projects need that and thats why I have not gotten as much feedback on it but it seems to work just fine for the people that are currently using it. And if anybody got feedback on how to improve this feature even further I'd be more than happy to look into this.

Current workflow looks like this:
- Manually set up individual scenes
- Load all scenes simultaneously
- Select the menu option Perfect Culling/Bake All

 

Yes, our main scene setup is several scenes streamed asynchronously as on an openworld map,
and we need full support of a culling system on it.
What bothers us is the constraint to load all scenes to do a baking process,
and not being able to bake a bunch of scenes isolately.
(We never work with the whole world loaded)

 

You can also bake scenes in isolation but the culling would happen in isolation as well. The main advantage of the multi-scene workflow is that it allows an object from Scene A to occlude an object in Scene B. This will never happen if you bake them in isolation. However to make this work you'd also need to make sure that your PerfectCullingVolume is larger than the scene itself so it can bake the surrounding area as well. Of course, this increases bake time and bake size though.

 

Thank you for those precisions.
I will definitely give it a try now, and see how it can fit in our workflow, but that sounds promising !

 

Can this solution be used to check if a moving object is currently occluded?

 

Fully dynamic objects are not currently supported. I'm still doing some investigation on this matter but haven't found a satisfying solution yet.

 

Hi! I found no limitation regarding VR in the description, yet - will it work with VR multiview and singleinstanced?

 

Hi PatrickKa， another question
Can refelction probe using this culling system?
How to manage to do it?

 

It will work for VR no matter whether you use Multiview, Single Pass Instanced, Multipass, etc. They are all fully supported without limitations.

Hey,

Could you further describe what you are trying to do? Do you want to cull Reflection Probes?