Graphics [RELEASED] Perfect Culling - Pixel Perfect Occlusion Culling

Okay I see, that's what I was assuming the prefab baking was for. Well the workaround sounds reasonable since I use a bounding volume to randomly place objects in I could probably just use that for the bake. Thanks for the info!

 

Seems I did something wrong..
Either the bake was failing and stopping or some change..
The other times I was trying after 2-3 minutes it was done, this is now saying bake time is 17hours!

Well this is odd...in my main scene it is larger, I created 2 volumes. only using 1 volume I selected 1 asset (the HQ abandoned hospital) and it baked, great...so I added another building and it failed with the GPU error again.
I open a new scene, put the hospital in, bakes fine. Add the prefab building, bakes fine. So new scene worked original scene fails. but only those 2 prefabs added to the bake volume group list

What I did notice was in the new scene I get the nice colors as it is baking, in the main scene it just turns pink.

 

If it says that the bake is gonna take 17 hours you probably reduced the cell size?

Anyway if you have any way to reproduce the GPU error maybe you can package it up and send it to me and I will be able to look into it in-depth because right now everything is a shot in the dark.

EDIT: You could also go to the Perfect Culling settings and uncheck the Use Unity for Rendering checkbox and see what that does.

 

Think I found it, the terrain. I have your excluder script like you said to add in the video. I turned off everything in the main scene except the hospital, worked perfect. turned on terrain and bam...error.
The issue is probably the offset. my terrain at that spot is -9....I set the offset to -9 as well but guessing that was the wrong thing since it still errored...I remove that script it still errors, it onyl works if I remove the terrain from the scene....

 

Could you turn this into a small project and send it to me via mail or just describe here again what I need to do to reproduce it myself? I will look into a fix then. Thank you for looking into this some more. Glad you found the root cause!

 

Working on it...I think I got it all stripped out to just the hospital (exterior only) and terrain. Email or PM you with a download link once I have it ready and tested in a fresh project to make sure it acts up

(Emailed it over)

 

OK but basically what will happend if We use additive scenes but in the same area, Lets assume we have 10x10 meter map, and then we we load there some additive scenes in additive way, so Basically There is Main scene , scene A and scene B. We always have loaded Main scene, but loading Scene A or scene B, the problem with Umbra is, that If scene A have building in the same place when Scene B, and we have to load all scenes at the same time to bake, so there is like bridge in scene A at that place, and House in Scene B, it will just add these 2 ocludders, and no matter if only one of that scene is loaded it use baked oclussion with both of these building loaded, what makes problems. So basically Umbra works only correct if additive scene objects dont overalap each other, (Scene divided into areas) but they didnt though at all about situation when someone use aditive scenes to load part of elements on the same area.
Are You system handle sucha situation?

And second question, is that if We have to load all scenes together to bake, then there is probably the same problem like in ubra - massive usage of RAM if You have huge world.

Waiting for reply especially for my first question

 

Just wanted to update this post if anyone else has a similar issue.
MY GPU duplicate issue (not saying yours is the same) was caused due to my terrain being on the same layer as his camera used in baking.
Change this line:
PerfectCullingConstants.cs and find the line that reads (probably line 39):
public const int CamBakeLayer = 30;

And change it to an empty layer.
I was able to bake after this.
Again, this was my fix, your issue might be different.

 

A hot fix was reviewed and released round about an hour ago and this workaround should not be necessary anymore as of version 1.1.8. Sorry for the inconvenience.

 

If you bake all scenes independently they will function independently and Scene A would never cull Scene B, etc. But maybe that is not sufficient for performance reasons.

However a PerfectCullingVolume also holds an array called Additional Occluders. This array is only used in the Unity Editor and you can add occluders that are baked in. Maybe you can make use of that?

Loading all scenes isn't ideal but it is the only way to properly take into account occluders from other scenes. Maybe you could instead hand-craft some cubes to work as occluders? Then you would only need to load a bunch of cubes and you can put them into the Additional Occluders array to bake that data in.

I think there are a couple of options here and if you are willing to experiment and adjust your workflow or maybe create additional tooling it should be very possible to make it work.

 

Ok I sent 20k bake groups to native renderer, bake starts and after some time GPU stops activity (from task manager view), Unity still read data from pipe (eg sampling batches etc) but then pipe stream reader tries to read next count it throws an EndOfStreamException: Unable to read beyound the end of stream. Changing buffer sizes of the pipe server doesnt help. The number of sampling points passing to native renderer is same as in Unity PerformBake method.

I assume that native renderer client crashes and closes pipe but I have no source for native renderer dll to fix myself.

Help please)

 

Find the Perfect Culling Settings and check Use Unity for Rendering. This will not use the native renderer anymore but everything happens in Unity and you have full source code access. For this reason I also plan to eventually remove the native renderer because it is way too rigid and Unity bake performance increased in later Unity versions. But I haven't made a final decision on that.

If you really need the native renderer I could also send the source for that one but it is all C++.

 

I know anout that switch but unity rendering is not an option for such large number of objects due to unity version restriction on the project (2019 is slow), bake time is somewhat that doesnt reduce at all yet native bakes like a rocket. Any chance to get native render source in case you drop its support (without sharing it ofcourse, just to fix that exception)?

 

I sent you a PM. If there is enough interest in the native renderer (even though it is rather rigid and not as customizable) I also might rewrite it from scratch using Vulkan this time. I just thought it is too rigid and not worth the effort but maybe I'm very wrong and it is sufficiently useful to make it worth to put in this work.

 

it works faster for complex scenes and do its job perfectly, anyway thanks again for help

 

So basically Your system supports Dynamic Occludders?

 

Well, this still happens at bake-time so it is still pretty static. So maybe better to just say that it gives you more control.

 

Ok t hanks for clarification

 

Will this work with Unitys Addressable system, When we switch scenes are loaded into the main scene and unload the scene ( enviroment ) with addressable and additively and load a new scene. is the occlusion data stored on the scene file. Unity sugggests loading all scenes in and baking with the old occlusion culling. How does this plugin differ.

 

Occlusion data is stored as an asset that is referenced in the scene. For culling across multiple scenes you would also load all scenes and select Perfect Culling -> Bake All. Each scene would have its own PerfectCullingVolume and its own occlusion data. This step simply makes sure that renderers from other scenes are taken into account by injecting them as additional occluders to allow culling across scenes.

So I'd say the general workflow is very similiar but you can of course just look at the source code and customize and extend it for your project.

 

tried this on a complex model (+40k meshes), good performance but some popping..

now testing few different bake settings,
currently cell size is already 1x1x1 (and cannot make it smaller)
camera has neighbor cells: "2" enabled..

also, do you have ideas/plans to check if baking speeds can be improved?
maybe could use GPU for some parts?

 

Hey,

First of all I'd recommend not to use the Include Neighbor Radius option on the camera because:
a) It is evaluated at run-time and requires additional lookups
b) It does not take all neighbours into account to not hurt performance too much

It is mostly meant as a quick and responsive debugging tool to check how merging more cells could change the culling results.

So set it to 0 and instead look at your PerfectCullingVolume and set the Merge-Downsample iteration slider to 2 instead. This calculates it at bake time and also makes sure to evaluate all neighbor cells. Maybe that alone already helps to reduce your popping issue. Requires a bake again to see the effect though.

The best way to increase the bake speed is to reduce the number of cells you need to bake. If you are not excluding cells yet you might want to do that. There is some documentation about built-in sampling providers.

If you are on Windows you could also go to the Perfect Culling Settings and uncheck "Use Unity for rendering". This will use the native renderer instead and some people reported it works much faster for them.

The baking process is already happening on the GPU for the most part, I'm afraid. That also means a more powerful rig could most likely make quite a difference here.

Anyway I hope this helps a bit. Let me know how it goes!

 

Ok great will check those - got very good results already by increasing the bounds, which did then increase the bake time.. but its not too big issue since this is static scene and wont change much. (i do have +44k cells now..)

I guess the issue was: camera went outside bounds, so it snapped into closest cell,
which then caused popping in wrong places..

current test scene performance went from ~4fps (without your plugin) into +80fps in editor.

 

@PatrickKa Congratulations! This is a great asset. Can you tell me if it is ok to have the Perfect Culling Camera component on the camera even when no baking volume is present in a scene. It seems to work fine and I don't see any error but i was wondering it there is a drawback to having this script by default on my camera .This would simplify my workflow. Also can you tell me if you have a Discord channel? Thanks for your help!

 

Hi!

Can't figure out why the cells don't completely cover the volume?

 

Thank you! This should be completely fine. It loops over all volumes but if you have none it will exit early. I don't have a Discord channel.

The cells most likely cover the entire volume but for performance reasons I only show gizmos for cells close to the scene camera. Did you try to move your scene camera around a bit? If you still don't get to see them please let me know your Perfect Culling Volume configuration and I can check this specific setup.

EDIT: Whoops your settings are in the screenshot, sorry.

 

Version 1.1.9 was approved and is available now. I usually do not mention this here but this one is more special because the changelog also reads:

Code (CSharp):

1. ADDED: Native Vulkan Renderer (Experimental; Windows only at the moment)

You need to enable this new Renderer in the Perfect Culling Settings (see screenshot). This feature might be hit or miss (thats why it is experimental) because I have only been able to test it on a very limited number of hardware and Vulkan is not very forgiving. So please keep that in mind. However if it works for you it should be faster than the other renderer.

I hope many of you are able to give it a go and report back with the results. I do not want to state any performance numbers because it greatly depends on your scene but it should be good step forward. Part of it due to Vulkan and part of it just due to different design decisions.

 

i'm building a game with many rooms in a building and i'm using a scene for each room, you are free to go around the building and scenes get loaded/unloaded as you move around. do i need to bake everything at once? because that'd be very straining on the machine. I'd rather bake it one scene at a time. since almost every scene is a room in an enclosed space with walls i dont actually care about occulusion data take consideration from renderers in other scenes. Does the asset support this workflow?(bake one scene at a time and scenes can get loaded/unloaded asynchronously as the player travels in the world)

 

You can have a scene per room and just bake them in isolation (each scene features its very own PerfectCullingVolume and references its own occlusion data).

The real question is whether a single room allows for enough occlusion opportunities? Because baking them in isolation also means that you need good occluders in the room itself.

 

hope so! when i say "room" i more mean apartments where each scene contains multiple rooms separated by hallways and walls.

i'm going to get the asset to see if it is any better workflow wise than the built-in one!

 

Hi Patrick,

I bought your asset after I saw that it supported VR and multi-scene workflows. But after trying it and reading through all the documentation, I'm worried it won't work for my game.

My play area is very large. A 2km x 2.5km modern city, and the player can fly vertically as well. For performance, the city is broken up into about 300 scenes and loaded/unloaded additively. I thought that I could load all of them at once, create one large volume, and then bake, similar to how I do it for Umbra, but apparently that isn't the case. Do I have to add a volume for every scene, and then add their renderers one by one? Is it even feasible to bake them all together?

 

Technically you could add a PerfectCullingVolume to each individual scene (and have it reference its own occlusion data and the renderers in this scene). Now you would load all 300 scenes and use the Perfect Culling Bake All menu option. This automatically takes the other volumes into account and turns them into occluders that are baked in as well. Practically I'm not sure how this would impact the bake time though because you'd bake about 300 times. Sounds like you might want to try the experimental Vulkan Renderer (assuming you can bake on Windows)!

Of course, you could create a single volume and bake all of them together but the problem is that the reference to the renderers are unstable because you'd load/unload them? This is pretty much the main problem. If you could keep the renderers in your scene and only load the textures and meshes, etc. that could maybe work though.

If you cannot make it work at all reach out to me via PM.

 

Hi Patrick. played around with the assets for a few days. setup was pretty easy and the tutorial is straight forward. kudos.

In our scenes, we use a lot of small real time/mixed lights, which we believe if occlusion culled can help our performance. I noticed that perfect culling doesn't deal with that by default, however there's a small document that mentions that I can associate lights to a renderer and it'll get disabled if the light is occluded.

I'm not sure how to come up with a good workflow for this.
my current thinking is to generate an invisible renderer, whose sizes cover the influence volume of the light.
I haven't tried it yet, but during baking does it care about the shape of the renderer? or does the baker only care about the bounding box of the renderer?

better yet we'd love to see realtime light culling on the roadmap

 

Basically the idea was that you'd already perform culling for the room the light is located in. So you could just select any renderer in the room and use that as a hook to enable and disable your light. Concluding that you do not even need any additional renderers. There is a demo scene called Demo_UnityBehaviours that shows exactly that.

If that still doesn't cut it though then you probably need an additional renderer as hook. The shape of the renderer matters because all visibility checks are pixel perfect. For a point light a sphere (probably a low poly ico sphere) should work nicely. You do not want the sphere to occlude other objects so it needs to be transparent. Furthermore it should be double-sided. Otherwise the renderer and thus the light would be culled when you are within the radius of it. The PerfectCullingRendererTag component allows to force a renderer into transparency and also allows to force it to be double sided.

I agree that light culling would be a nice feature to have. Great idea.

 

started getting this error after swapped model, and cleared old bake groups: (when click the calculate eta button)

Code (CSharp):

1. EndLayoutGroup: BeginLayoutGroup must be called first.
2. UnityEngine.GUILayout:EndVertical ()
3. Koenigz.PerfectCulling.PerfectCullingVolumeEditor:BakeSetup (Koenigz.PerfectCulling.PerfectCullingVolume) (at Assets/Koenigz/Perfect Culling/Scripts/Editor/PerfectCullingVolumeEditor.cs:409)
4. Koenigz.PerfectCulling.PerfectCullingVolumeEditor:DrawUI (Koenigz.PerfectCulling.PerfectCullingVolume) (at Assets/Koenigz/Perfect Culling/Scripts/Editor/PerfectCullingVolumeEditor.cs:103)
5. Koenigz.PerfectCulling.PerfectCullingVolumeEditor:OnInspectorGUI () (at Assets/Koenigz/Perfect Culling/Scripts/Editor/PerfectCullingVolumeEditor.cs:89)
6. UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
7.  

 

Thank you for reporting this.

I actually had one more person report it but I'm not sure what is causing this because everything checks out in the code and I wasn't able to reproduce. It could also be caused by some Unity UI and just happens to propagate and fail in the Perfect Culling code.

Fortunately it is a harmless (but of course annoying) error that is just about the Editor UI being unhappy. Anyway I plan to change some code to see whether that fixes it but it is gonna be a shot in the dark.

EDIT: Nevermind I might see the problem. Fix will be in version 1.2.0. If you need it ahead of time let me know though.

 

Hey, I have a question a little like @Jakub_Machowski 's above, but different enough that I want to be sure about how I should approach this.

I'm working on a game with large exterior environments. I'm streaming my scenes asynchronously as the player moves through the world; this scene-streaming is portal-based, so I have design-time control over where and when the scene streaming takes place. At runtime, the game keeps the following loaded:

• manager scenes (no geo, doesn't matter for culling)
• terrain scenes (actual 'terrains' for nearby terrains, low-poly mesh impostors for distant terrains)
• the scene pertaining to the location that the player is currently in (containing props, geo, etc.)
  
• the scenes pertaining to 'neighboring' locations that the player can move to or see from their current location

So if the player can see/move to locations B, C, and D from A, all four (A, B, C, D) will be loaded when the player is in A. If the player moves to B and can no longer see D, D will be unloaded. (These associations are dictated by me at design-time, there's no runtime querying against 'visibility' volumes or anything like that.)

I want to bake occlusion for these scenes. I do want occlusion to handle cross-scene geo, so that my occlusion bake for scene A can cull geo in scenes B, C, and D. I do not want to have to load every scene and bake occlusion for all scenes simultaneously for the following reasons:

• My game is large; loading every scene at once would be brutal
• My game is large; being able to bake scenes individually as I go would be vastly better for iteration
• I don't need to cull geometry in scenes E, F, G, H, etc. from scene A, because I'm already not loading those scenes while the player is in scene A
• Multiple scenes occupy the same positions in space (e.g. if the player returns to scene A after stealing an amulet, scene A1 will be loaded instead)

It seems like the multi-scene setup described in the docs requires me to bake every scene simultaneously. Is there any way to circumvent this and only bake for a specific Perfect Culling Volume for a specific open scene?

 

Hey,

I perfectly understand your situation and I think the tooling needs to be improved to allow for more flexibility here. I made a note to look into that.

Generally the multi-scene bake is really just perfoming a couple of simple steps under the hood:
- Merge all loaded scenes into a temporary scene
- Collect all renderers in all scenes and add them as "Additional Occluders" to each Perfect Culling Volume
- Bake all Perfect Culling Volumes

Effectively this simply bakes in the occlusion but does not need any references to the renderers (the additional occluder array is only used during the bake step but not used at run-time at all).

Anyway this is already almost what you need except for the fact that you only want to bake one Perfect Culling Volume, of course.

So if you want to bake Scene A and you know that only Scene B, C and D need to be taken into account for occlusion you should be able to load Scene A, B, C, D. Remove the Perfect Culling Volume in Scene B, C and D. Use Bake All option. Make sure to select Don't save so you don't save the change where you removed the Perfect Culling Volume.

Obviously this is a bit clunky and where the current menu option just happens to be too unflexible and where I want to improve it so you don't need to do this manually. I imagine it would just show you a window that shows all scenes that it is about to bake and you can uncheck things.

Of course, you could also take a look at the code and the API documentation to implement your own bake step. This could allow to use the data you already configured to streamline this even further.

Really all you need to allow for culling across scenes to work is to populate the additional occluders array. You also need to make sure your Perfect Culling Volume is large enough (so it can contains the additional occluders). As a matter of fact you are not even required to use the actual scene renderers. You might as well create some cubes that approximate your occluders. All of this works and it depends on what is easier to maintain, etc.

I hope this gives you some ideas and allows you to move forward. Feel free to ask more questions if things are still unclear.

 

Hey, thanks for the detailed reply. That makes perfect sense, and is plenty to get me started on my own implementation.

Having a GUI for selecting volumes to bake (or enqueueing multiple bakes for different volumes) that handles that temporary destruction/cleanup does sound like it'd be a little more intuitive, but it looks like the API exposes everything I'd need to write my own tooling for that, so probably not a huge priority. Thanks, and I'll be sure to let you know if I run into any problems!

 

I've noticed that PerfectCulling doesn't do a great just of culling when you're inside of a wall, which makes sense given how it works. Ideally your player isn't inside walls in the first place, but being close to a wall can have the same affect. It occurred to me that if I set every object to double-sided that should help cull out some of things, by having the backside of the next wall occlude them. Would it be possible to add a tick box on the Culling Volume script to use Double-Sided on everything, so I dont need to put a double-sided tag on all of my objects?

 

Heya
I wanted to ask if perfect culling calculates shadow impact on objects too or not.
In my example, i can see that some part of interior are without shadows so i dont know if there is some step that im doing incorrectly or if perfect culling is not taking shadows into account at all.

Example:

Spoiler

 

What are you trying to use this for? Shadows dont relate to Occlusion Culling. This is for hiding objects that you can't see.

 

They should. You cannot cull object that is projecting shadow on place where you can see because it will result in incorrect lighting.

 

Oh i see. you're talking about factoring in realtime shadows in order to decide if an object should be culled or not. I'll wait to hear what Patrick has to say, but I can't image this system has a way to take that into account

 

Hey,

You are exactly right and I have plans to add an actual option for this but I haven't been able to do that just yet because it also needs to function correctly with the Native OpenGL Renderer. I have since created a Native Vulkan Renderer that could handle it but it is still being tested. If you are on Windows maybe give it a try as well. I posted about it in this thread on May 23th.

Anyway an easy to make everything double-sided is to simply go into PerfectCullingSceneColor.cs and remove/comment out lines 80-91. I added a screenshot.

You should be able to confirm the correct behaviour by entering Play Mode and selecting the Replace all materials in scene with bake color material option on your PerfectCullingVolume.

 

Many people use Perfect Culling on low-end hardware and use baked lightmaps that solve this problem nicely. Thats why Perfect Culling simply disables the entire renderer in its default state.
However if you cannot use lightmaps you can open PerfectCullingConstants.cs and find the line (probably line 44) that reads:

Code (CSharp):

1. public const PerfectCullingRenderToggleMode ToggleRenderMode = PerfectCullingRenderToggleMode.ToggleForceRenderingOff;

Try to replace it with:

Code (CSharp):

1. public const PerfectCullingRenderToggleMode ToggleRenderMode = PerfectCullingRenderToggleMode.ToggleShadowcastMode;

This effectively sets the Renderer to ShadowsOnly instead of disabling it completely and should fix your issue. Obviously this is more expensive but if you are not targeting low-end hardware might not be a problem.

Of course, I know that opening script files to make such changes isn't very user-friendly but it is located in a hot path and using constants is the most efficient way to do it. I might look into some code gen in the future to make this configurable from the UI as well though.

EDIT:
You could also manually author some proxy volumes to make sure objects are picked up as visible for longer. Here is what I wrote to somebody else in the past:

 

Great! I'll give that a try! Thanks.

One related issue I'm having: I have some LOD objects, and if I apply a Perfect Culling Renderer Tag to LOD0, or all LOD's, set to "Render Double Sided", my culling volume will always report that the "Hash Doesn't Match", until I remove the tags from all LOD's

 

Actually, an update on both things. I removed those lines from the script, and I end up getting that same error I would get before that there are invalid renderers. So it seems I get this if anything is trying to render double sided.

 

Can you try to Clear Bakegroups and add the renderers back in (basically performing the initial PerfectCullingVolume setup steps again)? Anyway I will investigate this, of course.

Alternatively if you are currently using Unity for baking you can find the material called PerfectCulling_UnlitTag and set Cull to None. This should also make it render double-sided but it does not need the script change. However this only works for the Unity baker.

 

Thanks I'll try the material modification.

I have definitely cleared my bakegroups, many times. We developed some scripts to automatically clear and repopulate the bakegroups. And everything works right so long as I dont have double-sided tag on certain objects. I've used it successfully on many objects too. But LODs in particularly, at least for me, seem to not be agreeing with it