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