Understanding participating media

[OliviaBorgstrom]

Hi, I'm currently working on expanding the particle tracer integrator to support participating media, as I need the functionality for a research project I am a part of. To understand how to do this I have been looking at the volumetric path tracer and how it deals with volumes. I'm still confused about what part of the volumetric path tracer implementation makes it able to do volumes which is lacking in the ptracer module. Any kind of pointers to help me understand this would be helpful. Thanks!

[njroussel]

Hi @OliviaBorgstrom

This entire section of the volpath integrator is relevant for volumetric path tracing. It is estimating the solution of the radiative transfer equation.
It makes use of this internal sample_emitter method. This method connects some interaction point to an emitter in your scene and estimates the contribution along that segment. Because it builds a "direct" connection, it assumes that any interaction along that segment does not perturb the ray direciton.

I'd recommend having a look at chapters 11 and 14 of PBRT. They'll give you a great overview of this problem.

[OliviaBorgstrom]

Hi, I just had a question about this line from the VolPath tracer.

dr::masked(result, active_e) += throughput * phase_val * emitted *
                                                    mis_weight(ds.pdf, dr::select(ds.delta, 0.f, phase_pdf));

Is it correct to assume, for my adaption to the ptracer integrator, that this line is equivalent to this:

throughput *= phase_val * emitted * mis_weight(ds.pdf, dr::select(ds.delta, 0.f, phase_pdf));

[OliviaBorgstrom]

Thanks a lot for your helpful reply. The PBRT link is very useful, I'll have a read of that.

One other thing that has confused me while looking through the code for volpath vs ptracer is the way each of them output to the image block - and how this might affect my implementation. In the ptracer integrator it uses the 'connect_sensor' function to put contributions from a singular ray onto the image block. This is called with every loop inside of the 'trace_light_ray' function. Whereas volpath seems to accumulate the values to put onto the image block in the 'result' variable and puts them on the block all at once. (Correct me if i'm wrong)

Am I right in thinking that if I update this loop inside of the 'trace_light_ray' function to include contributions from the medium - in a similar way to volpath does - and keep the connect_sensor functionality i.e splatting each ray to the image block one by one, that it should produce the functionality that I want. Or is there a greater purpose that I am missing to the result variable in volpath which wouldn't be captured with this approach.

Thanks again for all the help.

[njroussel]

Am I right in thinking that if I update this loop inside of the 'trace_light_ray' function to include contributions from the medium - in a similar way to volpath does - and keep the connect_sensor functionality i.e splatting each ray to the image block one by one, that it should produce the functionality that I want.

You are correct, this is what you should implement.
As you said in the previous paragraph, the result variable gets splat on the block outside of the sample loop: it's done in the render_sample function. The reason for this is because only the render_sample function is aware of the 2D coordinate at which to splat this value. Whereas in the ptracer, every time a connection is made, the integrator knows exactly the 2D position on the sensor's film where the value should be accumulated.

[OliviaBorgstrom]

That makes sense, thanks!