Yes, in rendering when we talk about “diffuse” reflection we implicitly mean fuzzy reflections due to light penetrating the material and exiting a small distance away from the entry point (less than a pixel far)
The term subsurface scattering is used for light that exits further away (more than a pixel) like in simulations of human skin
However that part of the article isn’t clear enough and warrants a rewrite
It looks like a good model for lower incident angles but begins to diverse at higher angles. There's also one huge caveat - it relates the GGX model to real world ground glass. Obviously it's important to compare like to like. However, very few materials in the real world are ground glass.
Looking around my surroundings, I see painted drywall, wood, paper, plastics, and textiles. It would seemingly be a mistake to assume each of these materials behaved optically like ground glass. I hope that similar measurements are carried out on other materials.
I wrote everything from scratch in javascript and webgl. You can check the entire source code of the article here: https://imadr.me/pbr/main.js
Beaware though, it's a 8000+ lines of code js file that is very badly organized, it's by no mean a reference for good quality code.
However I find writing everything by hand easier in the long term than using already existing libraries for example.
The code includes all the math functions, mesh primitive generation, shaders and even a sketchy text renderer using sdf fonts.
If I had to make it again I would use typescript, type errors were the biggest source of bugs.
How long did it take you to write that code / this article?
I'm a big fan of zero-dependency code (or at the very least with any dependency vendored/hosted locally), it means this page will still work and look as it does today in 25 years time.
I don't know if TS runs natively in browsers yet, but v8 / NodeJS does support it (just strips off Typescript specific tokens).
I took me about 3 months working on it on and off, it amounts to about 3 weeks of full time work. For my other projects I'm just writing everything to a single typescript file and compiling it with tsc, works like a charm and zero dependencies!
Love it! For typescript, esbuild has been my favorite tool for turning typescript into browser-readable js, and then I check type errors separately using the ide plugin.
Thanks for the constructive criticism! A few points I'd like to discuss:
Let's suppose the aim of the article was indeed to learn PBR from first principles, what would it look like? Quantum electrodynamics?
I think there is merit in exploring different physical models for fun and scientific curiosity (like I mentioned in the first chapter).
I (personally) feel that it's boring to just dump equations like Snell's law without exploring the deeper meaning behind it. I also feel that it's easier to grasp if you have some surface knowledge about more complex physical models.
I agree however that I probably made many mistakes since I didn't study physics, I'd appreciate any feedback to improve that.
I dislike "Physically Based Rendering: From Theory To Implementation", I personally think that the literate programming approach of the book is way too confusing and disorganized. I prefer the SIGGRAPH talk by Naty Hoffman[0]
> Let's suppose the aim of the article was indeed to learn PBR from first principles, what would it look like?
Well given the title I at least expected the article to explain or derive things like why and how metals and their alloys have the color (wavelenght-dependent complex index of refraction) that they do, why and how say quartz crystals have different colors, birefringence, fluorescence (makes T-shirts appear extra bright) etc.
And there is no mention of the recording process. Are we simulating good old film with its silver crystals of various sizes? Different film stock is known to have very different looks due to their chemistry.
Or a digital camera sensor with its quantum and thermal noise, bayer filter and a rolling shutter causing those funny-looking propeller pictures?
Not knocking the article, but given the title it fell well short of my expectations going in. That is, I was wondering how on earth anyone had managed to do all that.
Yes I didn't have time to write a chapter about camera sensors, the human retina, and the whole image formation process. I'll definitely expand on this later on.
> I dislike "Physically Based Rendering: From Theory To Implementation", I personally think that the literate programming approach of the book is way too confusing and disorganized.
Interesting. Personally it's by far the best programming related book I've read. I didn't mind the literal programming, and I loved how it dove fairly deep into the math and physics but also into the details of implementing the math.
The latter being important as there are can be so many gotchas when implementing math.
I agree with OP and find the literal programming in that book incredibly distracting and annoying. I prefer the theory up front and the code later. "Ray Tracing From the Ground Up" does a much better job in my opinion (although it also only covers a fraction of the topics in the PBR book.)
> Let's suppose the aim of the article was indeed to learn PBR from first principles, what would it look like? Quantum electrodynamics?
Something like that, yes. A truly from-first-principles treatment of photon-surface interactions would involve an extremely deep dive into quantum numbers, molecular orbitals, solid state physics and crystal lattices (which are metals), including a discussion about how electron waves superpose to produce various conduction/valence bands with various band gaps, and then discuss how photons interact with these bands.
I might be a stupid question but how hard would that be to explain, and to understand?
If you had to teach an alien from another universe physically based rendering:
- In an exhaustive manner and,
- You're only allowed to explain something if it derives from something more "fundamental" until we reach the most comprehensive physical models we have
How hard would be the math behind it for example? Because realistically in my article the hardest piece of math is a very basic integral
Could I for example start reading these Feynman lectures[0] and get up to speed on everything there is to know about photon-surface interaction?
The raw mathematics isn't the hardest; most of this is settled by the end of the second year of undergraduate physics—things like Taylor series, ODEs, PDEs, special functions, a bit of linear algebra (no proofs needed, just use the results); perhaps complex analysis which leads to Fourier transforms and all. Maybe a treatment of tensors.
The issue is the sheer complexity of micro systems, and the unintuitive nature of going deeper than 'EM wave reflects off electrons'.
Consider metal-light interaction. Exactly how does a visible-light EM wave interact with a conduction band of superposed free valence electrons? How does the massive superposition elevate each valence electron up energy levels? Why do only metallic and semi-metallic crystals have no band gap? Why are electrons filled in the order of s, p, d, f, g, h orbitals? Why do these orbitals have these shapes? Why are electrons so much less massive than protons and neutrons? Why does the nucleus not tear itself apart since it only contains positive and neutral particles? Why are protons and neutrons made of three quarks each, and how does the strong interaction appear? Why are the three quarks' mass defect so much more than the individual masses of each quark? How does the mass-energy equivalence appear? Why does an accelerating electric charge produce and interact with a magnetic field, and thus emit EM radiation? What is mass, charge, and magnetism in the first place?
Each question is more 'first principles' than the last, and the answers get more complex. In these questions we have explored everything from classical EM, to solid state physics, to quantum electro- and chromodynamics, to particle physics and the Standard Model, and are now verging on special and general relativity.
> The raw mathematics isn't the hardest; most of this is settled by the end of the second year of undergraduate physics—things like Taylor series, ODEs, PDEs, special functions, a bit of linear algebra (no proofs needed, just use the results); perhaps complex analysis which leads to Fourier transforms and all. Maybe a treatment of tensors.
It sounds like the OP is saying you could tackle the article if you just know a little high school calculus and trig, and you're here saying that you need years of post-secondary mathematical education. I think you're making his case that he's dramatically simplified understanding how to compute these things for someone who doesn't have a post-secondary education.
no, the first principles could be reduced to the domain that you're working in, which in this case would be non-relativistic physical optics. that is, the description of electromagnetic waves using maxwells equations. these could be considered true first principles for this problem domain.
you don't need to go to quantum physics or general relativity for everything, that would mean that a description from first principles is impossible for any field that doesn't (yet) directly connect there like biology, psychology, you name it. which may be technically correct but clearly not in the spirit of the idea.
in general this article has a quite surface level focus and narrow scope. there isn't even a description how the most common physical rendering primitive ever, a ray of light, is related to electromagnetic waves in mathematical terms. the article is not very mathematical in general which is disappointing.
Sure! And I appreciate the response. I hope I didn't come off as too mean, it can be hard to find that balance in text, especially while criticizing. I really do not want to discourage you, and I think you should keep going. Don't let mistakes stop you.
> Let's suppose the aim of the article was indeed to learn PBR from first principles, what would it look like?
I think you shouldn't go that route, but the most honest answer I can give is that such a beginning doesn't exist in physics knowledge. You could start with something like String Theory, Supergravity, Loop Quantum Gravity, or some other proposition for a TOE. Physicists are still on the search for first principles.
All this is well beyond my expertise btw, despite having worked in optics. If you want to see some of this complexity, but at a higher level, I'd highly recommend picking up Jackson's Elecrtodynamics book. That's that canonical E&M book for graduate level physics, Griffith's is the canonical version for undergraduate (Junior/Senior year). Both are very well written. I also really like Fowles's "Introduction to Modern Optics", and it is probably somewhere in between (I read it after Griffiths).
I am in full agreement with you that having deep knowledge makes a lot of more shallow topics (and even many other deep topics) far easier to grasp. But depth takes time and it is tricky to get people to follow deep dives. I'm not trying to discourage you here, I actually do encourage going deep, but just noting how this is a tricky line and that's why it is often avoided. Don't just jump into the deepend. Either wade people in or the best option is to lead them in so they don't even recognize they're going deep until they're already there.
> I dislike <PBR Book>, I personally think that the literate programming approach of the book is way too confusing and disorganized
This is very understandable and I think something you should hone in on and likely where you can make something very successful. But an important thing to note about his SIGGRAPH talk is his audience. His talk is aimed at people who are experts in computer graphics, but likely computer scientists and not physicists. So his audience knows a fair amount of rendering to begin with and can already turn much of what's being said into the code already. But if you listen to it again I think you'll pick up on where he mentions they'll ignore a bunch of things[0]. There's no shame in ignoring some things and working your way forward. I actually like what Hoffman said at 22:25 "and we know that's an error. But we'll live with it for now." That's the mark of good scientific and engineering thinking: acknowledge errors and assumptions, triage, but move forward. A common mistake looks similar, dismissing those errors as inconsequential. That's putting them in the trash rather than tabling for later. Everything is flawed, so the most important thing is keeping track of those flaws, least we have to do extra work to rediscover them.
So, who is your audience?
This is just my opinion, so you have to be the real judge; but I think you should leverage your non-expertise. One of the hard things when teaching is that once you understand something you quickly forget how difficult it was to learn those things. We quickly go from "what the fuck does any of this mean" to "well that's trivial" lol. You referenced Feynman in your blog post and most important thing I learned from him is one of the best tools for learning is teaching (I've given way too many lectures to my poor cat lol). It forces you to answer a lot more questions, ones you normally would table and eventually forget about. But at your stage it means you have an advantage, that the topics you are struggling with and have overcome are much more fresh. When learning things we often learn from multiple sources (you yourself shared overlapping material), and that's because multiple perspectives give us lots of benefits. But at this point, don't try to be a physicist. If you want to work towards that direction, great! If you don't, that's okay too. But let your voice speak from where you are now.
Reading your blog post and poking through others, there's a "you" that's clear in there. Lean into it, because it is good. I like your attention to detail. Like in your Ray Marching post how you just color code everything. Not everyone is going to like that, but I appreciate it and find it very intuitive. I'm a huge fan of color coding equations myself and make heavy use of LaTeX's annotate-equations package when I make slides.
But I think looking at this post in isolation the biggest part to me is that it is unclear where you're going. This is a problem I suffer from a lot in early drafts. An advisor once gave me some great advice that works really well for any formal communication. First, tell "them" what you're going to tell them, then tell them, then tell them what you told them. It's dumb, but it helps. This is your intro, it is your hook. I think there's places for these ideas but early on they almost feel disconnected. This is really hard to get right and way too easy to overthink. I think I can help with a question: "What is your thesis?"/"What is your main goal?" Is it "learn how our human eyes capture light and how our brains interpret it as visual information"? Or is it "Physically based rendering from first principles". Or even "learn how to create physically realistic renderings of various materials." These are not exactly the same thing. When I'm struggling with this problem it is because I have too much to say. So my process is to create a "vomit draft" where I just get all the things out and it's going to be a mess and not in the right order. But once out of my head they are easier to put together and in the right order. After your vomit draft check your alignment. What is most important and what can be saved? What's the most bare bones version of what you need to communicate? Build out of that.
I do really think there's a good blog post in here and I can see a lot of elements that suggest a good series may come. So I do really encourage you to keep going. Look at what people are saying they like and what they dislike. But also make sure to not take them too literally. Sometimes when we complain about one thing we don't know our issue is something else. What I'm saying is don't write someone else's perfect post, write your post, but find best how to communicate what you want. I know I've said a lot, and I haven't exactly answered all your questions, but I hope this helps.
[0] There's a side note here that I think is actually more important than it appears. But the thing is that there's a weird relationship between computation and accuracy. I like to explain this looking at a Taylor Series as an example. Our first order approximation is usually easy to calculate and can usually get us a pretty good approximation (not always true btw). Usually much more than 50% accurate. Second order is much more computationally intensive and it'll significantly increase your accuracy but not as much as before. The thing is accuracy converges much like a log-like curve (or S-curve) while computation increases exponentially. So you need to make these trade-offs between computational feasibility and accuracy. The most important part is keeping track of your error. Now, the universe itself is simple and the computational requirements for it are lower than it takes us to simulate but there's a much deeper conversation about this that revolves around emergence. (The "way too short" version is there's islands of computational reducibility) But the main point here is this is why you should typically avoid going too low quickly, because you end up introducing too much complexity all at once and the simplicity of it all is masked by this complexity.
Again, thanks for the thorough and constructive answer, it doesn't come off as mean, on the contrary I appreciate it :)
I strongly agree that teaching is absolutely the best tool for learning. I wrote this article in part because I got inspired by the "What I cannot create, I do not understand" quote by Feynman.
I agree that the article is disorganized, and it's not only a feeling: it literally is! I had to shuffle around parts of the chapter about radiometry because I couldn't find the right place for it. I was kind of in a rush because I submitted this article as part of 3blue1brown's summer of math exposition.
I find it interesting that between the 3rd and 4th edition of pbr book, chapters have been reorganized too. Monte Carlo Integration has been moved to an earlier chapter before radiometry, reflection models..etc which I found confusing, but I suppose the authors had a good reason to do that.
So I have a lot to learn on how to improve my writing and how to organize ideas into something coherent.
Keep with it! And that reorganization between editions is a good reminder that things don't have to be perfect and can always be improved upon. We call these things "soft skills" but I think we've made a terrible mistake in implying that communicating is easy lol. Often it can be harder than the work itself! I think you got a good attitude and it'll take you far. So good luck on your submission! And FWIW, Monte Carlo Integration confused the hell out of me until I figured out how beautifully simplistic it is. If it hasn't clicked, keep with it. It eventually will.
> But the thing is that there's a weird relationship between computation and accuracy. I like to explain this looking at a Taylor Series as an example. Our first order approximation is usually easy to calculate and can usually get us a pretty good approximation (not always true btw). Usually much more than 50% accurate. Second order is much more computationally intensive and it'll significantly increase your accuracy but not as much as before. The thing is accuracy converges much like a log-like curve (or S-curve) while computation increases exponentially.
This is something I've been thinking about a lot lately that I'd like to better understand. Are there any examples in physics or machine learning that you can think of that have more specific figures?
I'm not sure what you exactly mean. But if you are interested in the problem in general I think any book on computational physics will make you quickly face this constraint. There's a reason people love first order methods like Euler but why second or higher order methods are needed in other situations. Or maybe you could look at second order gradient descent methods as they apply to machine learning (add "Hessian" to your search). You'll see there's some tradeoffs involved. And let's just note that through first order methods alone you may not be able to even reach the same optima that second order methods can. Or you could dig into approximation theory.
But I think first I'd just do some Taylor or Fourier expansions of some basic functions. This can help you get a feel of what's going on and why this relationship holds. The Taylor expansion one should be really easy. Clearly the second derivative is more computationally intensive than the first, because in order to calculate the second derivative you have to also calculate the first, right?
Mind you there are functions where higher order derivatives are easier to calculate. For example, the 100th derivative of x is just as easy to calculate as the second. But these are not the classes of functions we're usually trying to approximate...
Touching on what you were saying about accuracy converging like a log-like curve while computation increases exponentially, do you have an example where increasing computational resources by ten times leads to, say, only a 20% improvement in accuracy?
What I said before is a bit handwavy so I want to clarify this first. If we make the assumption that there is something that's 100% accurate, I'm saying that your curve will typically make the most gains at the start and much less as at the end. There can be additional nuances in this when discussing the limitations of metrics but I'd table that for your current stage (it is an incredibly important topic, so make sure you come back to it. You just need some pre-reqs to get a lot out of it[0]).
So maybe a classic example of this is the infamous 80/20 rule. You can read about the Pareto Principle[1] which really stems from the Pareto Distribution, which is a form of a Power Distribution. If you're looking at the wiki page for the Pareto Distribution (or Power Law), you'll see the shapes I'm talking about.
A real life example of this is when you train a machine learning model. Let's take accuracy for just simplicity. Let's look at PyTorch's example on using Tensorboard since that includes a plot at the very end[2]. Their metric is loss, which in this case is the inverse accuracy. So Accuracy is 0-100 (0 to 1) where higher is better, loss is just 1-accuracy, so 0 means perfectly accurate. From 0-2k iterations, they went from 1 to 0.6 (a 0.4 gain). Then at 4k iterations they are at a 0.4 loss (a 0.2 gain over 2k iterations). You see how this continues? It is converging towards a loss of 0.2 (accuracy = 80%). This is exactly what I'm talking about. Look at your improvements over some delta (in our case loss/(2k iterations)). It's a second order effect here, meaning it's non-linear.
This nonlinearity shows up everywhere. Going back to the 80/20 rule, it is often applied to coding. 80% of code is written using 20% of the time, but 20% of the code is written with 80% of the time. This should make sense as there are different bottlenecks. We'd be naive to just measure by lines of code (see [0]). A lot of time is spent on debugging, right? And mostly debugging just a few key areas. The reason this is true can derive from a simple fact: not all lines of code are equally as important.
So the other example I mentioned in the previous comment is Fourier Series[3]. That wiki has some nice visualizations and you'll be able to grasp what I'm talking about from them. Pay close attention to that first figure, the middle plot (image 2/17). These are different order approximations to a square wave. Might be hard to see, but as the more complex the wave (higher order) the better approximation you get to that square wave. Pay close attention to the calculations. Do a few yourself! How much work goes into calculating each term? Or rather, each order of approximation. I think you'll get the sense pretty quickly here that every higher order calculation requires you to also do the lower order ones.
As a more realistic example I am the creator of a state of the art image generator (I won't say which one to maintain some anonymity). When training my model the score quickly improves and really only a small amount of time. This training run took approximately 2 weeks wall time (what the clock says, not the GPU). Most of the improvement (via metric) took place in the first 6hrs. I was >90% of the way to my final score within the first day. If you look at the loss function in full, almost everything looks flat. But if you window it to exclude the first 24hrs, the shape reappears! There's a fractal nature to this (Power Distribution!). To put numbers to this, my whole run took 1M iterations and my final score was ~4.0. My first measurement was at 5k and was 180. My next measurement was at 25k and at 26. 15@50k, 9@100k, 6.8@200k, 5@500k, and so on. This is very normal and expected. (Then there's the complexity of [0]. Visually the images improved too. At 5k they were meaningless blobs. By 100k they had the general desired shape and even some detail appeared. By 500k most images resembled my target. At 800k I had SOTA but had could tell things were off. By 1M I thought there was a huge visual improvement from 800k but this is all down to subtle details and there are no measurements that can accurately reflect this)
I am happy to answer more but you're also asking about a complex topic with a lot of depth. One I absolutely love, but just giving you a warning :)
[0] The super short version is no matter what measurement you take you are using a proxy. Even a ruler is a proxy for a meter. It isn't exact. When measuring you approximate the measurement of the ruler which is an approximation of the measurement of a meter. This case is typically very well aligned so the fact that it is a proxy doesn't matter much (if you include your uncertainties). This isn't so simple when you move to more complex metrics like every single one you see in ML. Even something like "accuracy" is not super well defined. Go through a simple dataset like CIFAR-10 and you'll find some errors in labels. You'll also find some more things to think about ;) Table this for now but keep it in the back of your head and let it mature.
I developed this article on firefox desktop and tested it on safari ios, and here I was thinking my testing was exhaustive! I just hope it’s not some obscure webgl bug on android
And it shouldn't need to. Making (relatively) simple changes like checking-in fixed versions of dependencies in the code base and abstracting away core logic from the platform layer goes a long way. This works well for video games
I find with C/++ I have to compile to find warnings and errors, while with Rust I get more information automatically due to the modern type and linking systems. As a result I compile Rust significantly less times which is a massive speed increase.
Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience
Not the GP, but the biggest one is dependency management. Cargo is just extremely good.
As for the language tooling itself, static and runtime analyzers in C and C++ (and these are table stakes at this point) do not come close to the level of accuracy of the Rust compiler. If you care about writing unsafe code, Miri is orders of magnitude better at detecting UB than any runtime analyzer I've seen for C and C++.
Strictly speaking, Cargo isn't part of the Rust programming language itself. Cargo is a layer on top of Rust, and you can use the Rust compiler completely independently of Cargo. I think bazel, for example, can compile and handle dependencies without Cargo.
I am yet to use async in c++, but I did work on a multi threaded c++ project for a few years
Rust is nicer for async and MT than c++ in every way. I am pretty sure.
But it's still mid. If you use Rust async aggressively you will struggle with the borrow checker and the architecture results of channel hell.
If you follow the "one control thread that does everything and never blocks" you can get far, but the language does not give you much help in doing that style neatly.
I have never used Go. I love a lot of Go projects like Forgejo and SyncThing. Maybe Go solved async. Rust did not. C++ did not even add good tagged unions yet.
Go (at least before generics) was really annoying to use.
Doing anything concurrent in Go is also really annoying (be that async or with threads), because everything is mutable. Not just by default but always. So anything shared is very dangerous.
Async rust is amazing as long as you only mix in one more hard concept. Be it traits, generics or whatever. You can confidently write and refactor heavily multithreaded code without being deathly afraid of race conditions etc. and it is extremely empowering.
The problem comes when trying to write async generic traits in a multithreaded environment.
Then just throwing stuff at the wall and hoping something sticks will quickly lead you into despair.
Don't you think a sufficiently advanced model will end up emulating what normal 3D engines already do mathematically? At least for the rendering part, I don't see you can "compress" the meaning behind light interaction without ending up with a somewhat latent representation of the rendering equation
If I am not mistaken, we are already past that. The pixel, or token, gets probability-predicted in real time. The complete, shaded pixel, as you will, gets computed ‘at once’ instead of layers of simulation. That’s the LLM’s core mechanism.
If the mechanism allows for predicting how the next pixel will look like, which includes the lighting equation, then there is no need anymore for a light simulation.
Would also like to know how Genie works. Maybe some parts get indeed already simulated in a hybrid approach.
The model has multiple layers which are basically a giant non-linear equation to predict the final shaded pixel, I don't see how it's inherently difference from a shader outputing a pixel "at once".
Correct me if I'm wrong, but I don't see how you can simulate a PBR pixel without doing ANY pbr computation whatsoever.
For example one could imagine a very simple program computing sin(x), or a giant multi-layered model that does the same, wouldn't it just be a latent, more-or-less compressed version of sin(x)?
in this case I assume it would be taken from motion / pixels of actual trees blowing in the wind. Which does serve up the challenge of like how does dust blow on a hypothetical gameworld alien planet?
- 3d primitives (arrows, hemisphere)
- billboarded text rendering
- mouse interaction/canvas rendering that works for multiple scenes
It might be possible to vibe code but you’ll hit a wall of complexity really quick