Hello!
I am currently investigating correct up-to-date lighting setups and best practices and I’m looking at OnePassProjection VSM usage in combination with Clustered Deferred Shading. The documentation mentions that certain light features will prevent a light from being batched: [Image Removed]
However, testing this locally I am seeing that having all these features in a scene does not result in UnbatchedLights appearing in the GPU profiler, but only marks the usage of these features in the description of the pass:<br>
[Image Removed]
Could you provide information regarding this?
I also have a couple of additional questions:
- Is using the combination of OnePass projection + ClusteredDeferred is a generally recommended thing?
- What is the deferred shading algorithm when not using deferred clustered? Is it a tiled version of deferred or is the renderer doing fullscreen passes for each local light?
- The documentation mentions that adjusting r.Shadow.Virtual.OnePassProjection.MaxLightsPerPixel allows the additional lights to fallback to an inexpensive single hard shadow lookup algorithm. In my testing, I’ve seen shadows from lights completely disappear instead, where as I was expecting them to be still present in the scene without doing any SMRT. Is this normal behavior for this setting?
Thanks in advance!
Hi Fedor,
Thanks for reaching out. Could you share the project you used to test the One Pass Projection (OPP) feature? The feature is still being marked as experimental, so it could be that the setup you have is hitting an unexpected edge case. As for your other questions:
Is using the combination of OnePass projection + ClusteredDeferred is a generally recommended thing?
Yes, you will need to have ClusterDeferred shading enabled to use OPP.
What is the deferred shading algorithm when not using deferred clustered? Is it a tiled version of deferred or is the renderer doing fullscreen passes for each local light?
Without OPP, the shading of local lights will be handled using our standard shading path. This means that each local light will have to be projected into the scene and accumulated in an unbatched fashion, which can become costly the more local lights you add to your scene.
The documentation mentions that adjusting r.Shadow.Virtual.OnePassProjection.MaxLightsPerPixel allows the additional lights to fallback to an inexpensive single hard shadow lookup algorithm. In my testing, I’ve seen shadows from lights completely disappear instead, where as I was expecting them to be still present in the scene without doing any SMRT. Is this normal behavior for this setting?
Please share the project in this case so we can see if there is an issue in the OPP code. If you have any further questions, please feel free to reach out.
Cheers,
Tim
Hi Fedor,
Yes, it would be really helpful if you could please create and upload the test scene. As to your light feature question, I would assume that the documentation is up-to-date, but depending on what we can find out from the test project, we might need to update it accordingly.
Sounds good. Let me know when you have something available for us to look at
[mention removed] Hello! I have prepared the test project as you’ve requested 
I used 5.5.4 from Epic Games Launcher and create a new project from a blank preset.
I have created a test scene that has 2 bookmarks (1 and 2) that have the test setups required to reproduce what I’ve been seeing. I’ve also set r.UseClusteredDeferredShading=1 in project’s DefaultEngine.ini.
Here’s what I’m getting when running ProfileGPU on bookmark 1. A rectangle light, a light using light channels, a light using light functions and a light using profiles don’t seem to get unbatched:
[Image Removed]
On bookmark 2 I created a simple setup to illustrate the types of artifacts I’ve been getting with r.Shadow.Virtual.OnePassProjection.MaxLightsPerPixel. In the attached video (in the second message) you can see shadows glitching in and out of existence from some angles + blocky artifacts in some places when I set the MaxLightsPerPixel value to 1. The latter, I presume, is the border tile (?) where the ‘passing’ amount of lights becomes too big (i.e. 1 -> 2 in my case). With that said, some of the artifacts seem to be happening outside of those areas, and as you can see from the video, disabling SMRT by setting both the ray and the sample count to 0 doesn’t fix them.
If this is expected behavior, then I’d appreciate some general advice with how this value can be used for scalability purposes.
Thanks!
Hi Fedor,
Thanks for putting together the sample project and the accompanying video. It gave me a chance to verify that what you are seeing is indeed a discrepancy between the improvements on VSMs we have made and the public documentation. I got confirmation from the team working on VSMs that we now support batching of lighting channels, and light functions. Those changes have not been made public yet, but the docs team is going to publish some updates to that part of the docs with the 5.6 release to reflect those changes. In the end, this was merely a slight oversight on our part.
As for the second part, where you asked about the r.Shadow.Virtual.OnePassProjection.MaxLightsPerPixel, I have not had luck reproducing the artifacting that you are showing in the video. I did notice that you have an in-editor warning already being displayed about a MaxLightsPerPixel overflow, which could be the reason for you seeing those artifacts. Why do you need the MaxLightsPerPixel to be that low? From the comments on the Cvar, it suggests keeping the values to either 8/16/32. Do the artifacts improve if you set the value to 8?
Cheers,
Tim
Hi Fedor,
I dug through the code a bit, and MaxLightsPerPixel is mainly used to limit the number of local lights that can be iterated over in the VSM Projection pass. As an example, see VirtualShadowMapProjection.usf::820. Setting MaxLightsPerPixel too low introduces artifacts since the projection pass could not query a local light contributing to shadows. You will need to ensure that you are querying a higher number of local lights by increasing MaxLightsPerPixel to get around the artifacting, as we currently do not have any other mechanisms to control this behavior. This will tie into the SMRT settings you mentioned as well. If you are not tracing rays to the correct light sources, you cannot correct your soft shadows by increasing the ray or sample count. These should be adjusted once you have a sensible value for MaxLightsPerPixel. I hope that clears things up for you, but of course, feel free to ask any further questions if you have them.
Ok, I am glad to hear that! I will go ahead and close out the ticket then. Please feel free to reach out again if you have any further questions.
Hi Tim,
Thank you for the answer! Apologies for a delay on my end, I was away last week.
I used a clean project in a Epic Games Launcher UE 5.5.4 installation to run my testing and I created a simple test scene with a bunch of boxes and different lights. I haven’t saved the scene so if you’d like me to I can recreate the setup in a new fully empty project, reconfirm and send it to you. Let me know if I should do this
And do you have any information regarding the light feature usage with OPP + ClusteredDeferred? Or would that also require for you to take a look at the test project?
Got it, thank you! I will provide the test scene early next week 
Hi Tim,
Thank you for the confirmation! Great to know that I wasn’t seeing things 
Regarding the MaxLightsPerPixel overflow - I only set it to 1 for the visualization purposes in this case I did try, however, setting it to values lower than 8 to see if this is something that I can use for scalability - e.g. 16 MaxLightsPerPixel for Epic preset, 8 for high, 6 for medium and 4 for low. Unfortunately, setting it to 4 would result in the artifacting that you’ve seen in the video, thus my question. Still trying to wrap my head around SMRT scalability - I was thinking that MaxLightsPerPixel could be used together with decreasing the quality (ray count + sample count) of SMRT to still keep soft shadows on N amount of lights per pixel
[mention removed] ah, thank you so much, now it makes sense!
You’ve cleared up everything and I don’t have any additional questions right now Thank you so much for thorough answers, really appreciate it!