Title is self explanatory: WorldLightManager.Collect is taking over 3ms - and I have seen it take upwards of 7ms in a scene without any lights on it.
The scene has quite a few GO - around 8K - the objects are being culled aggressively with a custom BurstJob - although irrelevant using forceRenderingOff=true. I am expecting the world to reach at least twice this number, although most will be disabled GO that get loaded as the camera flies.
This is using HDRP in the preview version of unity 6.
There seems to be something weird with the implementation, since it does not make sense to be spending upwards of 9ms, just “collecting” lights.
The world in question is runtime generated, and consists of dozen of prefabs and occupies a fairly “small” world space - around 100mx50mx100m, with a typical 2M character that can see up to 80m around, so the world needs to be in-fact loaded.
Weirdly enough, adding 200 - 300 random lights, makes the timing change very little, so the issue are not the lights themselves but the collection algorithm.
Does anyone have any suggestion on how to handle this scenario?
Hey,
This function is used to build a list of lights for the ray-tracing passes of HDRP. First, if you’re not using HW Raytracing, you shouldn’t see this in the profiler (check the camera or default frame settings).
If you don’t have any lights in your scene I don’t see how this code can be expansive, could you enable deep profiling in the profiler to get more details about what’s happening inside the function?
I reckon if I need ray tracing there is no way around it, unless I change the internal collection code? Since in my case the lights wont change, I could cache the results instead of calling collect? Its just weird since the performance difference between having 0 actual lights and 500 is less than 1ms, but the total time is still over 3ms - 5ms most of the time.
Yeah if you need raytracing then you need this function to set up the lights for RT.
Indeed this is weird, if you could share a screenshot of the deep profiling capture maybe we could identify something inside this function that is causing this perf problem?
Also, note that CPU times in the editor will be pretty different than in builds. For example, if you release your builds with IL2CPP, the cost will likely be less than what you see now.
