Yes, I've explained earlier how exactly it worked before... Both approaches are not ideal ('cause of weak 3ds Max API), but the latter one properly reflects the 3ds Max ideology of working with gamma. And yes, one of the big problem - there is no way to set the gamma setting separately for material editor in 3ds Max, it just does not have this feature neither in user interface nor in plugins API. Or the 3ds Max must automatically calculate the material editor color pickers gamma, knowing the gamma of the rendered result (and accepting the fact it may be above 1.0) and the gamma set in its settings - the gamma of the color picker UI is calculated as easy as "Max gamma on the top of render-result gamma". Fixing this by 3ds Max developers would solve this last inconsistency between tonemapped render result and material editor color pickers.boris wrote:It looked like it worked but it was some kind of a fake and for sure not correct...
The main thing here is that 3ds Max does not imply that some renderer will produce already tonemapped result (looks like they think a user will only use 3ds Max Lookup Tables for that, on the top of always untonemapped result). Because of that it does not have the separate gamma setting for material editor. As a result - if the image produced by the renderer (and placed into the Max render buffer) has some gamma above 1.0 - it will always shown by 3ds Max user interface brighter than material editor color pickers. Because 3ds Max always shows these color pickers in gamma that is set in its gamma settings, but it always applies this same gamma on the top of the render buffer (which makes the render result looking brighter than the material editor color pickers if that buffer holds the render result with gamma above 1.0).
Having in 3ds Max the separate gamma setting for material editor color pickers or (more properly) automatic color picker gamma calculation (accepting the fact the render-result may have non-1.0 gamma) would solve anything.
