Hacker News Reader

Comment by magicalhippo | Hacker News Reader

Pbrt was made to teach how to write a physically-based ray tracer. As such it is not focused on raw speed, and the ability to extend it easily is important.

Implementing better mesh handling is an excellent exercise for the reader.

As an aside, the book "Physically Based Rendering", which is the source of pbrt, is _by far_ the best programming book I've ever read.

So many books spend a lot of time on trivial stuff, while others dive into the difficult theory and math but doesn't show how to translate it into code.

PBR goes through the difficult theory and math in detail while also showing how to implement it in code, explaining potential pitfalls and tricks along the way. And it does so in an elegant and easy to understand way.

And if you got some questions, the authors answers questions in a Google Group.

View on HN

Turns out Matt Pharr, the author of this article, is also the author of this book.

Yes, thanks for pointing that out. I so easily forget to mention things that seem obvious to me :(

Ahah, not good for a programmer :D

I'm joking, thanks for suggesting that book, I don't know much about this stuff but i might actually read it!

Tell me about it :P

Since a physically-based ray tracer involves a lot of different theory and math, it can be quite interesting even if your not in it for the actual ray tracing. For example there's sampling low-discrepancy sequences, kd-trees and other bounding volumes, color representation and conversion etc.

I haven't criticized the code or the merits of programmers, but it looks like a case of "if all you have is a hammer, everything looks like a nail". Sorry if I'm wrong. I've met many programmers who just can't think outside OOP model.

FWIW, in the Physically Based Rendering book, we also discuss data-oriented design (https://en.wikipedia.org/wiki/Data-oriented_design) as a potential alternative implementation approach, which would be the most natural non-OOP way to go about this.

As noted in other comments, this was a case where the pedagogical goals of the system outweighed maximizing performance.

I've been playing around with a slightly different non-OO approach. The use of sum and product types taken more from functional programming. You can see some of the results here: <https://github.com/KayEss/AnimRay/tree/feature/animation/ani... (needs to be that branch for anything interesting right now).

It's really incomplete, and I have had hardly any time to work on it over the many years that it's been around, but the general idea is to type construction to determine the aspects that a scene actually uses and let the compiler sort out what to do about it.

For example, the depth count attached to a ray doesn't appear until it hits a reflective surface so there is no overhead if the scene doesn't need it. As you can probably imagine the template errors can be obscene :)

The next thing would be to constexpr everything so that the scene could be built up in the compiler, I guess ideally in parts and then combined by the linker. I think it'll be really fun to try that with this Moana scene, but don't expect the compilers or linkers will survive let alone the tracer

EDIT to say, I really love your book. I feel hugely inspired every time I look at it, which unfortunately means I can't look too often as I don't have the time to play with these things as much as I'd like.

Reply on news.ycombinator.com