Occlusion culling CPU spike in profiler

unity bugs department answered by email to my report today , they requested more information cause the project i sent is not causing spikes on their machine ;-(

 

Works

 

Captain's Log 08/07/2017, I am running a project in 5.3, we have not heard word from Unity Command. It appears many Starships, their crews and Captains have been lost due to this anomaly.

When we look across the plane in a diagonal manner we get a spike. I believe it's the real time sun light drawing on all objects as it travels across the sky. I tried LOD subsystems, but that did not alleviate the problem. Without Unity Command answering our distress calls, we will also be lost in the abyss of space.

I have but a couple of tricks up my sleeve, but this 21 years of making games Captain is all out of answers.

Captain of the USS Last Bastion. Out.

 

I'm afraid Unity won't put (much) more work into 5.3, which was originally released in 2015. The most recent 5.3 patch release is from February 2017, which is about 6 months ago.

You could check if an Unity update is feasible for your project and benefit from all those bug-fixes and new features that have been added to newer Unity releases.

Another option could be to buy Premium Support, where they might provide custom Unity builds.

 

I'm having this issue on Unity 2017.1. Going to try the various lighting fixes mentioned in the thread, but it does seem like a bug.

 

If you think you found a bug, I recommend to submit a bug-report following the advice given in this document. If UT don't have a bug-report to reproduce this issue, it's very unlikely that they're able (or perhaps even look into it) to fix that bug (from my experience).

 

I notice a lot of people have had issues in this thread, and I never saw a comprehensive answer for it. So here is my best explanation for the occlusion culling.

Occlusion culling is a pretty cpu intensive process. The idea is to invest cpu power in checking which objects don't have to be rendered, so that way the cpu does not have to send as many draw calls to the gpu.

So when the cpu is doing occlusion culling, cpu tries to do it as quick as possible.
The cpu desperately checks the largest closest occluders in the scene, hoping that it will occlude the rest of it's view. If the tests fail, it goes to the next one checking if this one will occlude the rest of the view. It continues this process until it doesn't fail. In the meantime it is saying "WaitingForJob." Once it is no longer waiting it goes, "okay my view is completely occluded, I'm not checking any more occludees." It then sends the Draw Call Train off to unload into the GPU.

For this reason, Occlusion Culling should not be used in outdoor scenes, or any scenes where there is some serious draw distance. The CPU will have a really hard time finding objects that occlude it's view in its entirety.

With indoor scenes, it is pretty easy to handle occlussion, because you can just mark all the walls as both occluders, and then everything that is supposed to be static can be marked as occludees. The cpu can then quickly check the closest occluders, recognize that the view is completely occluded beyond them, and then ignore anymore occludees.

With occlusion, it is important to be really particular with what to set as occluder static and occludee static.

Occluder's are things like walls that Occlude other objects. These are things like walls between rooms.

Occludees are objects that should be occluded, but do not occlude other objects. These are mainly things that are transparent, or small.

So it doesn't make sense to mark something like a dining room table as an occluder. It will hardly block any vision. However, it does make sense to mark a table as an occludee.

Lastly, whether an object should be occluded isn't strictly affected by whether it's visible, but rather if it is needed to render the view. So if object A is not visible, but casts a shadow onto object b, which is visible, object A still gets rendered because it still affects what the player sees.

Helpful Tip, if you are only using baked lighting on occluder and occludee objects shadow casting checks isn't really an issue. You can also turn off shadows for real time lights, or turn off cast shadows or receive shadows on the objects themselves.

I hope this helps.

 

Actually, great reading. Thank you for taking an effort explaining OC. So, the question appears: how would you do outdoor scene without OC?

 

Optimizing outdoor scenes takes a lot of work. There are a lot of trade offs for optimizing certain things over others.

Use lots of LOD groups.
They help a lot. They can cull objects if they are too far away and they don't have nearly as much overhead as occlusion culling. These only stop them from being rendered, so if you have any game logic on things, it will continue to run.

If there are things like towns, people, and animals, you should think about turning the game logic on those things off based on whether they have any relevance to the player at the moment. For example, scripts that handle ai behaviour for people, don't need to be running if they aren't visible or are across the map. The same goes for any scripts really.

You only want game logic running that is immediately relevant.

There are alot of terrain optimizations as well. Thats a whole subject on its own though.

 

Update. I fixed the spikes, they were several corrupted objects that moved to 0,0,0 and for a lack of a better word, were animating on top of each other, with physics colliders.

But now, when I create a stand alone build, the spike is back. The profile says about 64% is being used in Culling! Is there a occlusion data file? What am I doing wrong here?

 

Update: We switched back to Forward Rendering vs Deferred on all cameras and the spikes have lessoned.

 

How much does this correspond to the problem under discussion?
I have in the scene only the camera, the painting is done through the Shader DrawProcedural. Culling 11% - as it should be? This can be turned off?

 

The culling in your case takes almost no time. So it's probably just a small overhead for doing nothing.

 

I think it's too much for nothing, in comparison with Space OnRenderObject() or SpaceInfo OnRenderObject()

Code (CSharp):

1.   void OnRenderObject()
2.   {
3.     if (Stars == null)
4.       return;
5.     UInt3 Id = Pos.Id;
6.     if (NeedUpdate(Id)) {
7.       UpdateBoxGPU(Id);
8.       LoadBoxFromGPU();
9.     }
10.  
11.     int indInitSort = SpaceCompute.FindKernel("InitSort");
12.     int indSortGalaxy = SpaceCompute.FindKernel("SortGalaxy");
13.     SpaceCompute.SetInts("Id", Pos.Id.ToArray());
14.     SpaceCompute.SetInts("Seg", Pos.Seg.ToArray());
15.     SpaceCompute.SetInts("Pos", Pos.Pos.ToArray());
16.     ComputeBuffer.CopyCount(Stars, ArgCounter, 0);
17.     SpaceCompute.SetBuffer(indInitSort, "Counters", ArgCounter);
18.     SpaceCompute.SetBuffer(indSortGalaxy, "Counters", ArgCounter);
19.     SpaceCompute.SetBuffer(indInitSort, "GroupCounters", ArgDispath);
20.     UpSort.SetCounterValue(0);
21.     SpaceCompute.SetBuffer(indSortGalaxy, "Box", UpSort);
22.  
23.     SpaceCompute.DispatchIndirect(indInitSort, OneArgsDispath);
24.     SpaceCompute.SetBuffer(indSortGalaxy, "Sort", Stars);
25.     float MiddleSort = BOX_SIZE;
26.     SpaceCompute.SetFloat("LimSort", BOX_SIZE*20.0f);
27.     while (MiddleSort > MinStarRadius)
28.     {
29.       SpaceCompute.SetFloat("MiddleSort", MiddleSort);
30.       SpaceCompute.DispatchIndirect(indSortGalaxy, ArgDispath);
31.       SpaceCompute.SetFloat("LimSort", MiddleSort);
32.       MiddleSort *= 0.5f;
33.     }
34.  
35.     UInt4[] arr = new UInt4[3];
36.     arr[0] = UInt3.ToUInt4(Pos.Id);
37.     arr[1] = UInt3.ToUInt4(Pos.Seg);
38.     arr[2] = UInt3.ToUInt4(Pos.Pos);
39.     PosBuff.SetData(arr);
40.  
41.     ComputeBuffer.CopyCount(Planets, ArgCounter, 0);
42.     StarsRender.SetFloat("MaxDistance", 99000);
43.     StarsRender.SetBuffer("GlobalPos", PosBuff);
44.     StarsRender.SetBuffer("Base", Planets);
45.     StarsRender.SetPass(1);
46.     Graphics.DrawProceduralIndirect(MeshTopology.Points, ArgCounter, 0);
47.  
48.     ComputeBuffer.CopyCount(Stars, ArgCounter, 0);
49.     StarsRender.SetTexture("AnimatedTexture", AnimatedTexture);
50.     StarsRender.SetVector("AnimatedTextureSize", new Vector4(0.125f, 0.125f, 0.0f,0.0f));
51.     StarsRender.SetBuffer("Base", Stars);
52.     StarsRender.SetPass(0);
53.     Graphics.DrawProceduralIndirect(MeshTopology.Points, ArgCounter, 0);
54.   }

 

I am also getting huge spikes when usually my game can run over 150FPS, I have 8x8 terrain objects 512x512 length. Using Unity 2017.2 Beta.

 

So I am also gettin a spike in CPU usage on Scene Culling / WaitForJobGroup. The thing is, my project is 2D and I turned occlusion culling off on my cameras. For some reason, I still get this spike. This happens even when the player is in an empty room with no enemies or projectiles. Given that the last reply on this thread was nearly a year ago, I don't know if I will get any help with this, but I thought I would try. Seems like this is an issue with Unity that they never resolved. Anybody else having this problem on 2D?

 

too answer your old question, this is unity 2018.3.5f1. simple 2d scene, some sprites, culling turned off in the camera. looks like this will never be fixed.

 

Most likely it's regular frustum culling which is always used and can't be turned off in the camera.
It has nothing to do with occlusion culling.

Though these timings are definitely not normal and most likely it's a bug.
I bet it's related to particle systems, they've been always caused troubles like this.

Try to disable pre-warm if it's enabled

 

I don't use any particle systems... just some sprites, and a few quad on post render for UI.

 

I also have same issue with frustum culling. It have some huge spikes and can't be turned off at all.

I saw a blog with documentation on how to render all objects not using unity camera render. send it directly to GPU and all those spikes and heavy ms go away. I will try to find the blog again.

 

There are two different problems mixed in the topic.

When spikes are consistent, like in foxes' message, this is indeed Culling issue:

But when spikes are rare (once every few seconds) and extreme (5-10 times higher than usual), like in vbs' message, then this is issue with Job Workers randomly freezing when OS doesn't give them any time slices, so main thread stalls while waiting for them to finish. This is unrelated to culling, it's just that culling uses jobs extensively. And when theres only single core, and thus no worker threads available, these spikes disappear.

 

My problem was I was calling a very expensive method that updated the camera's orthographicSize every frame without realizing it