Graphics GPU Occlusion Culling without baking and raycasting

Deprecated.

Spoiler

GDOC is a dynamic GPU occlusion culling solution that increases FPS by hiding objects that are not visible by the camera, drastically reducing draw calls.

Compared to the built-in occlusion culling, GDOC works at runtime and doesn't need baking.

Features
— No baking, works with procedurally generated or streamed scenes
— No raycasting, doesn’t need colliders
— Supports dynamic occluders and occludees
— Most of the work is done on GPU
— Culls shadow casters for 1 directional light
— Supports LWRP
— Supports VR multi pass & single pass (non-instanced)

Testing scene: Viking Village City
Made from assets from the Viking Village demo:



MeshRenderers: 111k
MeshFilter triangles: 670kk
Particle systems: 18k
Point lights: 6k (no shadows)

The scene is generated at runtime, nothing is baked.
All meshes cast realtime shadows from 1 directional light that moves around the scene.

Comparison in editor:



It's not really fair because scene view kills the performance.
Check out the video to see how it works in builds.

Requirements
Supported platforms: DX11 on Windows x64
Not supported yet: Vulkan, HDRP, Linux/Mac, consoles
Won’t be supported: OpenGL, Metal, mobile devices

Best practices
To achieve the best results with GDOC, make sure:
1. Scenes are big and have many objects that can be potentially occluded (like in the demo scene)
2. Objects exist in the scene hierarchy as MeshRenderers or other supported components
3. You have a Directional Light with realtime shadows
4. The number of draw calls is high and seems to be the main bottleneck

You can PM me in case you're not sure if it will work well for your game

Purchase GDOC on the Asset Store: http://u3d.as/1rYU

Download demo build:
https://drive.google.com/file/d/1BIoSZBDR1B0B5TJJTRxal7uptgWFNuCp

Join Discord
https://discord.gg/hMUTyfZ

 

tip: you should compare it with Unity defaut oc.

 

Built-in OC doesn't cull shadow casters, so if you have sun with realtime shadows, it's not a competitor
Check out this screenshot:

It culls things fine for regular rendering, but does nothing for the shadow pass
And it leads to 1500+ extra drawcalls that contribute nothing to the final picture

Same situation but with gDOC (to be named... ):

And you see that all shadows that can't be seen by the camera are disabled 8)

 

Very interesting, hope to see your OC soon on the store!

 

First post updated with a new demo scene — it has more than 100000 mesh renderers with realtime shadows

 

Oh boy have I got a scene to test this out on for YOU.
I'm working on a huge scene for a real world city building project with millions of tris visible almost every frame and full of geometry not optimized for an interactive Unity environment. Our standard baked occlusion culling isn't really doing the best job, we think, so I'm always on the lookout for new solutions.

I'd love to test this ASAP!

 

@drcrck does this support Multiplayer/multi cams/display?

 

I'm afraid it can't optimize your scene for you. If baked OC doesn't improve performance, this one can't as well. Can you show some screenshots of your scenes?

No, it currently supports only 1 non-vr camera. More features will be added later.

 

Hi,

Great work!
Is it compatible with something like vegetation studio which already uses gpu ?

 

Looks interesting!

I have a game where the whole world is made of dynamic chunks, which are itself set together to one mesh from voxels, some just cubes others meshes.

I can either set each chunk to be static, or turn that off and have all materials gpu instanced, both works fine.

I have a Problem with the Performance (each chunk is 10x10x10 blocks) when viewing distance gets higher, could this help in my case, too?

I would really like to give it a try if you are unsure and give you Feedback

 

No, but I need it too, so I'll add it later

You can easily test this manually: disable chunks which are inside the camera frustum, but occluded by other objects (i.e. can't be seen by the camera). Are there such chunks? Does disabling improve performance?

 

I once tried this myself, but I do not know if I did it right.
I realized no big change if I do this or not:

Code (CSharp):

1.     private void CheckChunksVisible()
2.     {
3.         //https://forum.unity.com/threads/check-if-object-is-visible-to-main-camera.462777/
4.         //https://answers.unity.com/questions/8003/how-can-i-know-if-a-gameobject-is-seen-by-a-partic.html
5.  
6.         Plane[] planes = GeometryUtility.CalculateFrustumPlanes(Camera.main);
7.         foreach (var chunk in ChunkManager.Chunks)
8.         {
9.             //if (chunk.Value != null && chunk.Value.FlaggedToUpdate || chunk.Value.FlaggedToRemove) {
10.             chunk.Value.GetComponent<Renderer>().enabled = GeometryUtility.TestPlanesAABB(planes, chunk.Value.GetComponent<Mesh>().bounds); // oder chunk.ChunkCollider oder chunk.GetComponent<MeshCollider>
11.         }
12.     }
13.  

In the player's update method:

Code (CSharp):

1.             Vector3 screenPoint = Camera.main.WorldToViewportPoint(targetPoint.position);
2.             if (screenPoint.z > 0 && screenPoint.x > 0 && screenPoint.x < 1 && screenPoint.y > 0 && screenPoint.y < 1)
3.             {
4.                 currentGazeTimeInSeconds += Time.deltaTime;
5.                 if (currentGazeTimeInSeconds >= holdGazeTimeInSeconds)
6.                 {
7.                     currentGazeTimeInSeconds = 0;
8.                     CheckChunksVisible(); // todo Thread? StartCoroutine?
9.                 }
10.             }
11.             else
12.             {
13.                 currentGazeTimeInSeconds = 0;
14.             }
15.  

I could do this with StartCoroutine. I just don't know if the method CheckChunksVisibleis useful this way. Or if there is a better way. Maybe also hide chunks that are behind other chunks etc.

I thought your asset is doing this on the GPU?

Thanks!

 

No, what you're doing is regular frustum culling, it's already done by Unity. Doing it twice can't increase FPS

What I mean is to select 1 camera position and compare FPS with all chunks enabled and some chunks manually disabled in the hierarchy. Not the ones which are outside camera frustum, but the ones which are inside, but can't be seen. Example: https://i.imgur.com/N0Zmdbb.png

That's exactly what OC does

Yeah but the outcome is disabled chunks. And you can do it yourself to approximate the potential effect of OC.

 

If I disable my some of my chunks it get's more performant, yes

I believe when walking on the surface, a big problem is chunks that are under the "surface ground chunks" which I cannot see anyway but I guess they are all rendered…

Does your asset help with These? Then I guess my performance should be a lot better (for GPU, the other stuff is already good)…

Does your asset work with transparent parts also? In my case like a Ground chunk under a water chunk? Or a large Building but with big windows on all sides?

I would really like to test and give you feedback and when it is helping and not too expensive I will gladly buy it.

Thanks

 

Then it will help. Especially if you have realtime shadows from the sun, so invisible underground chunks are also rendered into the shadowmap.

It shouldn't be an issue

 

Yes I have these! I am using "Enviro" and also additional torch (point) lights etc.

 

Free demo is available!
Requirements: Windows x64, DX11, Unity 2017+
PM me if you'd like to check it out

 

The demo was updated and now supports ILL2CPP

 

I’d love to check out the demo. I’ll send you a PM

 

By default, it consumes 0.050 ms per frame to scan currently active scenes to detect new objects and process them according to the layer rules you mentioned and other settings.

Also it spends another 0.050 ms to validate active occludees and remove them from the GPU buffers when their gameobjects are removed from the scene.

You can change the time limits or completely disable the first feature if it doesn't fit your game (there are other ways to manage objects).

The real time consumer is dynamic occludees because their transforms must be checked every frame and all changes must be sent to GPU. It's expensive and most likely it's faster to simply draw them, especially for instanced objects. More details in documentation (soon™).

Other than these 3 things, nothing important is done on CPU.

 

My game is currently CPU bound so that is the biggest concern for my game. That's very little CPU time, so that's great.

Have you done any tests to see how much of a savings there are for not rendering vs running the occlusion code on the GPU?

Also, keep up the great work....I think it could really help a lot of developers

 

It helps in this case too, since Unity doesn't need to process disabled objects (do frustum culling, sorting, building command buffers and so on) and it saves some CPU time (mostly on the rendering thread)

"not rendering" means an empty scene? I'm not sure I understand what exactly you want me to test

 

Sorry, I meant rendering calculations to determine if a renderer should be enabled or not vs just rendering it.

A bad question since it depends on what. The renderer is rendering, amount of materials, light pass, etc

I noticed that some of my renderers where being occluded when they should not be, the seamed to be smaller items. I could seem to get them to stay visible without turning off and on.

 

"just rendering" might be faster if the percent of occluded objects is very low (for example, you're looking at forest trees from above — all trees are visible, OC does nothing)

It's either Visibility Threshold (it's like global LOD for all objects, decrease the value if you don't see some small distant objects when you should) or simply a bug of the version you used

 

Yea, I have it reduced it to zero already to might be a bug.

Curious, how are you handling cutout shaders, like a chain link fence?

Also, when do you plan on releasing it to the asset store?

 

First post updated with a new demo scene! This time it has 100000+ mesh renderers, 18000+ particle systems, 6000+ point lights and 1 directional light with realtime shadows.

PM me if you want to test it in your project!

 

Comparison with the built-in OC

This scene is smaller, but the camera is above the roofs so it's actually harder to render, even after OC.

Note:
1. LODs are not used. With LODs, the performance will be better in all cases and the difference will be less drastic.
2. FPS is as it's shown in Stats, and timings are from RenderDoc, so they might not match.

No OC (4.2 FPS):

GBuffer: 48 ms
Lighting: 20 ms (point lights from torches + shadow map from the moon)
Particles: 32 ms




Built-in OC (6.4 FPS):

GBuffer: 37 ms
Lighting: 20 ms
Particles: 23 ms

I think it might be better with non-default baking settings but it would take too much time to try it.



GDOC (63.5 FPS):

GBuffer: 17 ms
Lighting: 5 ms
Particles: 1 ms

 

Hey, out of curiosity would using this package raise minimum system requirements and / or require a certain amount of GPU? It seems really cool (tried out the demo), but I'm wondering if it would behave differently on someone who had a 1 GB or 2 GB GPU from a few years ago as opposed to my 1080TI

We have a lot of players who play on laptops and I want to make sure that adding this won't make our game unplayable for them

EDIT: Also we stream assets in and out as the player moves through the world, will that cause any issues with this camera component still having references to deleted objects? We use prefabs not scenes for our streaming system

 

The last video was recorded on GTX 960 2GB
Also I tested it on Intel HD Graphics 530 and it worked, giving significant fps boost (numbers were like 1 fps vs 40 fps, this scene without LODs is definitely too hard for an intel gpu, even with OC)

It automatically deletes removed objects and processes newly created (if background scan is enabled)

 

Okay that's awesome to hear - one more question, will this work alongside software like GPU Instancer? https://assetstore.unity.com/packages/tools/utilities/gpu-instancer-117566

 

It works with anything that exists in the scene hierarchy as GameObjects

 

How are you handling meshes that use cutout shaders? Can those be excluded?

 

They don't require any special handling, it just works — all shaders end up in the same depth buffer and once it's rendered, you can't tell was it a cutout shader or a complex mesh.

 

I guess I should have been more specific.

Is there any fine grained control over which meshes can be occluders? I know you are using layers, but there are some gameObjects that require special handling and need to be the same layer because of lighting.

For example:
A chainlink fence shouldn't be able to hide any objects behind it since its mostly gaps and you would be able to see occlusion at work.

 

No, it's not possible in this method — the whole depth buffer is the occluder, and cutout chainlink or mesh chainlink look the same there, regardless of their shaders

They don't survive depth downsampling so it's not an issue





But it's not a special handling of cutout shaders, it would work the same way if it was a complex mesh

--
Brand new GDOC Discord: https://discord.gg/hMUTyfZ

 

Awesome!

 

Hi, how do you make objects not render? Changing .enable of renderers? And does this have delay from GPU to CPU or everything is done in one frame? Really cool plugin, at last modern occlusion culling in Unity.

 

Yes, changing enable and shadowCastingMode

It does, so I'm using some techniques to make the delay acceptable in most cases.

There are only 2 ways to eliminate the GPU→CPU delay:
1) Wait for GPU to readback the results (not an option actually due to extreme performance impact).
2) Draw everything indirectly. It requires very deep integration into the engine, especially for lights and other objects that are not mesh renderers. Good option but not possible for an asset.

 

Does it work with LOD Group?

Additionally, we sometimes use a lower LOD to render the shadow, using such MeshRenderer/LODGroup setup:

• Render mesh of LOD0 using mesh_lod0.fbx (MeshRenderer.castShadows=Off)
  
• Render shadow of LOD0 using mesh_lod1.fbx (MeshRenderer.castShadows=shadowsOnly)

 

Yes, it was implemented in the latest version, now it correctly works with this setup

New demo is available in GDOC Discord: https://discord.gg/GhKTEXy

 

I was on #General, didn't look at #News.

I ran around a lot. After a longer while again I had a hole in the landscape. I pressed F1, and it was gone. Again I pressed F1 and gDoc was working again, no hole. Happened only one time.

No crash yet...

 

What are the chances of getting something like this to run on mac/linux builds?

 

It will be added in future releases, but no ETA yet.

 

New demo is available!
https://discord.gg/GhKTEXy

 

Hi,
I tested the demo package on my large outdoor map with 1km x 1km but it doesn't seem to make much difference.
I'm using Vegetation Studio Pro for trees and foliages though.

Is it supposed to work well in outdoor terrain scene? Yeah, it's not flat terrain so visiblity is somewhat limited.

Thanks.

 

Hi,
Currently it works only with objects that exist in the scene hierarchy (but not Terrain as there's no API to work with its chunks)
Vegetation Studio integration will be added in future versions

 

I see. I'll try to test once again when VSP support is in. Thanks.

 

GDOC is now available on the Asset Store!
http://u3d.as/1rYU

This is the very first release so expect some bugs
Please report them in #bug-reports on Discord: https://discord.gg/hMUTyfZ
Or in this thread

To achieve the best results with the current version, make sure:

1. Scenes are big and have many objects that can be potentially occluded (like in the demo scene)
2. Objects exist in the scene hierarchy as MeshRenderers or other supported components
3. You have a Directional Light with realtime shadows
4. The number of drawcalls is the main bottleneck

You can PM me in case you're not sure if it will work well for your game

 

Hi,
Will it be possible to use multiple cameras in a later update?

 

Yeah it might be added in future versions