←back to thread

Distributed Ray-Tracing

(www.4rknova.com)
36 points ibobev | 3 comments | 16 Oct 25 21:32 UTC | HN request time: 0.001s | source
Show context
amelius ◴[22 Oct 25 13:08 UTC] No.45668543[source]▶
Perhaps someone can help me with this. I was doing some experimentation with lenses and PBTR v4. This was going great, I was able to model the projection of an object through a lens onto a surface quite well. However, now I want to simulate doublets: lenses which consist of two parts so with two materials. I don't know how to model this in PBTR. It seems that it is not possible to have a shape (lens) touch more than one other material.

> PBRT's MediumInterface system can only represent a single "inside" medium and a single "outside" medium per shape. If a shape physically touches multiple different media (for example, a glass sphere sitting at the interface between water and air), PBRT cannot directly represent this configuration.

I think this is kind of odd for a renderer which is otherwise quite capable. Can anyone explain why this is the case, and how I can work around this limitation?

replies(2): >>45668863 #>>45669331 #
1. tylermw ◴[22 Oct 25 14:01 UTC] No.45669331[source]▶
There is a way to model this type of situation for watertight dielectrics with interface tracking: you assign each material a priority value, and a transition between materials occurs when entering that material only if it has a higher priority than your current material. Yining Karl Li has a great article about it:

https://blog.yiningkarlli.com/2019/05/nested-dielectrics.htm...

that inspired me to add the feature to my renderer (rayrender.net).

The downside to priority tracking (and possibly why PBRT does not include it) is it introduces a lots of overhead to ray traversal due to each ray needing to track a priority list. Modern raytracers use packets of rays for GPU/SIMD operations, and thus minimizing the ray size is extremely important to maximize throughput and minimize cache misses.

replies(2): >>45669721 #>>45673471 #
2. amelius ◴[22 Oct 25 14:32 UTC] No.45669721[source]▶
Wow, the problem is more involved than I (a simple user) realized ...

Maybe I have to broaden my search for a raytracer. What would be my best bet for correctly simulating multi-material lenses (so with physical correctness), in Linux (open source), preferably with GPU support?

(By the way, as a user I'd be happy to give up even a factor of 10 of performance if the resulting rendering was 100% physically accurate)

3. mattpharr ◴[22 Oct 25 18:48 UTC] No.45673471[source]▶
Minimizing the ray payload for GPU was definitely part of why we didn't add that. (Though it does pain me sometimes that we don't have it in there.)

And, PBR being a textbook, we do save some things for exercises and I believe that is one of them; I think it's a nice project.

A final reason is book length: we generally don't add features that aren't described in the book and we're about at the page limit, length wise. So to add this, we'd have to cut something else...