Occlusion culling CPU spike in profiler

Hi, it seems that occlusion culling in Unity 5 creates unusually large spikes on the CPU in the profiler. I’ve noticed this problem in multiple scenes, in multiple projects, and have reproduced it in a simple scene with a few cubes in it.

There is only one camera, one directional light and 9 cubes using the standard specular shader. The cubes are marked as occluder and occludee static, and the occlusion culling settings are default.

Here is a screenshot of the scene :

I saw a post with a similar problem, which was solved by removing occlusion culling on a second camera that should not have used it. However, in this case I only have one camera, and it needs occlusion culling.

1 Like

I’m also encountering this spike caused by WaitingForJob (though mine is under Culling/SCeneCulling/CullAllVisibleLights/WaitingForJob).

I need the occlusion culling as I am creating a large detailed environment with many rooms, so clearing the baked occlusion is not an option. I’m going to try being more selective about what I flag as Occluder Static and see if that helps, but I have my doubts. I’ll post my results here.

Quick update: no, reducing the number of occluders made no difference.

Having the same problem myself.

Checking the profiler in an attempt to optimise my scene, and noticed that whenever the camera turns, there is an enormous spike in CPU usage coming from Camera.Render/Culling/SceneCulling/WaitingForJob. Whatever it is, it seems to take up 87% of the CPU for a brief moment, dropping the framerate from a smooth 70 to 10 or lower.

I have the same issue, even if I remove Occluder static, and ocludee static from all objects, turn off occlusion culling on the camera and clear the oc data, I still get a spike every minute or so.

1 Like

Hmm. I had initially assumed it was something to do with my DetailGroup scripts (hiding and unhiding groups of objects based on distance to reduce distance calculations) but evidently not if others are having the same problem.

I submitted a bug report. I will let you know what they say.

We’re seeing the same issue popping up in random spikes, interested in seeing if this is a bug or just something that we can optimize somehow.

Still no word on their part? I have been optimising my project across the board and have it running at 120fps, but these occluder spikes are still causing dropped frames in there.

No reply as of yet.

Taken a closer look at the profiler; it seems that the WaitingForJob process that is causing these spikes is actually running on every frame, albeit at a much lower CPU usage. It runs constantly at about 0.5ms, spiking to 20ms at seemingly random intervals. This background process takes up something like 11% of the CPU usage, in an 80fps scene, with the spikes taking up over 80%.

Had a look around similar threads; according to this guy: http://forum.unity3d.com/threads/unity-5-rc2-occlusion-culling-stuttering-waitingforjob-spikes.298957/ The bug is even happening in the Unity Viking Village that came as an example scene for Unity 5.

I also submitted a bug report, and attached a basic scene with nothing but cubes that shows the glitch. Hopefully that should do it.

We are seeing stalls in Camera.Render->Culling->SceneCulling->WaitingForJob - our game is stalling once every couple of seconds (the stalls are for 10-16 seconds). We re running Unity 5.0.1

I think we need someone with a pro account to submit a ticket.

We made this problem go away by a combination of setting the Bounce Intensity on all our dynamic lights to zero (I think this stops them contributing to global illumination), and not continually enabling and disabling lights (just turning there Intensity to 0 rather than fully disabling them seemed to improve performance).

1 Like

I found that unmark light disabled/enable during runtime as static dit the trick for me.

I have the same problem in 5.0.2f1 and 5.1.1f1. Although my game is 2D without any light sources so I guess I have to fiddle around and see if there’s another solution. I’ll make sure to come back here if I find anything.

Oh! I thought it was because I switch off static gameobjects that was baked in occlusion data. Is it still a bug?

I am still seeing these spikes as of 5.2.1p1.

Please note that ‘WaitingForJob’ is a very generic token and does not really identify a specific problem. We need to dig deeper to look at what job (from Unity’s multithreaded job system) is taking longer than we think it should. To do this, when you are looking at a CPU frame in Unity’s profiler, click the drop down in the upper left corner of the bottom pane and select ‘Timeline.’ In the timeline view, you can see what is happening on each thread, in actual chronological order from left to right. You can zoom in/out with the mouse scroll wheel to get a better look at the names and timings of specific markers. If you zoom in so far that you can no longer see the entire frame, there is a scroll bar at the bottom of the pane that lets you pan left and right.

Anyway, in this comment I attached an image of a spike frame in a profile I just checked. Have a look!

In this frame there are two problem areas that are causing large WaitingForJob stalls, which I’ve circled in red. The first one is caused by long CullSceneDynamicObjects and CullDynamicObjectsWithUmbra markers. The second one is caused by long Shadows.CullShadowCastersLocal and Shadows.CullShadowCastersWithoutUmbra markers. Note that all of the smaller marker boxes around those markers are the exact same types of jobs, they just normally take a lot less time to complete. On a non-spikey frame, they are all around the same short duration. Also note that there are different spike levels on different frames. The worst frames are as illustrated in this image, where a job in the dynamic object occlusion culling system has spiked and also a job in the shadow caster culling system has spiked. In other frames, only one of those two subsystems have a job that spikes, resulting in a spike that is not as severe as when both have spiked.

I don’t have any solutions to offer. I haven’t really started experimenting with content to see if there is anything obvious that could be causing this.

Also, I haven’t seen any patch notes that mentioned this, but @karl_jones mentioned in another thread that Umbra was updated in 5.2.1p2. It didn’t sound like the update involved anything related to performance though, so it probably did not affect this. Karl, any chance you could poke around into this one, too? :slight_smile:

EDIT: I should probably add, in case it matters: this is using legacy deferred rendering for all cameras.