Discrepancy between homogeneous and heterogeneous media

[phyqh]

Summary

I noticed a discrepancy between homogeneous medium and heterogeneous medium, when the heterogeneous one is modelled to behave exactly like the homogeneous one (using constvolume). I have ran into this problem using both the prbvolpath and volpath integrators where the media are absorption-only (albedo set to zeros).

System configuration

System information:

OS: Windows-10
CPU: Intel64 Family 6 Model 183 Stepping 1, GenuineIntel
GPU: NVIDIA GeForce RTX 4070 Ti
Python: 3.11.4 (tags/v3.11.4:d2340ef, Jun 7 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)]
NVidia driver: 560.94
CUDA: 12.4.131
LLVM: -1.-1.-1

Dr.Jit: 0.4.3
Mitsuba: 3.4.0
Is custom build? False
Compiled with: MSVC 19.37.32822.0
Variants:
scalar_rgb
scalar_spectral
cuda_ad_rgb
llvm_ad_rgb

Description

I have defined two very simple scenes (can be found in the zip file in the beginning of next section) that are geometrically equivalent, where a cube is defined in front of a large rectangular area light source, with the light's radiance set to (1, 1, 1), Below is a view from a different camera configuration as would be used for a simple reproducible, that should show the scene in a clear way:

The only difference in the two scenes is how the participating medium is defined: In simple_light_heterogeneous_volume_modified.xml, the medium type is heterogeneous, in simple_light_volume_modified.xml, the medium type is homogeneous, and both medium should have zero albedo (to model an absorption-only volume), and constant sigma_t that is different across three channels:

<rgb name="sigma_t" value="0.5, 0.25, 0.1" />

and

<volume type="constvolume" name="sigma_t">
<rgb name="value" value="0.5, 0.25, 0.1"/>
...
</volume>

I expect the two scenes return identical results, but they do not, when comparing between a ground truth image I generated based on manually calculating transmittance, the heterogeneous image appears to be dimmer than a correct result (Up: Heterogeneous, Down: Homogeneous):

Additionally, as you would notice in point 3 of the next section, if sigma_t has the same value across all three channels, the result is correct which appears very curious to me.

I would appreciate your help, and any comments on why this might be happening, or if there is anything wrong about my assumptions / files.

Steps to reproduce

All files needed to reproduce this issue is in this zip file:
reproduce.zip

1. Place reproduce.py and the two xml files under the same directory, from that directory, run reproduce.py. The resulting pngs and exrs would be saved to this same directory (Maybe you would like to place my exrs and pngs to a separate folder first so that they don't get overwritten).
2. Compare the two exrs. It is optional to see the diff (no absolute) between the ground truth transmittance image gt_transmittance.exr and the two noisy exrs obtained in 1, on my end it is clear const_heterogeneous.exr appears dimmer, while homogeneous.exr appears fine and unbiased.
3. Importantly, you could try setting the sigma_t in both xmls to:

<rgb name="sigma_t" value="0.5, 0.5, 0.5" />

which I have commented out, if sigma_t is set to be the same across three channels, the results from both homogeneous and heterogeneous media would be consistent.

List of contents in the zip file:
reproduce.py, simple_light_heterogeneous_volume_modified.xml (for the heterogeneous scene), simple_light_volume_modified.xml (for the homogeneous scene), the two results for these two scenes (const_heterogeneous.exr and homogeneous.exr respectively), and a ground truth image that is obtained via directly computing the transmittance (gt_transmittance.exr, this is obtained using another script and not obtained using reproduce.py, this image could be useful if viewed in certain exr viewers that compare two exrs using difference $ref - img$).

[njroussel]

Hi @phyqh

Thanks for the detailed description and reproducers.

I'm able to reproduce this discrepancy. There indeed seems to be an issue with volpath and prbvolpath, only volpathmis is producing the correct output for the scenes you've provided.
It might take us some time to get to the bottom of this.

[phyqh]

Thank you @njroussel for your feedback and information!

Now that you mentioned it, I could indeed obtain consistent results (between the two mis results) using volpathmis, however these results do not look correct. Both images look dimmer, and on both the volume and the light (it can be noticed that the light intensity should be (1, 1, 1), but on image it is observed to be ($\frac{2}{3}$, $\frac{2}{3}$, $\frac{2}{3}$) approximately, similarly elsewhere), which is not consistent with the analytical result. Is there something fundamentally different about mis in volpath that might cause this behavior? Or are there more modifications required on the scene given that I only modified the line of integrator:
<default name="integrator" value="volpathmis" />

I have attached my results on volpathmis here, would you help me check if you observe similar behavior:
mis_results.zip

One "hack" to "fix" it is to apply a $\frac{3}{2}$ scale to each pixel of the incorrect images, and then consistent and correct results could be obtained. Though I am not sure why this is happening. Thanks for any help if there is something obvious I missed.

[diiigle]

(Without having looked at the scene files)
In mitsuba 0.5, volpath did not support spectrally-varying sigma_t at all (AFAIK it used the max value by default). In subsequent versions this improved, however still not with good sampling strategies. This is documented behaviour:

This integrator does not implement good sampling strategies to render participating media with a spectrally varying extinction coefficient. For these cases, it is better to use the more advanced volumetric path tracer with spectral MIS, which will produce in a significantly less noisy rendered image.

Some pointers to look at:
volpath.cpp, search for channel to see the uniform spectral sampling strategy, other channels are weighted by the pdf in one channel (L232). A search for is_spectral highlights all the code that affects your bug.