mattpharr

Not just for software, but more generally for technology that influences the movie industry: https://www.oscars.org/sci-tech

Minimizing the ray payload for GPU was definitely part of why we didn't add that. (Though it does pain me sometimes that we don't have it in there.)

And, PBR being a textbook, we do save some things for exercises and I believe that is one of them; I think it's a nice project.

A final reason is book length: we generally don't add features that aren't described in the book and we're about at the page limit, length wise. So to add this, we'd have to cut something else...

How would one link to a physical object?

If this is what you’re asking: there are (perhaps too discreet) links at the bottom of each page to Amazon and MIT Press to purchase the physical book.

In the 4th edition, there's no support for RGB rendering--it's always and only spectral.

And admittedly the spectral rendering option in earlier editions wasn't great. We didn't always correctly distinguish between illuminants and reflectances, used a fixed binning of wavelength ranges (vs stochastically sampling wavelengths), and had a fine-but-not-state-of-the-art RGB -> Spectrum conversion algorithm. All of that is much better / state of the art in the 4th edition.

I love the Watt and Watt "Advanced Animation and Rendering Techniques" book as well; it was IMHO the best book on those topics in its time.

The physical book was published 6 months ago, and per agreement with the publisher, the contents are now freely available online as well.

The book's blurb:

Photorealistic computer graphics are ubiquitous in today's world, widely used in movies and video games as well as product design and architecture. Physically based approaches to rendering, where an accurate modeling of the physics of light scattering is at the heart of image synthesis, offer both visual realism and predictability. Now in a comprehensively updated new edition, this best-selling computer graphics textbook sets the standard for physically based rendering in the industry and the field.

Physically Based Rendering describes both the mathematical theory behind a modern photorealistic rendering system and its practical implementation. A method known as literate programming combines human-readable documentation and source code into a single reference that is specifically designed to aid comprehension. The book's leading-edge algorithms, software, and ideas—including new material on GPU ray tracing—equip the reader to design and employ a full-featured rendering system capable of creating stunning imagery. This essential text represents the future of real-time graphics.

The author team of Matt Pharr, Greg Humphreys, and Pat Hanrahan garnered a 2014 Academy Award for Scientific and Technical Achievement from the Academy of Motion Picture Arts and Sciences based on impact the first and second editions of the book had on how movies are made. The Academy called the book a “widely adopted practical roadmap for most physically based shading and lighting systems used in film production.”

Of the book, Donald Knuth wrote “This book has deservedly won an Academy Award. I believe it should also be nominated for a Pulitzer Prize.”

Also related as far as the programming model: C* on Connection Machines and the C dialect used on MasPar systems in the 1980s.

There is some discussion in the ispc paper: https://pharr.org/matt/assets/ispc.pdf

I would expect a shader could do a credible job of emulating all of these.

The key is that it is necessary to know the coherence of the light arriving at the surface in order for a shader to accurately model reflection. (See Figure 13 in the paper for an example that shows how this matters.) Otherwise a shader would have to make up a guess about the light's coherence.

The main contribution of the paper is a much more efficient approach than was known before for finding light's coherence, even in the presence of complex light transport (multiple reflections, etc), and one that further allows the application of traditional ray-optics computer graphics techniques for sampling light paths through the scene. (For example, previously if one wanted to track coherence, it was necessary to sample light paths starting from the light sources rather than from the camera, as is done in path tracing.)

The irony of such a post on a website with the domain name “y combinator”…

Rejection sampling is not a good choice here.

First, the cost is 2 FMAs * the cost of generating 2 random numbers * the number of rejection sampling iterations. On average, you reject (4-pi)/4 ~= 0.25 of the time. However, if you're running on a GPU in a warp (or the equivalent) of 32 threads, then you pay the cost of the maximum number of rejections over all the threads.

The bigger issue is that a direct mapping from [0,1]^2 to the disk, as is described in this tweet, if you have well-distributed uniform samples in [0,1]^2, you get well-distributed samples on the disk. Thus, stratified or low discrepancy samples in [0,1]^2 end up being well distributed on the disk. In turn, this generally gives benefits in terms of error with Monte Carlo integration of functions over the disk.

FWIW that algorithm for uniform floating-point sampling in [0,1] is actually originally due to: Walker, Alastair J. “Fast generation of uniformly distributed pseudorandom numbers with floating-point representation.” Electronics Letters 10 (1974): 533-534.

Are there alternative tools that focus on rewriting code to maximise performance while keeping error below some configurable bound?

There are! See followup work by @pavpanchekha and others on "Pherbie", which finds a set of Pareto-optimal rewritings of a program so that it's possible to trade-off error and performance: https://ztatlock.net/pubs/2021-arith-pherbie/paper.pdf.

I'd be happy to pay the author (note, not donate*) for this corpus online.

Lucky for you, we have a Patreon. Looking forward to your support!

Yeah, about that prediction... Progress continues, but Fall 2021 is more likely for an online edition and then printed copies in the first half of 2022. (I suppose we should update the website.)

Extra pedantic: no, because "physically" ends in "-ly". :-)

(Rule 3 here: https://www.grammarbook.com/punctuation/hyphens.asp)

It’s good for linear algebra with long vectors and large matrices, but SIMD is useful for many other things besides that

The main goal in ispc's design was to support SPMD (single program multiple data) programming, which is more general than pure SIMD. Handling the relatively easy cases of (dense) linear algebra that are easily expressed in SIMD wasn't a focus as it's pretty easy to do in other ways.

Rather, ispc is focused on making it easy to write code with divergent control flow over the vector lanes. This is especially painful to do in intrinsics, especially in the presence of nested divergent control flow. If you don't have that, you might as well use explicit SIMD, though perhaps via something like Eigen in order to avoid all of the ugliness of manual use of intrinsics.

I’m pretty sure manually written SSE2 or AVX2 code (inner loop doing _mm_cmpeq_epi8 and _mm_sub_epi8, outer one doing _mm_sad_epu8 and _mm_add_epi64)

ispc is focused on 32-byte datatypes, so I'm sure that is true. I suspect it would be a more pleasant experience than intrinsics for a reduction operation of that sort over 32-bit datatypes, however.

No, the actual publisher (Elsevier) printed a batch of terrible quality books. This led to our ending our relationship with them. We are in the midst of finding a new publisher for the 4th edition; not repeating that disaster is of great importance to us...

(PBRT author, here)

pbrt is the Physically Based Ray Tracer that is described in the Physically Based Rendering book.

So -20480 works out to be 0xAFFF.

My trusty copy of "What's Where in the Apple", which includes a catalog of where everything is in memory, says that the routine to write the VTOC from its in-memory buffer to disk starts at $AFF8.

The VTOC is the volume table of contents (https://en.wikipedia.org/wiki/Talk%3AApple_DOS#Volume_Table_...), so calling into the middle of that presumably ends up overwriting the VTOC with junk, which would indeed make the disk useless.

Workin' on it. :-)

Note that the third edition came out roughly 5 years ago now, not 10.

Thanks! Also fixed and will also go live in a little bit.

Nice find!

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!

It's pretty much a big hack.

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.

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.

Correct: it generates a surface light field from a set of RGBZ images that sample the scene surfaces. In turn, that's simplified into a set of alpha-textured quads that very accurately represent the scene from a specified headbox.

View frustum culling wouldn't have been enough to render this stuff (https://www.roadtovr.com/preview-google-seurat-ilm-xlab-mobi...) in VR on a mobile GPU. :-)

Post on nice interactions with the LLVM team coming up in a few days. :-)

IMHO, the problem with the device model is that it imposes a bunch of unnecessary overhead on the programmer for cases where memory is shared and you're running on the same processor.

If I just want to call a function, pass some parameters, have it do some work, and get a result, things like OpenCL require all sorts of annoying boilerplate just to pass parameter values, map buffers, copy results out, etc. Sure it's all straightforward to write, but it's friction, and it's annoying.

Regarding clGetProgramInfo: does that return actual native executable code or IR? (I assume it's free to do either but in practice returns the latter, and that there's the usual "final driver compiler" between that code and what runs on the hardware, but I don't know.) An issue with that is that you can't be sure of what will run on users' systems; you're at the mercy of the version of the driver they've got installed.

Original ispc author here.

I have no idea how performance compares to OpenCL on CPUs today, but it was in the same ballpark a few years ago.

The big difference is that OpenCL imposes a device model which is (IMHO) ridiculous if you're running everything on the CPU. With ispc, you have:

* Ahead-of-time compilation to binary code (no driver compiler in the way, so you can look at the ASM and know that's what will run.)

* Straightforward interop with C/C++ code: it compiles to the C ABI, so going from whatever other language to ispc code is just a function call. (Similarly, ispc can call out to C code.)

* Straightforward interop with application data structures: you can (and should!) pass pointers back and forth between C/C++ code and ispc code, do computation using the same data structures, etc.

All three of those are much uglier / more painful with the device model.

No worries!

The publishing industry has gotten worse in a lot of ways in the ~10 years since we did the first edition. The whole for-profit academic journals thing makes me sad in general, etc.

However, it's also impressive how much work how many people put in to publish a book (illustrators, proof-readers, copy editors, professional layout, etc., etc.). For a specialist book like PBR that sells ~1500 copies a year, no one involved is making a ton of money from the process including, as far as I can figure, the publisher.

Even though the most important reason I've done my part of that work is to try to spread knowledge as widely as possible, that all does make me want to do my small part to discourage piracy. :-)

Hi, Kefka.

I'm the author of the book.

Could you please not post links to pirated versions of it on HN?

Thanks, Matt