[mattpharr]

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.

[KayEss]

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.