search

DassaultSystemes-Technology / dspbr-pt

A WebGL2 Enterprise PBR sample renderer
Apache License 2.0
139 stars 19 forks source link

transmission is dark #30

Open elalish opened 3 years ago

elalish commented 3 years ago

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 commented 3 years ago

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:

screenshot

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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