Shadowed Point Lights performance is... weird.

Unity 2019.3.0f6
HDRP 7.1.8

GTX 970
i5 3570k @ 4.2GHz

Been exploring HDRP for the past couple of days and one thing that seems really weird is the performance hog that shadowed point lights are. Also, how I can't seem to decrease their cost, other than disabling shadow casting altogether.
I understand that they are essentially 6 lights in one and are inherently costly, but each one is costing me ~0.75ms on the CPU (GPU seems unaffected), which is considerably worse than I've ever seen a Point Light cost, in any engine.
For reference 27 Spot Lights use up about as much CPU time as 8 Point Lights.

• ~5.0ms (~190FPS) with no Spot Lights

• ~5.5ms (~175FPS) with 8 Unshadowed Spot Lights

• ~11.5ms (~85FPS) with 8 Shadowed Spot Lights.

Also, what I found the weirdest is that changing settings such as Shadow Resolution and number of Cascades have no difference in performance.
Setting Cascades to 1 and Shadow Resolution to 32, which results in a pixelated mess, is just as demanding on the CPU as setting it to 4 Cascades and Shadow Resolution to 4K. There is absolutely no difference in CPU or GPU times.
Needless to say I'm hoping that it is a bug or something that I am overlooking.

Looking at the profiler the bulk of the time is going into:

• RenderPipelineManager.DoRenderLoop_Internal() (~10.25ms)
  • C#_HDRenderPipelineRender (~7ms)
    • C#_PrepareLightsForGPU (~4.4ms)

Funnily enough C#_RenderShadowMap is sitting pretty at ~0.75ms right after.
Again, regardless of Cascade count or Shadow Resolution.

Disabling the 8 Shadowed Point Lights the numbers go down to:

• RenderPipelineManager.DoRenderLoop_Internal() (~4ms)
  • C#_HDRenderPipelineRender (~2.3ms)
    • C#_PrepareLightsForGPU (~0.3ms)

One other thing, the Mixed mode for Point Lights doesn't work with Baked Indirect. Maybe that is by design.

Also some weird quirks:

• Even when Intensity is set to 0, so essentially it's not having any effect on the scene at all, it still costs as much as if it was visible. Potential room for optimization?

• Even after the light is past the Fade Distance and has no visual impact it still costs as much as if it was visible. That sounds like a bug, surely the whole point of the feature is to cull the lights that are past that threshold, like in any other engine that has that feature.

• Changing Update Mode to On Demand or On Enable also has no impact on performance, you'd think that since it's not calculating shadows in realtime anymore that performance would be affected.

 

Yes, shadow casting point lights are very expensive. It gets more worse when the shadows overlap, so points too close to each other.
What you can do is limit their range and decrease the shadow map resolution altogether with global point light shadow atlas size. The resolution had some impact on my game. But despite the resolution. it has always to render 6 sides to get a point light shadow.

Mostly over 20 shadow casting points in a dense area in realtime won't work.

 

I wish I could get 20, with 8 Point Lights my FPS more than halves from 190 to 85
I've been decreasing the numbers as low as they would go, disabling features left and right and the numbers stay locked.
The only things that have decreased their cost were: Disabling the light (surprising I know ), disabling shadow casting altogether (again, surprising ), moving the lights so they don't affect anything in the scene (unbelievable ).
Other than that the moment a shadow casting Point Light touches an object the FPS tanks.
I'm hoping for improvements when the stable version comes out next week because right now Point Lights are almost unusable to me.

 

Do you know any game that has many realtime shadow casting points lights in a dense area where you can get over 60 fps on an average computer? Me not, it is either baked or faked or a lot of objects are excluded from shadow casting. Unless there is a bug, I think you cannot expect that HDRP get a lot better in that point.

 

I understand that, Ive been using game engine since UDK and the early days of Unity 4. This is not my first rodeo.
I've also been using UE4 for a little less than a decade now, being intimately familiar with how things work over there, I'm dipping my toes in HDRP to see how it works.

What I find weird when it comes to shadow casting lights are 2 things:

1. ~0.75ms for a single Point Light is very unusual, they are expected to be costly but I've never seen it be that costly.
2. Disabling/Decreasing all settings related to lighting/shadow casting (other than disabling lighting/shadow casting altogether) has 0 impact on performance. As I said before, a 4K shadowmap and 4 cascades costs the exact same, according to the profiler, as a 32 shadowmap and 1 cascade. That is likely a bug.

Also, I added some extra information to my first post with some tinkering that I did.

HDRP is still in very active development, that means a lot of potential for bugs.
Looking around other threads in here there are constant bugs and issues of all kinds being reported and acknowledged, I wouldn't be surprised if there were issues with how shadow casting is being done currently, but no one noticed yet.

 

C#_PrepareLightsForGPU seems to be the CPU collecting which objects need to go into each shadow projection, it is indeed far too expensive for such a low amount of lights. How many objects are there in the scene?

 

I don't know your scene setup, but I have interior scene with a rather big museum (at night) with lots of point lights casting shadows, and I get over 30 fps on my RTX 2060 with Intel i7 (9th generation). I also use it with Enlighten. But I had to do a lot of optimizations like combining meshes and adjust the shadow distance for each individual point light. Not the shadow cascade. I mean the individual shadow range settings for each light component.
Now that I see your hardware specs, I would say your hardware is too weak for HDRP with shadow casting point lights.

 

I assumed so as well.
Just created a simple test scene to isolate the issue.
3 objects. A plane, a box and a sphere.
9 Point lights just scattered around.

Literally all there is to it.

 

9 Point Lights affecting 3 objects really shouldn't be too much for my specs. They are outdated as hell I am aware. But it's really weird when UE4 with the same scene setup runs at over 120FPS.
It might be that older CPUs simply don't perform well with HDRP because it wasn't developed with them in mind. But I'd really love an official answer.

For reference, in a scene in UE4, comparable to the one in Unity that I posted above, each Point Light costs ~0.45ms, expensive but manageable. ~0.75ms is not too far from being double the cost.
Now, I'm not trying to start a fight over engines, I just wanna know if that is just how it is, or if maybe there is some problem that has gone unnoticed under people's noses.

 

This definitely sounds bad, specially when HDRP is supposed to use point/spot shadow caching while UE4 doesn't.

 

Im experiencing exactly the same problem with HDRP 7.3.1. In my projects scene there are about 5 point lights using 256x256 shadow maps and 2 using 1kx1k + 4 spot lights in an indoor scene. Im also using a directional light.

Using the built in renderer the cpu time is about 12ms while GPU is about 3-5ms on average. CPU times do not really change depending on the view. Im also using a second camera that renders objects on a specific layer max. 2 at a time. I have an additional 3 spot lights that illuminate the objects on the 2nd camera. With this camera active the CPU time increases about 0.5 ms and GPU about 1ms.

I updated the project to HDRP and after I finished setting up all the lighting, broken materials and custom shader i noticed that the performance was a lot worse.
CPU time is about 40-80% higher (now depending on what the camera sees). 19ms worst case. And about 15ms average. GPU time is also slightly higher 3-6 ms. When the 2nd camera is active then CPU needs about 22ms (+4ms) for the loop and GPU +0.5ms.

So i tried to figure out why this happened. When the project is updated then it runs at 11ms but with broken lighting. As soons as the light components are updated (for example by selecting them in the light inspector) then performance drops. I can also confirm that this is especially caused by the shadow maps.

In order to achieve nearly the same CPU performance as in the built in renderer I have restrict to a maximum of 2 punctual lights (which includes points and spot lights) in the HDRP asset. So im just left with 2 lights + directional light in the scene and still about 12.5 ms CPU time. Disabling all lights the main thread needs 10.5ms.
Regarding the 3 additional spot lights that illuminate objects for the 2nd camera: those seem to also affect the CPU even if the 2nd camera is inactive (this does NOT disable the lights) and they do not appear on screen through the player camera (about 1ms in total). But even if the player camera somehow has to render them all that they affect is 1 plane and nothing else.
I also noticed rendering the directional light needs about 2ms.
And overall im using less pp and effects. Build is slightly better.
It tried to disable features in the hdrp asset and/or reducing light range but this did not help / the difference was very minor.
So maybe im making some really big mistakes setting up HDRP. But simply by comparing the default HDRP upgrading setup with the built in renderer in terms of performance makes me doubt using HDRP for that project. The upgrading decision is because of additional tools for artists and also because it was said to be focused on performance.

 

Quick cheat sheet:

• point light shadows are the most expensive possible. You are calculating 6 shadows instead of 1, almost no AAA games do it directly like that, or when they do, they fake it or it's for specific controlled locations
• UE4 performance tanks directly in relation to how many lights overlap. That's long before you think about shadows
• consider resolution of shadow maps/cascades per light
• fade out point light shadows very close
• use deferred not forward

Honestly pretty shocked people think they can render 120 shadow casting frustums (20 * 6 light directions) and somehow expect acceptable performance.

The best thing people having perf issues can do is look at what AAA actually does. HDRP gives you tools to go from game to film. If you throw film-level stuff in a scene and expect magic then you should learn more about what is happening under the hood, and learn what the techniques are for avoiding these issues while looking mostly the same.

I really can't fault HDRP here. It's the fastest, best-looking forward-gen engine I've ever used, and I've used quite a few. But it cuts both ways, if you don't know what it's doing or how it's behaving then you can be hit by slow performance.

 

I do understand that point lights are costly. But in the first place I made a direct comparison between those 2 renderers and thats my first impression with few hours of time spent into hdrp. And there are multiple issues. Not only the shadow map performance is worse (in my case) but also when using a second camera. The scene consists of three rooms those lights are not visible all at once. So i do not think that this is a pretty exotic scene that only the default unity renderer is able to handle with acceptable performance results.

 

Ah the second camera lark. HDRP doesn't work properly with second cameras. It's not designed to and will do light-lists and all that extra work all over again. Ideally you remove the second camera with HDRP (you should not do the same things as built-in renderer). HDRP is bringing out a new feature called Compositor which should replace the need for a second camera.

In short the camera in HDRP does way, way more up-front work than built-in does. The design of SRP is not about layering cameras and Unity is working toward restoring that functionality in URP, and providing alternatives for HDRP.

 

That's true. I read a lot of post that are all related having a second camera which causes a huge performence decrease. Actually I think Unity need to communicate in their manual that second camera is no longer "legit". Developers still think some of the old techniques from build in render works with HDRP. But actually what I got taught at University is that you probably should never render the scene more than once. You cannot expect that performence in realtime for AA(A) looking game.

The other thing is, that artist often "abuse" point lights and their shadows. Even the Unreal engine manual states, that you should used them rare. Often a spotlight is far enough to achieve the lighting effect and will save a lot of performence. That means, if you scattering your high density area with a lot of points light, more worse when overlapping, you killing the game. Get rid of the mindset that you can use a realtime point light with shadows for every lighting source and every light bulb in your scene. It does not work.

Solutions:
- Bake it.
- Fake it.
- Use spotlights and light cookies. If you bake your lamp fixture, you actually get far more realistic shadows that are impossible to capture in realtime without DXR plus you can include caustics.
- Use emissive material.
- Use decals or textures.
- Use vertex color.
- Decrease the global shadow distance for the main camera.
- Manually tweak the individual shadow distance for each light component.
- Avoid overlapping shadows.
- Exclude not important meshes from shadow rendering.

 

Yes, I am aware, I even remarked on that.

Yes, light overlap is a problem you need to keep in mind in UE4, but I don't see how that is relevant.

I've set them from as low as they will go to as high as they will go, the performance doesn't change at all from 32 pixels all the way up to 4k. That is one of the reasons I made this thread, that just doesn't make sense and seems to be a bug.

I think you mean fade out shadows that are far? In any case, I did test fading out the light entirely based on distance (I forget what the option is called off the top), which is another reason for this thread. As I remarked in one of my previous posts, fading out the light completely has no impact on performance at all, The light has no contribution to the scene but it still costs just as much.

I am, and yes I am aware of the differences, pros and cons.

I am aware that that would be quite absurd, I think you misunderstood something or I wasn't clear in something that I've said?

I've dedicated over a decade of my life to learning these things. While there is still always more to learn nothing that we are talking about is news to me.

Yup, HDRP is quite impressive, but as it is still heavily in development bugs can and will squeeze through the cracks, that is the main reason for this thread, I've found some really unexpected results from testing how lighting works in it and wanted to know if they are expected.

As of yet the only answers I've gotten are from people misunderstanding what I was saying (and I tried so hard to be descriptive so that this wouldn't happen), or people assuming I know way less than I do and I'm just some ignorant person expecting magic.

In my mind the situation was pretty simple, I'd describe the results of my tests and, hopefully, someone from Unity would answer with a simple, "Thank you for reporting these findings, they are not expected, we'll look into it", or an even simpler: "Sorry, but those values line up with our expectations, everything looks fine." Like I've seen happen with other multiple threads that are reporting HDRP bugs and general weirdness.

I wish I could just lock down this thread at this point, obviously nothing of value will come of it for anyone involved.

 

I think nobody from Unity would admit officially that the shadow performence is bad (if that's actually real the case).
HDRP is out of preview and advertised to be production-ready. So I don't think there will be a new future update with heavy performence improvements for realtime shadows.

Things like realtime shadows and realtime reflections will be a still bottleneck for computer games for long time. Even with RTX card you cannot go insane with the quality.

Even if a game had already too much point lights, a small patch would not make it really more playable. If you go over certain amount and push the quality too high, only very high-end gfx cards will make the game playable.

So unless there is a comparison of an excact same lighting scenario in another engine with actual benchmarks and detailed screenshots of the setup to compare: No.

 

It's not like this is unfeasible. ID Tech 6 uses shadow-casting real-time lights everywhere and manages to run even on Switch. The ingredients for high performance real-time shadow-casting point and post lights are:

1) Scenes where most shadow casting lights and shadow casting objects are static.

2) A way to efficiently determine which pixels are shaded by which lights to avoid processing lights which won't contribute. 2D or 3D tile-based light techniques are a must.

3) A way to quickly determine which shadow maps actually need to be updated, reusing the shadows where none of the casters have moved since the past frame. Can be augmented with time-slicing techniques to enforce the maximum number of shadows updated per frame and give priority to certain lights over others.

4) A fast potential visibility set calculation, preferably with some sort of caching mechanism to avoid unnecessary re-calculations.

5) Having separate shadow maps for static objects, which are composed with the ones for dynamic objects. This greatly reduces the number of draw calls needed for subsequent shadows updates since only the dynamic objects need to be rendered.

 

Very interested in the original question. I hope unity can reply with an answers.

 

I also would like to see a follow up for this question.

 

This has been a useful thread. I can't wait for Unity to come back with an explanation, so I'm going to redesign my lighting and fake it where possible.

 

- Use spotlights and light cookies. If you bake your lamp fixture, you actually get far more realistic shadows that are impossible to capture in realtime without DXR plus you can include caustics.

Cookies are really the best solution for both point & spot, but it's an awkward process in HDRP. I implemented a 'lite' approach by having a sphere with inverted normals and a custom reflection probe, which I stick prop lights into to bake, then use the resulting cubemap.

In many ways I'd rather see them provide better cookie support, than eke out a few percent more performance on realtime shadows, since you'll always effectively be constrained to using realtime shadows for 1-2 lights at a time.

For example, cookie sliders for volumetric intensity & opacity would be a much quicker workflow than having to keep alt-tabbing, image editing, and observing the result. It would also be good to blend textures/noise with varying cubemap rotations, particularly for caustics; the problem if you want 50 cookied lights w/ caustics is either they all have the exact same caustic (which can in many cases look eerily familiar), or 50 cubemap textures eating memory.

Considering you can set up your own cookie-baker in Unity (awkwardly), having a custom tool to do that would also be a big help and I think something that's sufficiently needed to be an in-engine feature. Cookies kinda get overlooked since there's little documentation on them, they're not straightforward to bake, and they're relegated to a 'yes or no' option. Often the only time you see them used is the mandatory one stuck on the end of the player's flashlight, but once you have a workflow to create them they're more useful (and much more performant) than shadows.

 

Thanks for the information.
Can you also explain why the resolution of a shadow and the shadow atlas has not so much impact on the performence?

 

That is a thing I still do not understand. Often the GPU is advertised to be the most influence in gaming despite architectures like HDRP seems to be way more CPU hungry and CPU bound plus the problems with garbage collection. I invested more into a RTX than into the processor. Guess this was a mistake because all these fancy and expensive CUDA kernels sleep most of the time while Unity eating the CPU with it's culling, shadow and light proxy volume managers. Is there a way to shove the workload more to the GPU?

 

The GPU is advertised as having the most influence in gaming because NVidia care more about selling GPUs to gamers than Intel care about selling CPUs to gamers.

Really GPU performance beyond a 970 is unneeded horsepower for the console ports that make up the PC gaming market these days. NVidia know this, which is why they plug 4k, RTX, or other gimmicks that make a $1000 GPU somewhat useful to the mass market.

I'm not the greatest Unity defender, and I don't think it's necessarily the best engine for visuals, but you can still easily GPU bind yourself in HDRP if you want to just by turning raytracing on and setting SSAO/SSR to max (or path tracing) in 4k. Or you can make the awkward move to DOTS, in which case Unity is the best engine for CPU performance at the moment bar none.

 

That sounds terrible. If you know the light is beyond shadow fade distance, why bother building a list of casters for a shadow that will not be rendered? With new SRP versions constantly relying on core engine features to work at all, the idea of "SRP not having control" over anything makes it sound there are "lines" the SRP team is not allowed/capable of crossing, which is expected from Asset Store stuff, not from Unity features.

Another result of weird design decisions. In a sensible renderer, the cost for culling additional cascades should not increase linearly because a specialized culling algorithm can build the PVS for all cascades while traversing the scene only once.

Sounds like SRP is hamstrung by relying on the inflexible and limited PVS generation functions offered by the core engine and, worse, changing that is off-limits for the SRP team.

 

Ouch ... core's culling has a certain reputation so I was hoping that you guys had access to the renderer list.
Now this explains the bad perfs I'm seeing on hundred object and I will work around it ... so thanks for the info and may Zuul grant you low level access to scene data.

 

When will HDRP finally succeed?

 

Regarding your statement, that means stats like "CPU 11.4 ms vs. GPU 1.6 ms" are quite normal for HDRP? Seems impossible to me that it could be GPU bound.

 

does this also apply when Rendering UI to a render texture by using a camera? I have noticed that fullscreen passthrough actually improves this a lot, are there any other recommendations for this? Thanks

 

Hi Julien, a question related to your comment: I'm profiling my scene and noticed that, when the reflection probe is set to "Real Time", performance drops (obviously), and according to the profiler, "RenderShadowMaps" time is something like 15 times higher. There's only 1 directional light in the scene casting shadows. That seems to suggest that, for each cubemap face, shadows are rendered. Is that the case? If so, any way to optimize it?

 

6 cameras, 4 cascade per camera. It's surprising that your performance drops only by 15 times.

Check "Custom Frame Settings" toggle on reflection probe, and disable shadows.

 

how come spot lights are more expensive?
surely at the very least, you can at least match point light performance by rendering a point light and discarding most of it

 

Even when only rendering when they're enabled, they're still extremely expensive. Only a few point lights easily eats the entire 16ms frame budget and no quality setting makes them cheap enough to be enabled at all.