3 ms·

Each triangle is an object with two v-tables? That's gross indeed.

barrkel 8y ago
OO is not the approach I'd use for fast and memory efficient manipulations of lots of geometric primitives, indeed. Although I don't know the specifics.
magicalhippo 8y ago
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.
- weavie 8y ago
  Turns out Matt Pharr, the author of this article, is also the author of this book.
  - magicalhippo 8y ago
    Yes, thanks for pointing that out. I so easily forget to mention things that seem obvious to me :(
    - Micoloth 8y ago
      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!
      - magicalhippo 8y ago
        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.
- red75prime 8y ago
  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.
  - mattpharr 8y ago
    FWIW, in the Physically Based Rendering book, we also discuss data-oriented design (https://en.wikipedia.org/wiki/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 8y ago
      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/animray> 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.
ur-whale 8y ago
Even one would be gross.

OO is not the approach I'd use for fast and memory efficient manipulations of lots of geometric primitives, indeed. Although I don't know the specifics.

magicalhippo 8y ago

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.

weavie 8y ago
Turns out Matt Pharr, the author of this article, is also the author of this book.
- magicalhippo 8y ago
  Yes, thanks for pointing that out. I so easily forget to mention things that seem obvious to me :(
  - Micoloth 8y ago
    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!
    - magicalhippo 8y ago
      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.
red75prime 8y ago
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.
- mattpharr 8y ago
  FWIW, in the Physically Based Rendering book, we also discuss data-oriented design (https://en.wikipedia.org/wiki/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 8y ago
    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/animray> 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.

ur-whale 8y ago

Even one would be gross.