A Taxonomy for Rendering Engines

Summary

It's time to grow up. One of the main objectives behind the REAC conference we (Steve, Stephanie, Natalya, Michael and I) organize now every year is to share the kind of "hard won" lessons on the craft of real-time rendering that are currently not possible to learn outside working in our industry for decades (and possibly, on many different projects and companies...). Gamedevs and Computer Graphics people are a great community, we do share a lot when it comes to how things are made, we are proud of pushing the state of the art forward and we want others to know about it! It's undeniable that without this openness, we would not be able to produce the incredible technology we have today. But, in many ways, we are still a young industry, we love to talk about shiny things, not as much the "less glamorous" behind the scene decisions that most often make all of the difference. And because we are not used to doing this, we are not great at it! I was talking with someone (I'll ask them later if they want to appear by name) a few days ago about how they "hate" architecture talks, as most often are just showing how a given thing works - whilst not providing with the kind of context useful to evaluate if that solution would be good to consider. I fully agree! I think it will take us, as an industry, some time to understand how to best present these lessons. It's the difference between a lazy post about the "10 habits of successful CEOs" and an academic text that tries to develop a theory of management. Theories require assumptions, context, they need to be replicable, falsifiable. A good start would be to develop a taxonomy of real-time rendering engines. A language to describe the context. This is... normal, in all mature technologies. Let's think for example about databases. Nobody would say "this is how you make a database", that's such a vague statement. What kind of database? Relational, key-value, time-series, vector, graph, spatial, columnar? With what characteristics?...