Expose HDR tonemapping operator as a PP Component

[rzkid]

For?

S&Box

What can't you do?

Previously, in the before times, there was a postprocessing editor with many nice color management features, however the coolest feature of all was the ability to define your own tonemap curve (within certain limitations).

Everything changed when the fire nation attacked and removed the postprocessing editor, turning many of it's features into separate PP components, and hard-locking Hable as the tonemap.

Which by itself is not bad, Hable operator is a good bare minimum, however a lot of engines allow you to just swap it out with whatever the user desires: two flavors of ACES, like five flavors of Reinhard, Hable (again), Uchimura, Lottes, AGx, and many more, the opportunities are endless.

How would you like it to work?

Have a PP component that is rendered in correct order (tonemapping is usually applied after all HDR PP but before UI/LDR PP, details differ per every implementation ever, no idea how S2 does it) and has a selection box thingie to select a .shader file, which is the user's preferred tonemap

You can still keep Hable as the default (or as example .shader) by having the component override "the engine tonemap", or just finally letting go and having nothing by default (many valve CS2 maps actually have no tonemap, not even hable SOMEHOW).

What have you tried?

There is a default .vpost file somewhere within the S&Box installation folder, however modifying it within the project folder doesn't register the file and compile it, and even then, it wouldn't be used by anything and therefore not go into effect. Plus I can't exactly curve out ACES with Hable forumla (I tried).

Additional context

NOTE: By saying "tonemapping operator" I mean remapping HDR values into SDR range, and NOT the autoexposure feature of already existing "tonemapping" PP component, which is a unfortunate naming scheme that comes from valve's weird naming choices since 2005 :( (no values are being remapped, all is done is giving the exposure multiplier a clamp range, I mean this is technically remapping but the wrong kind)

[rzkid]

I have played around with S&Box almost daily (key word "almost") since posting this request and have been discovering more and more information that make the OP look like a joke that isn't based in reality. This is a third-ish attempt at writing a follow up, because every discovery about the rendering pipeline and the current S&Box API kept obsoleting my proposals and I kept coming up with something else.

In a current post-process system the order of each effect is dictated not by component order on a camera (probably the first assumption of everyone), but by a number in the post-process renderhook. That means, for the effects you don't have access the code to, you dont know in what order they are in (postprocess_standard_p2.shader could be on the render order of 50, 1000, or 2, and you cant know which). The situation is better with the inside-shader order, since you just put the things in the order you want (and there are sources to know what happens).

Also, the tonemap is not only for the game, but you are also looking at HDR rendering in various tools like ModelDoc/Material Editor/etc and the non-play-mode scene editor. Hard to achieve visual parity with just a component (unless I'm wrong).

The proposed option in the OP is not as simple as it could be, due to how slightly convoluted the vanilla effects setup is (and they are too good to not use, why make your own effects if there's already a perfectly working sharpen or film grain or bloom etc.), so asking a user to code a post process shader from nothing to drag & drop it onto a component that renders it in the incorrect order (or order unknown to the user) is not cool. Bad experience, ok result.

There are two better options from this point:

1. Less customizability, more convenient There is a great open source tool that has millions of users, and it allows to change the tonemapper from a specific selection: Blender. You can go into the color management settings and select which tonemapper you want (or none at all), and it works correctly all the time, no issues, however you can't add new ones or change any of the existing ones, which is fine if you just want a good tonemap. However if you want customize or pick something specific, you really can't. You can keep Hable this way, providing it as a default option, and also defaulting to it if the component is not present on the camera.

2. More customizability, less convenient You could go the postprocess_standard_p1-2-3.shader route, and just have a shader included with the rest of the shaders, which has the tonemap code, you can change in any way you want. Instead of a component for handling it, it's just hardcoded as a renderhook stage (something like cc.AddHookPreTonemap/cc.AddHookAfterTonemap, or just signal in some way which of the existing stages are pre or post tonemap, to not add any more stages, a wiki entry perhaps). And with this you can ship Hable as the default one, once again breaking nothing.

I am willing to provide ethically sourced tonemap code for ACES and AgX, converted to S&Box Shader API; Including some minimal tweaks of my own (if needed).