It's a well-written and informative post, it deserves a little more praise than "does nothing in terms of educating readers".
What he is discussing is about aesthetics. There are two things at play here: the big studio business model relies on making blockbusters, so you pack together a few hundred devs and artists and try to pop out the biggest game you can. The other is that many devs are technically trained but not especially artistically educated. They have a limited understanding of lighting, color, framing a scene, etc.
Someone who has made some great criticisms of this as well as provided real solutions is Eskil Steenberg.
The article isn't very concise and is actually quite repetitive, it uses a bunch of jargon (without any description), and shifts blame around.
The topics are interesting and the opinions are there, but it certainly could be written better.
As a programmer who has done a small amount of work in graphics but hasn't worked in HDR rendering I have no idea what any of these are....
film LUT
color grading
post process LUT color grade
...but I could write the linked-to shader. So who is he helping?
> It alters between putting the blame on technical limitations and ignorance, so I would have liked to see a suggestion on how to address either of these.
Yes, I understand the acronyms, but they are being used as jargon, not in a instructive way.
If I were to talk about a web framework and say, "we've got our JSON files wrong and our package configs are cluttered, and don't get me started on the XML files," it's clear that it is metonymy [1].
Knowing that JSON is JavaScript Object Notation, the package.json is used for Node Package Manager, and that XML is a file format doesn't capture the feeling that a developer might have reading that sentence, and it doesn't instruct.
>>> It was Reinhard in years past, then it was Hable, now it’s ACES RRT. And it’s stop #1 on the train of Why does every game this year look exactly the goddamn same?
If the problem the author is facing is a gap between art skills and technical skills, then the post could be less angry and more informative about color theory or rendering technology, maybe bridging the needed skills.
If you were writing for an audience of people who work with web frameworks all the time, writing JSON and XML and whatever would be entirely reasonable.
Though if you look to the sidebar, you can see the author’s recent tweets:
> Tonight in "alarming discoveries" is that I went into my WP stats to find heavy traffic from Reddit. From r/pcgaming no less - blech.
> Practical consequence is that I'm going to have to write future entries from more basic principles, because this is getting out of hand.
> adjusting the color in an image, as you might do in Photoshop or whatever
Photoshop is a very basic tool for this. Color grading tools used in the industry are far more advanced than the options offered in PS, take a peek at Resolve (free).
I’m just defining a term, hence the “or whatever”.
But personally I find Photoshop to be more flexible and more capable than any of these film tools I’ve looked at, none of which seem to be capable of the kind of (very non-standard) workflow I use in Photoshop. Photoshop tools (layers, masks, adjustment layers [especially curves, and more recently full color lookup tables], blend modes) can be combined in very sophisticated ways which can be set up via a macro action, whereas most of these other tools are a bit more prescriptive. For example I can build my own “hue vs. hue” tool (from the Resolve marketing video) out of more basic Photoshop building blocks, and set up an action to pop one up with a keystroke. To be fair Photoshop also has piles of highly constrained single-purpose tools, most of which are outdated and relatively useless.
But none of these tools was ever designed with a user in mind who would think abstractly about building blocks and means of combination. More abstract and generic functional-boxes + arrows kind of interface could probably do better from a flexibility perspective, but can be a pain in the butt to use.
Someone with a color science, user interface design, and art background and a lot of time to experiment who was trying to make a tool for professionals could also certainly do a heck of a lot better. Most of the individual user interface components in these tools [including photoshop] are pretty uncreative and inflexible. Maybe this will be me in a few years when I have some more time, we’ll see.
Resolve specifically and PS are operating differently. Resolve's color correction is nodal-based, nodes stack by coefficients, not output (like layers generally do). The usual example to show this off is to drown the blacks in one node and pull them back up in the next, without any loss of detail, since Resolve combines the coefficients not the outputs of the transformations.
Resolve exactly lets you put your layers in graphs instead of have them linear. It also lets a later layer bring back detail that was removed in a previous layer, while Photoshop doesn't. Here's an example: https://youtu.be/YxUoW5_gMjQ
That video shows Resolve to be a pretty capable tool. (Can the nodes take custom user-specified logic in them, e.g. some GPU shader or the like?)
But everything shown in that video (other than motion tracking) can be done step for step equivalently in Photoshop, albeit some bits take some nonstandard combinations of tools. Some of it would probably be more convenient in PS to achieve via a different method.
I don’t exactly understand what the compositing order is of “parallel nodes”, but I’m quite convinced I could mimick the effect almost precisely given a technical description.
The nonlinear ordering you mention could be done using smart objects, but that can get annoying, so it’s usually easier in practice to just duplicate the layer (which breaks the link if you change something up the compositing chain later).
I think the audience is other games graphics programmers and technical artists who can be expected to understand all this terminology. As a game graphics programmer the article was written appropriately assuming I'm representative of his intended audience (which is implied by his use of 'we').
The article is intended for graphics engineers. All those terms are pretty fundamental and something I expect a graphics engineer working even ~6 months professionally to fully grasp.
What he is discussing is about aesthetics. There are two things at play here: the big studio business model relies on making blockbusters, so you pack together a few hundred devs and artists and try to pop out the biggest game you can. The other is that many devs are technically trained but not especially artistically educated. They have a limited understanding of lighting, color, framing a scene, etc.
Someone who has made some great criticisms of this as well as provided real solutions is Eskil Steenberg.