Hello,
I wanted to post about the following issue which we’ve been encountering: under higher intensity local lights it seems that meshes using the “Hair Shading Model” can become overly bright. This to the point where clearly the values no longer make any sense, especially on areas conceptually occluded by body parts (the character’s head in particular of course). I setup an environment to test this, here is an example image showing the problem:
This is with a pointlight with direct intensity set to 300. Understandably the first suggestion would be to reduce the brightness of this particular light but I’m against it since it would severely limit the artistic freedom related to lighting going forwards, as well considering 300 isn’t crazy high. I think the shading just looks broken, especially knowing this only occurs for the Hair Shading Model.
Context:
Now, I can’t provide any project files due to the confidentiality of them but I’ll do my best to explain the context in which the project exists and the problem occurs. Feel free to ask for more details and I’ll do my best to provide them.
First of all the project setup:
HDR is disabled, Nanite is on, Lumen is on, VSM’s are on, Megalights are on (but has no proven effect if disabled), we are currently setup to use SWRT.
Secondly the material:
Hair Shading Model, Masked, Two-sided
CVars:
I tried initially via CVars to identify the issue at hand and fairly quickly found that disabling r.Lumen.DiffuseIndirect.Allow removed the glow on the hair. Obviously this isn’t a great fix though. So instead after some trial and error I found that the following settings were the only ones that had any particular effect on our issue:
- r.Lumen.DiffuseIndirect.MinTraceDistance
- r.Lumen.ScreenProbeGather.ScreenTraces
- r.Lumen.ScreenProbeGather.ScreenTraces.HairBias (seems inconsistent)
- r.Lumen.HardwareRayTracing
Setting a MinTraceDistance is an obvious one, but also not really usable since it would just limit the range of our GI. But interesting it must be trace related!
ScreenTraces logically mitigate the problem then, since fewer samples get taken from the bright probes in the scene. But it still it’s great, here are images without ScreenTraces and then with:
A clear improvement but obviously still overbrightened. Logically this made me wonder what the traces are actually doing, so via r.Lumen.ScreenProbeGather.VisualizeTraces we can see the following (example without screen traces):
Certain rays will sample adjacent probes from time to time of course, but in this case it seems they also cut directly through the middle of the sphere (supposed to represent the headmesh, similar was detected on skeletal meshes). Which seems to me like the main problem. Where ScreenTraces just mitigates this, though perhaps I’m incorrect on that.
Finally I wanted to at least mention HardwareRayTracing, obviously it would help resolve such issues. Case and point this image (no properly adjusted settings):
We can’t always just use HWRT, since weaker platforms are to be supported. To me this is one of the smoking guns that shows the blame clearly lies with Lumen SWRT, and in particular with the probe gathering.
Renderdoc details:
I also opened up renderdoc in case there was some obvious fault at play here. And perhaps this is self evident but here the pipeline does the problem first appear:
Conclusion:
Is this a known issue with the engine or rather our setup that can be tuned?
What can be done about it overall?
Do you need additional info?