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]

[0] https://www.youtube.com/watch?v=j-A0mwsJRmk

> 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.

> 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.

> 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.

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?

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

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.

[dead]