Path Tracer bright material performance issues

Unity Engine
, , ,
1

The more I use the Path Tracer the more oddities crop up.

There are issues with performance when rendering with brighter materials in an enclosed space.
This can be tested on any if not all of the current version of the Path Tracer by simply enclosing a room and applying white or white-ish materials onto the walls, floor and ceiling.
You’ll notice the performance takes a nosedive as soon as you have a camera inside this space.
However with the same room and applying a darker material, performance returns to what I’d call normal levels.
This seems to be a issue of how the GI/illumination rays are being handles when they hit bighter surfaces, where they will continue to bounce and not lose energy until they reach the max depth.
This happens regardless of the reflectivity and metalness of a surface. You can have a 100% mirror-like surface but to the Path Tracer it’s seen as a white wall in terms of the GI calculations.

A possible solution for this is to decouple the GI and Reflection rays from eachother? Why not have a seperate min-max depth for both rather than the combined as they are now.
Having 10 reflection bounces, or 10 refraction bounces has less impact on the performance compared to the GI bounces. With GI bounces anything over 4 seems to tank performance to an insane degree considering the minimal to no visual benefit.
For the sake of “ground truth” there should still be an option to increase the bounces, but I still think we should have a slider for each “pass” if you want to call them that.
One min-max depth for reflections/refractions (perhaps these should be seperated too??), and one min-max depth for the illumination bounces.

As a test I tried to see the performance difference between white and grey materials.
Rendering 30 panoramic cameras with whiter materials took around 10 minutes to complete. Not too bad but time is money and 10 minutes can quickly add up if you have to do many in a row.
Rendering the same amount of cameras with grey materials (50% rgb) took around 6 minutes to complete.
These tests were with a denoiser and that has an added cost, but in general the grey materials can run up to 3 times as fast if no denoiser is used.

TLDR:
There are huge performance penalties when using bright materials, this seems like a bug or an oversight and something has to be done about this.
Having seperate minimum and maximum depth for reflection/refraction and illumination rays is a possible solution.

2

Sorry for the super late reply, but you are right that there might be an issue about this. Thanks for super detailled feedback.
I’ve logged something and it will get looked at ! :slight_smile:

3

No worries. We managed to get around the issue by simply modifying the russian roulette rules.
We added our own rule set based on a custom threshold value and at which bounce this threshold should start.

With the current way the PT is set up, the russian roulette threshold is based on more or less 10% of the current max depth value. At a glance this make a lot of sense, the deeper you want rays to bounce the less energy it would carry and the more rays would get culled as a result. Meaning the higher the depth the better the performance.
But thinking about it some more, it makes less sense. You could have a max depth of 256 bounces, or even 1024 in my testing, and it would perform so much better than if you’d set the max bounce to only 10. Near infinity mirrors perform better than one capped at 10 bounces. This sounds silly.
Of course based on the roussian roulette threshold calculation this makes sense. Higher the max bounce = more rays are culled, as the energy required to continue bouncing is much higher.

With our workaround, we define the russian roulette theshold with a user specified value instead of one based on the depth only. It’s actually a combination of the two because of the second modification.
The second modification is to define at which bounce should this user defined threshold start.

By modifying the PTs russian roulette rules we’ve manage to increase performance by around 30%++, with minimal image quality loss. There is a loss, but it’s barely noticable because we usually define the rules to only apply after the third bounce, meaning up to the third bounce quality is equal to the old rule set.