←back to thread

Distributed Ray-Tracing

(www.4rknova.com)
36 points ibobev | 1 comments | | HN request time: 0s | source
Show context
amelius ◴[] 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 #
tylermw ◴[] 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 #
1. mattpharr ◴[] 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...