[Editor] Allow choosing "no tonemapping"

[hybridherbst]

Description

Modelviewer is pervasive on the web for 3D models, which is great!

But also, the default ACES transform has done quite some harm: I've seen numerous pipelines now tuned to "look right in model-viewer" which means that art departments are tuning colors and textures to kind of counter the effect of ACES, making it hard or impossible to switch to a better tonemapping (e.g. Commerce) after the fact.

One small step towards making that easier could be to allow choosing "no tonemapping" in the editor, to at least see the base colors of everything without ACES applied.

[elalish]

Since there is no such thing as "no tonemapping" (the closest is clamped, which also has strange hue skews), I went ahead and added the new Commerce tone mapper as an option in the editor already:

Does that suffice?

[hybridherbst]

I saw that, but I mean „colors as-is without additional curves“ which would be LinearToneMapping in three, and just clamping. This would ensure people have some way of seeing the same thing in their DCC and model-viewer.

[elalish]

What is DCC? I'm working on making an OCIO profile for commerce which should allow it to be applied in artist tools. Clamping is an extreme non-linear "additional curve" - a point I'm trying to help people understand the importance of. The purpose of the commerce tone mapper is exactly to create a minimally-invasive tone mapping function, one which is closer to base color than either ACES or clamped.

If you think the ACES hue skews are problematic, take a look at what clamped can do (clamped exposure sweep on the top, ACES on the bottom):

[hybridherbst]

DCC = Digital Content Creation, e.g. 3ds Max, Blender, Maya, Unity, ... anything where glTF can come from in this case. Could also be called "artist tools", yeah.

Usually people are working either with settings that are hard/impossible to replicate elsewhere (e.g. Filmic in Blender) or "no tonemapping" which at least allows them to see if the same model looks the same elsewhere (verifying their exports actually worked).

OCIO is not supported everywhere. Currently people mostly work "without tonemapping" in their DCC and then move the data out of it. Not being able to see the same thing is a problem :) I'm doing a lot of explaining that no, they shouldn't judge their glTF models in model-viewer because then they're desinging against ACES.

My ask here is not about the hue skews, it's about getting replicatable results (no matter if hue skews or not) in a time where OCIO is not supported everywhere and where most* people still don't really know what tonemapping is.

[elalish]

You and I are trying to solve the same problem for the industry, so this is great. I hear what you're saying, though I may not have every nuance yet. I'm concerned with this approach because if I add a "no tonemapping" / "clamped" option to MV (and expose it in the editor), I'm afraid that will encourage people to use that in production (many already are, assuming incorrectly that it preserves base color better). I'm not sure how useful replicatable results are if they don't match the desired production result. Artists need to be able to work with the same tone mapping as production, but production needs tone mapping that preserves color better than "clamped". My proposal is Commerce tone mapping with an OCIO profile, all the way from DCC to MV. What workflow do you envision for the end-to-end? And what steps along the way?

[donmccurdy]

I would note that preventing users from disabling tone mapping ("clamping") may have at least one negative side effect – unlit scenes cannot properly use model-viewer-effects. I know model-viewer disables tone mapping for unlit materials, but this doesn't work in a post-processed pipeline.

On the three.js side I think we should aim to help users feel comfortable defining their own tone mappers, there isn't just one best tone mapper. Whether custom tone mapping fits well into MV I am not sure. Several DCCs already support AgX so I'm interested in making that available – it's a better default than ACES, though I can't compare to the proposed Commerce tone mapper.

[hybridherbst]

My personal end-to-end-flow is

• trying to get people to understand that they need matching tonemapping everywhere
• and that they also understand that the fallback – for the sadly still 90% of cases where matching end-to-end tonemapping is impossible – is ensuring that they are using "no tonemapping" everywhere
• use exposure sliders to judge things going over one.
• test often in the target platform, no matter which of the above they're using, if they actually care about the result.

Little bit unrelated, but I've got Commerce, a three.js AgX implementation and ACES in our still-experimental viewer: https://viewer.needle.tools/; happy to upload that AgX code somewhere.

I personally like AgX a lot – like Commerce, it requires somewhat stronger environment lighting, for AgX even stronger I think. From my initial testing "commerce people" are likely not going to be happy with AgX when they just look at a comparison instead of reviewing the image they see as a picture. Most scenes "feel" better and more realistic with AgX, but in comparison under the same IBL they are somewhat dull. This matches Blender 4.x AgX implementation by the way.

[elalish]

I'm going to call this fixed by #4615, since we now have AgX support as well. While it avoids some of the weirdest problems with ACES, the dullness is a real problem for commerce - way too many colors are unreachable. I've also updated my commerce tone mapper, which has improved both its contrast and color accuracy. I think that's still the way to go for e-commerce, but it'll take some effort to make it smooth in the artist workflows.

[elalish]

If you still like "no tonemapping", take a look at my Glitch, where you can drag and drop your own GLBs and HDRs and pick all the tone mappers. Check out the crazy color shifts you get with Linear/clamped/none on the metallic highlights especially. It's even weirder and worse than ACES.

[hybridherbst]

Personally I still think it's important to be able to "see the data" without application-specific tonemapping on top, but I understand your rationale for not adding it. Tonemapping implementations never match 1:1 between applications, AgX is no exception.