Graphics is not an academic body of knowledge as such. It's a bag of tricks developed over 50 years, going hand in hand with industrial hardware development.
There _is_ deep and rich academic framework around the subject, but I think to understand "why this" you need to program to understand the problem space since it's not really anything you could derive from first principles. I mean you get the rendering equation and so on, but the graphics knowledge portrayed in the article comes from understanding the three pillars of real time rendering.
It's about delicate interaction between human visual system (how to fool it), algorithms, and the hardware capabilities.
In general you need to program graphics, not read it. I mean I'm in the "reading" category myself and the people who've focused on programming are much better than myself.
Real time rendering by Akenine-Möller, Haines et all is the standard entry reference. Now in it's fourth edition. It's really good and dense.
If someone wants a simple recipe how to learn real time graphics alone in their cellar, nowadays I would recommend getting Real Time Rendering and going through https://learnopengl.com/.
After that you just continue... continue ... continue.
There are some people who understand everything about the topic instantly intuitively apparently but that's very, very unique. For the rest of us it's a life long adventure facing our own limitations and trying to get better, one program after another.
Speaking as graphics/geometry dev for 20 years now.
Absolutely! In a way it's really cool you can go to ACM archives and start reading from something like
https://dl.acm.org/doi/10.1145/563858.563893
(Blinn, Models of light reflection for computer synthesized pictures)
and then track forward from there.
But the developments in the field have mostly been motivated by "I think this looks better than that" followed by a formal mathematical model. The aesthetic aspect has been far more impactful in driving development than drive for technical precision as such.
"Does it look good" is far more important metric than displaying graphs with error bars.
This is not to say the field _isn't_ extremely technical. It is! But the main motivation for all developments has been aesthetic - hence it's IMHO almost as hard to learn computer graphics by just reading about it as it would be to learn something like academic oil painting just reading about it.
"In the center of the display, images reconstructed from filters with random values of (B, C) were displayed ... Nine expert observers took
part and over 500 samples were taken...It would not be credible to suggest that a single ideal parameter pair can be deduced from subjective testing"
So they basically did kernel fitting based on what looks good - while the theory of the kernel function itself was more technically motivated.
There _is_ deep and rich academic framework around the subject, but I think to understand "why this" you need to program to understand the problem space since it's not really anything you could derive from first principles. I mean you get the rendering equation and so on, but the graphics knowledge portrayed in the article comes from understanding the three pillars of real time rendering.
It's about delicate interaction between human visual system (how to fool it), algorithms, and the hardware capabilities.
In general you need to program graphics, not read it. I mean I'm in the "reading" category myself and the people who've focused on programming are much better than myself.
Real time rendering by Akenine-Möller, Haines et all is the standard entry reference. Now in it's fourth edition. It's really good and dense.
If someone wants a simple recipe how to learn real time graphics alone in their cellar, nowadays I would recommend getting Real Time Rendering and going through https://learnopengl.com/.
After that you just continue... continue ... continue.
There are some people who understand everything about the topic instantly intuitively apparently but that's very, very unique. For the rest of us it's a life long adventure facing our own limitations and trying to get better, one program after another.
Speaking as graphics/geometry dev for 20 years now.