Physically Based Rendering: From Theory to Implementation
pbr-book.org
pbr-book.org
There are applications (Zemax, for example) that are used to design optical systems (lens arrangements for cameras, etc). These applications are eye-wateringly expensive-- like similar in pricing to top-class EDA software licenses.
With the abundance GPU's and modern UI's, I wonder how much work would be involved for someone to make optical design software that blows away the old tools. It would be ray-tracing, but with interesting complications like accounting for polarization, diffraction, scattering, fluorescence, media effects beyond refraction like like birefringence and stuff like Kerr and Pockels, etc.
I do research in a subfield of optics called nonimaging optics (optics for energy transfer, e.g. solar concentrators or lighting systems). We typically use these optical design applications, and your observations are absolutely correct. Make some optical design software that uses GPUs for raytracing, reverse-mode autodiff for optimization, sprinkle in some other modern techniques you may blow these older tools out of the water.
I am hoping to be able to get some projects going in this direction (feel free to reach out if anyone are interested).
PS: I help organize an academic conference my subfield of optics. We run a design competition this year [1,2]. Would be super cool if someone submits a design that they made by drawing inspiration from modern computer graphics tools (maybe using Mitsuba 3, by one of the authors of this book?), instead of using our classical applications in the field.
[1] https://news.ycombinator.com/item?id=42609892
[2] https://nonimaging-conference.org/competition-2025/upload/
This does sound interesting! I’ve just finished a Masters degree, also in non-imaging optics (in my case oceanographic lidar systems). I have experience in raytracing for optical simulation, though not quite in the same sense as optical design software. How should I contact you to learn more?
Looking forward to some weekend paper reading.
Maybe in some time we also do an online workshop about it.
PBRT 3rd edition actually has a great section on the topic but it's one of the parts that wasn't implemented for the GPU (by the authors, anyway): https://pbr-book.org/3ed-2018/Camera_Models/Realistic_Camera...
- There aren't that many people willing to pay for such software, but those that do *really* need it, and will pay quite a bit (passing that cost on of course).
- The technical domain knowledge needed to do it properly is a barrier to many
- It needs to be pretty robust
I think the main way this changes is when someone has already spend the money in an adjacent area, and realized "huh, with a little effort here we could probably eat X's lunch"
Beyond that you at most get toy systems from enthusiasts and grad students (same group?) ...
From academic side, I've found the work of Steinberg in this area extremely impressive. They are pushing the frontier to include more wave-optical phenomenon in the rendering. E.g. https://ssteinberg.xyz/2023/03/27/rtplt/
I remember he had a lot of problems with the pinhole camera because the small size of the pinhole meant that rays had trouble going into the box, so to speak, and thus he needed an insane amount of rays.
Depending on use case, it already exists for gem cutters. We can simulate everything from RI to fluorescence excitation.
But the heavy-hitters in this field all seem to have very old-timey UI's and out-of-this-world pricing.
Meanwhile, raytracing for computer graphics on GPU's is soooo performant-- it makes me wonder how much work needs to be done to make the equivalent of KiCAD for optical design.
I completely agree that whatever simulation they have can be easily done better with modern GPUs.
For you. Anyone doing design and manufacturing of optics will not blink at paying for software.
We're only at the leading edge of this, too.
This paper from Disney is what kicked off the movement https://disneyanimation.com/publications/physically-based-sh...
As sibling pointed out, physically based rendering precedes “PBR” by a looong time and goes much, much deeper than “I put a metalness map in my shader”
https://books.google.com/ngrams/graph?content=physically+bas...
(Tweak the patameters to end in 1995 to see what I mean.)
I poked around papers from siggraph 1986-1988 and the closest I could find to the use of the term was a panel discussion in 1998:
"STEVE FEINER: Our second speaker will be Professor Don Greenberg. ... Don's group has been at the forefront of computer graphics for some twenty years now, most recently doing pioneering work on physically based modeling and radiosity approaches." ( https://dl.acm.org/doi/10.1145/1402242.1402254 )
I did run across a book using the term in 1994, "The State of the Art in Physically-based Rendering and its Impact on Future Applications" (to your point using the dash between physically and rendered): https://link.springer.com/chapter/10.1007/978-3-642-57963-9_...
The term around then was basically a catch-all for raytracing, radiosity and BRDF-oriented rendering techniques as opposed to the triangle-texture-shading techniques. The former took way more compute-per-pixel/"visual impact" than the latter and thus was done in software while the latter was starting to fit into hardware transistor counts available at the time. There were a variety of sytheses of the various techniques, so some kind of shorthand was definitely needed.
My guess, being mildly involved in the field in the mid-90s, is that while one could have in 1987 said "physics-based" rendering, the researchers, some of whom actually trained in physics, knew that even the techniques they were exploring (raytracing, radiosity, BRDF, light fields) were approximations of physics from the physics and optics literature and not actually grounded in the cycle of hypothesis and experimentation that would constitute "physics-based rendering".
Later the term came to have more specific connotations. One good summary of it from a practical point of view when this book came out was: https://news.ycombinator.com/item?id=38110448
https://books.google.com/books?id=Vw1DAQAAIAAJ&q=%22physical...
I see the term without the dash used in 1994 in Eurographics Computer Forum "A Theoretical Framework for Physically Based Rendering": https://www.cs.rpi.edu/~cutler/classes/advancedgraphics/S11/...
In 1994 siggraph paper by Greg Ward, https://radsite.lbl.gov/radiance/papers/sg94.1/Siggraph1994a..., the term is explicitly described in a footnote:
'The term "physically-based rendering" is used throughout the paper to refer to rendering techniques based on physical principles of light behavior for local and global illumination.'
I defer of course to mattpharr if he cares to comment! :)
Physics-based? Reality-based? Physically-derived?
"X-based" to me is equivalent with "based on X". Physics-based = based on physics, evidence-based = based on evidence, values-based = based on values; all perfectly fine.
Physically based feels correct in a sentence like "Our company is physically based in New York but we operate world-wide". But what does the "physically based" in "physically based rendering" mean?
But I'm not a native speaker, what do I know.
https://www.goodreads.com/review/list/21394355-william-adams...
I'd be glad to know of any I missed, or of a similar resource for websites.
There's often a lot of details that matter when implementing something efficiently and well which the theory either hides or is a result of our hardware limitations like floating point numbers.
Almost all other programming books I've read cover either the theory in detail and gloss over the implementation details, or goes into a lot of implementation stuff but only cover the easy parts and doesn't give you a good indication of how to deal with the advanced stuff.
So, any other books out there that you've read that is like PBR?
but the algorithm for the theory looks approximately like this to me
(ijfio) $@ * foiew(qwdrg) awep2-2lahl [1]
[1]: e.g. https://pbr-book.org/4ed/Introduction/Photorealistic_Renderi...
Here's the thing though: Mathematics isn't code! The symbols we use to form, say, equations, are not the "code" of a paper or a proof. Unless you yourself are an expert at the domain covered by the paper, you're unlikely to be able to piece together what the paper wants to convey from the equations alone. That's because mathematics is written down by humans for humans, and is almost always conveyed as prose, and the equations (or diagrams or whatever) are merely part of that text. It is way easier to read source code for a computer program because, by definition, that is all the computer has to work with. The recipient of a mathematical text is a human with mathematical training and experience.
Don't interpret this as gatekeeping. Just as a hint that math isn't code, and is not intended to be code (barring math written as actual code for proof assistants, of course, but that's a tiny minority).
I'll try keep an open mind and read more the surrounding content.
That said, there is a syntactic language, which many equations use, and they seem to vary or be presented differently. The big S is one, the meaning of `|` which is probably not "OR" etc. I wish there would be a cheat sheet of sorts, but I feel it would be death by a thousand paper cuts with 300 standards of doing things(?)
Light leaving a point in a direction = light emitted from that point in that direction (zero if we aren't talking about a light bulb or something) plus all light reflected by that point in that direction.
In pseudocode, or any programming language, I'm right there with you.
And it really isn't that bad in most cases, and isn't unlike how we learnt that "int 10h" is how you change graphics modes[1] in DOS back in the days.
The "big S" is an integral, which is in most cases essentially a for-loop but for continuous values rather than discrete values. You integrate over a domain, like how you can for-loop over a range or discrete collection.
The domain is written here as just a collection of continuous values S^2, so like a for-in loop, though it can also be from and to specific values in which case the lower bound is written subscript and the upper bound superscript.
Similar to how you have a loop variable in a for-loop you need an integration variable. Due to reasons this is written with a small "d" in front, so in this case "dω_i" means we're integration (looping) over ω_i. It's customary to write it either immediately after the integral sign or at the end of the thing you're integrating over (the loop body).
However dω_i serves a purpose, as unlike a regular discrete for-loop, integrals can be, lets say, uneven, and the "d" term serves to compensate for that.
The only other special thing is the use of the absolute function, written as |cosθ_i|, which returns the absolute value of cosθ_i, the cosine of the angle θ_i. Here θ_i is defined earlier in the book as the vertical angle of ω_i relative to the surface normal at the point in question, which can be calculated using the dot product.
So in programmer-like terms, it reads a bit like this in pseudo-code.
function L_o(p, ω_o):
integral_value = 0
for ω_i in S^2 do
θ_i = dot(w_i, n)
integral_value += f(p, ω_o, ω_i) * L_i(p, ω_i) * abs(cos(θ_i)) * dω_i
return L_e(p, ω_o) + integral_value
What's special here is that unlike a normal for-loop, in math the changes in ω_i, represented by dω_i, are infinitesimally small. But in practice you can actually implement a lot of integrals by assuming the changes are small but finite[2].
Anyway, this wasn't meant as a full explanation of integrals and such, but just an attempt to show that it's not all gobbledygook.
I've wanted to add this capability to Solvespace for a while. I did my own implementation with the Fresnel term and it looked OK, but I want something "standard" and correct.
Filament is extremely well documented: https://google.github.io/filament/Filament.html
glTF's PBR stuff is also very well documented and aimed at realtime usage: https://www.khronos.org/gltf/pbr/
OpenPBR is a newer, much more expensive BRDF with a reference implementation written in MaterialX that iirc can compile to glsl https://academysoftwarefoundation.github.io/OpenPBR
Pick one of the BRDFs, add IBL https://bruop.github.io/ibl, and you'll get decent results for visualization applications.
https://media.disneyanimation.com/uploads/production/publica...
I don't think there is a standard as such that would dominate the industry. It's all approximations to give artists parameters to tweak.
IMHO - Being an ex professional CAD person I think PBR is the wrong visual style for most cad though. The main point of shading is to improve the perception of shape and part isolation there. Traditional airbrush based engineering illustration styles are much better reference. So something like Gooch with depth buffer unsharp masking IMHO would be much much more appropriate.
That is some excellent feedback. I like that our current simple Snells law shader doesn't add specular highlights and can do flat shading by turning off all but the ambient light. I had never heard of "Gooch" and I don't recommend searching for it without "Gooch in the context of rendering". That looks interesting and we already have code to draw the silhouette edges.
I do think adding a PBR based Fresnel component with a backlight gives a similar but less sharp delineation of edges of objects, but it tends toward white right on the edge.
While people like a good PBR render, I agree that in CAD the objective of the rendering is to clearly convey the geometry AND the sketching tools and entities the user is manipulating.
It won't be plug and play since you'd have to pull out the shaders and make them work in your app, but the implementation supports quite a few material variants. The PBR shader implementation starts in source/Renderer/shaders/pbr.frag
If you want a standard I've go with OpenPBR, it is well documented and looks nice. Just skip the extra layers to begin with(fuzz/coat etc).
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.