Hacker News Reader

Comment by amelius | Hacker News Reader

Is the material description part of the language the same as in PBRT?

I'm asking because I had a lot of trouble trying to describe interfaces between materials, only to find out that what I wanted to do was not possible in PBRT without modifying the code. Apparently, in PBRT a material can only have one other material touching it. So, for example rendering a glass filled with water and ice is not possible without hacks. From a user's point of view this is a bit of a let-down, of course.

Context: https://news.ycombinator.com/item?id=45668543

View on HN

Nope, we made a complete high level Julia interface and I plan to have the Makie API be the main user facing scene description, which can be more descriptive than pbrt I think!

Ok. Did you see this:

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

And I'm curious how you solve it.

Sorry, I was on my phone. This doesn't seem to be a problem of the description language, but rather how the integrator and materials work internally, so this works the same way in Julia currently. I do think though, that its more approachable to add experimental features like this in the Julia version. Would certainly be an interesting project! I do want to over time get further away from the pbrt-v4 architecture and get to something much more modular and easy to extend. I feel like the overlaps resolve should happen at scene creation time, to not have an expensive priority stack at raytracing time - then it would be just a matter of better tracking the media at boundary crossing. But haven't really thought this through of course ;)

I think it was a problem with the language as well as how they handle it internally. It was basically the algorithm that dictates how the language works, and consequently there was no way to have one material touch more than one other material. But I might misremember.

Anyway, I'm looking at this from the user's perspective. I wanted to do some physics-based ray-tracing with lenses and pbrt is what I ended up trying. As such, I really needed the multi-material aspect to work correctly. Also, it would be nice to be able to describe surfaces using a z=f(x,y) kind of formulation, or a way to place a hook in the renderer.

It's definitely an architectural problem as well. I do wonder if we could extend that though, without too much trouble for the general architecture - after all, the material does not necessarily need to represent all the outside materials and instead the ray only needs to be able to go from one medium to another. I'm happy to chat about possible extensions in that direction, although to be fair I wont have much time in the next weeks to sit down on anything like this. But, I do really hope that this can become a playground for ray tracing experiments in general!

I think maybe the easiest way to tackle the problem is to have the language describe surfaces instead of solid objects, and let every surface have a normal and two materials. This might be the most natural representation for a ray tracer.

We are working on surface support in Makie to some degree: https://github.com/MakieOrg/Makie.jl/pull/5516 If we get funding, we may also support stuff like NURBS. Obviously, once that gets merged, we do want to also add Raytracing support for it ;)

Reply on news.ycombinator.com