transmission is dark

[elalish]

It seems like the attenuation color ends up considerably darker than in any of our rasterizers as a general rule, and I can't think of a path-tracer reason for that. It's especially clear here. Interestingly, khronos-AttenuationTest also shows a disparity between the first row and the others that I don't quite understand. Possibly related?

[emackey]

I noticed this just recently! The original AttenuationTest screenshot was rendered in an earlier version of this very path tracer some 5 months ago. Indeed this model was designed while referencing the then-current version of this dspbr-pt as a guide for getting the colors right.

The math should be simple enough: The middle block of the top row is a unit cube with a transmissive baseColor of [0.1, 0.5, 0.9] as defined here. The next block down is also a unit cube, but instead of baseColor it uses attenuationColor [0.1, 0.5, 0.9], with unit size, unit attenuationDistance, and unit thickness, defined here. When viewed mostly face-on (mostly axis-aligned), this should produce the same color as the row above, I believe. And indeed that was the situation when I first created this model. But these days the rows look different:

It looks to me like something changed in dspbr-pt in the intervening time.

One thought: Perhaps the backs of the top row are doubling the color density there? That row is set for single-sided rendering, but path tracers may ignore that. I'm still not sure why it changed, though, as the model hasn't.

[bsdorra]

@elalish, @emackey Thanks for the detailed input! The difference in the first row is indeed the result of an additional back-face evaluation. I recently changed the behavior to be consistent to the Dassault path-tracer reference. It now effectively evaluates albedo^2 for volumetric/thin objects. Before, it simply used sqrt(albedo) in all thin cases, but this then breaks rasterizer consistency when having thin/thin objects. We’re also discussing this internally right now as our artists are not exactly happy with the current behavior.
I also noticed that the absorption samples are generally quite dark. I have no good explanation for it right now, need to run some tests. Let’s discuss on Monday.

[bsdorra]

Just checked TransmissionRoughnessTest and DragonAttenuation (default variant). Those scenes also use colored transmission, no absorption, so the reason for the dark result is the same as mentioned above.

[emackey]

I don't suppose there's any chance that dspbr-pt could be made to honor the doubleSided: false flag, at least for thin-walled transmission? If a ray hits the back face of an opaque or thin-walled surface, it should not interact.

The other alternative I can think of is to edit the models, but of course it wouldn't do to remove the back half of the dragon. I suppose the models could be made intentionally double-sided, and the color lightened such that the rays were expected to pass through exactly twice, but most realtime rasterizers don't support 2 layers of transmission, only one.

[elalish]

Wait, DragonAttenuation doesn't use absorption? That seems like a misnomer. Should we update that? I also agree with @emackey regarding respecting double-sided.

[emackey]

Wait, DragonAttenuation doesn't use absorption?

Sorry, it does. It has material variants on it. The default variant does use absorption, but there is a surface-only variant for comparison.

The dragon is pretty hard to judge because the surface details are so complex. The thickness map is probably not doing it justice.

[bsdorra]

Right, sorry for the confusion. Dragon default variant does have absorption and neutral albedo, I was looking at the wrong variant.