In section 2.9.1 Quaternions, 4th paragraph reads as if it's missing an equation for the second representation of a quaternion:
A quaternion can be represented as a quadruple [EQ present] or as [EQ missing] , where is an imaginary 3-vector and is the real part. We will use both representations interchangeably in this section.
This is what it looks like for me:In general, you can send errata/bugs to authors@pbrt.org, but we got this one. :-)
It looks like an equation that MathJax wasn't happy with. I've got it fixed now and will include that fix in a push to the site in a little bit.
If you want to be listed as something other than "OnACoffeeBreak" in the errata credits, send me an email (matt@pharr.org).
Thanks again!
The image viewer works brilliantly and the renders are looking gorgeous. Looking forward to spending some hours with this on my iPad later.
Your road map says:
> We plan to release updated versions of the book roughly once a year, starting a year or so from now.
Out of curiosity, do you guys still plan to release new print editions?
I still buy physical books rather than e-books, but I always thought that hyperlinks were a great part of a reading experience as well.
Just a remark. When I first read the title, I was interested in the approximations you use because you emphasize physics so much in your book and your title. I read the preface and found a suspicious sentence.
When configured to do so, pbrt can compute images that are physically correct; they accurately reflect the lighting as it would be in a real-world version of the scene.
That is not correct. You use a phenomenological model for the light-matter interaction and approximate the effects of light with raytracing. That still produces (almost) photo realistic images for our eyes, but is not "physically correct". A paragraph on the limitations of technology could be worthwhile.
It does not simulate wave-optical effects, polarization, fluorescence, and phosphorescence. Some of them are easy to add (e.g. polarization), others such as wave optics are very challenging to solve in a fully general setting and would make the resulting system impractical to use.
However, that's not the whole story: even when simulating the underlying optics meticulously, a rendering of plane is not going to look photorealistic. Some detail must also go into modeling of the input, which is beyond the scope of the book (though Section 10.6 talks a bit about creating detail with noise functions).
Honestly curious, since as a graphics person and not a physicist, I’ve been under the impression that most of our “physically based” rendering framework these days can be derived from, explained by, or validated against first principles, and that only some of the reflectance functions we use might be described as “phenomenological” (and we might call those “hacky”). And as @wjakob said, there are certainly optical effects we don’t normally see, and don’t spend time computing.
Is it possible to have phenomenological models that are correct? The word means the model hasn’t been derived from first principles, but it doesn’t mean the model is wrong... right?
Personally, I think of the term “physically correct” within the context of computer graphics history. It’s not a technical term, and its meaning historically is referring to what came before now, and maybe not as much of a strict literal absolute as your interpretation(?). The 80’s and 90’s were full of fabulous graphics tricks that are even less physically correct than what we have now. Video games still have lots of them too.
Calling our newer techniques “physically correct” is perhaps kinda like how we call our TVs now “high definition”, or our colors “high dynamic range”. They’re not “high” in any absolute sense of the word, they’re just higher than before. In 10 or 20 years, what we call “high definition” today is probably going to feel like pretty low definition.
What PBR people are doing is to imagine the matter at small scale looks like a patchwork of many small walls (perfect reflectance or ballistic transport), and assume that light and matter behave and interact the same way in a macroscopic setting, which is further simplified to Snell's law, neglecting all classical wave-like characteristics. Beyond that, obviously, all quantum mechanical effects are neglected (which aren't that exotic, for daily-life examples, think laser pointers or solar panels or crystals).
That is a far cry from an ab initio calculation and is, at best, a very incomplete toy model or cartoon description of light and matter interaction which might barely be enough to deceive human eye for most everyday objects.
E.g. it doesn't handle things like polarization, interference or fluorescence, assumes light is instantaneous, etc.
https://www.oscars.org/sci-tech/ceremonies/2014
>> To Matt Pharr, Greg Humphreys and Pat Hanrahan for their formalization and reference implementation of the concepts behind physically based rendering, as shared in their book Physically Based Rendering.
>> Physically based rendering has transformed computer graphics lighting by more accurately simulating materials and lights, allowing digital artists to focus on cinematography rather than the intricacies of rendering. First published in 2004, Physically Based Rendering is both a textbook and a complete source-code implementation that has provided a widely adopted practical roadmap for most physically based shading and lighting systems used in film production.
These will get you a quick overview and get something rendering. PBRT is a great follow up to really understand the physical underpinnings and get more into the theory of how to do things correctly and efficiently.
The book was originally written in TeX, with lots of macros on top. We hacked together a custom translator (~3k loc, written in golang) that parses the TeX and generates the site.
Then MathJax to render the equations, Bootstrap 4 for some navigation, and jeri.io for the interaction with images.
I had some plans to present some other such written-in-TeX-literate-programs in HTML; could you perhaps share somewhere your "big hack" that you used here (the translator, the javascript)? Totally ok if you don't want to :) Thanks,