V-Ray 3.30.03 + Max 2016 SP2: Phys. camera exposure control tone mapping not working

[LudvikKoutny]

Hi,

I've recently noticed that when using exposure control connected to new Max 2016 physical camera, Image control settings that affect tone mapping, such as highlight burn, midtones level and shadow crushing do not work. I originally assumed this is due to the V-Ray having it's own tone mapping controls, so it disregards those in the Phys. camera exposure control panel, and that those are there only for Mental Ray.

But then I noticed something very strange: same set of controls in Mental Ray's exposure control work just fine even in V-Ray. So now there is this ironic situation that while tone mapping controls of exposure control dedicated to Mental Ray work, tone mapping controls of new universal exposure control that's supposed to work with all renderers do not work.

To illustrate:
These settings seem to have no effect on output image whatsoever:


Where as these settings work with V-Ray just fine:

[^Lele^]

You missed one bit:
You're using per-camera exposure, so that's the intended behavior.

[LudvikKoutny]

While I appreciate your effort trying to prove me wrong again, I'd suggest to always do some practical testing first before coming to conclusions

A, It does not react regardless of if it's set to per-camera or global control.

B, If it did work the way you say, it would not make much sense, because these "Image control" tone mapping settings are not present anywhere in the physical camera UI, so switching to per-camera setting would make them completely inaccessible.

Here's a scene if you'd like to have fun with it: https://dl.dropboxusercontent.com/u/...osureCMBug.zip If you go crazy with the settings in "Image control" frame, you will see they have no effect on final image what so ever, whereas if you try to do the same with MR Photographic Exposure Control, everything will work just fine. (BTW just to avoid confusion, once you switch to MR Photographic Exposure Control, you want to enable Process BG and Environment maps in the same manner it's enabled in Phys. Camera Exposure Control.)

[^Lele^]

I was trying to help, based on what you posted, on a holiday, from my phone.
With the settings in the screenshot you posted, even with 2016 SP1, the global controls would have had no effect.
However, when using global exposure, with SP1 they work.
That much, i could do on the move.

I tested (tonight) with 2016 SP1 first for two reasons:
A) It's precisely the version i did all of the pre-release testing with. So that is what i needed to check first, without adding another variable to the mix (it may have broken between nightlies and release, but nope.).
B) Given the physical camera and the exposure controls are Autodesk, testing with SP1 first insured that if any issue is there in SP2, it's with Max rather than with V-Ray 3.3.

It's unfortunate that the controls you mentioned do not work with SP2 (I can confirm it.), but we really have nothing to do with them.
We have our own color mapping elsewhere, and you are right, i'd warmly suggest you stuck to those: i personally don't like the ones in the exposure control (nor the never-quite-linear behavior of them.), and that's why i always expose locally.
Further, you are right, they are inaccessible in the physical camera controls (it was developed by us for Autodesk, but it isn't ours to support anymore.), just like in the "old" VRayPhyscam: shutter speed, ISO and f-Stops are all that ever was available (besides the CM controls) to expose.

You're left with two choices, Max SP1 to enable those controls, or a CER to Autodesk.
(i wouldn't really mix and match with the mR exposure, i have no clue as to the unintended consequences. perhaps none. perhaps not.)

[LudvikKoutny]

The reason i find this so weird is that exact same set of controls in MR Photo Exposure Control do work with V-Ray just fine. So it's probably something that could be fixed from ChaosGroup side.

Another thing I found weird is that with MR Photo Exposure control, these tone mapping controls do affect every scene object, and background, if Process BG Environment is enabled, but they do not affect DomeLight if it's set to be visible. So you are stuck with this one specific light source type in the scene, that won't be affected by those controls no matter what. Workaround is to make it invisible, and instance it's map to the environment background slot.

Lastly, from my tests, setting Highlights to 1, Midtones to 1, and shadows to 0 should give you 100% linear output.

[^Lele^]

The reason i find this so weird is that exact same set of controls in MR Photo Exposure Control do work with V-Ray just fine. So it's probably something that could be fixed from ChaosGroup side.

That's why i tested with SP1 first, to then upgrade just max to sp2.
It really isn't ours anymore: http://help.autodesk.com/view/3DSMAX...A-E6D7812A78B0
You can still create VRay Physcams with maxscript, if you prefer.
In fact, the exposure controls as a whole are fine with the scanline renderer (it should return to me 0.5f, and it does, under normal and linear conditions, using the global mode with the curves set to linear), mR and V-Ray, but broken for iRay (it returns ~0.9),broken with iRay+ (0.129).
I just spoke with AD, and they confirmed you should log a defect to them (however, you won't get a reply until next week. They're all out of the office, right now.).

Another thing I found weird is that with MR Photo Exposure control, these tone mapping controls do affect every scene object, and background, if Process BG Environment is enabled, but they do not affect DomeLight if it's set to be visible. So you are stuck with this one specific light source type in the scene, that won't be affected by those controls no matter what. Workaround is to make it invisible, and instance it's map to the environment background slot.

Well, technically, the domelight is neither of the background, nor of environment map class, but a direct light so it shouldn't be affected by that particular checkbox, rather it should be affected by default.
Exposing through the camera works as intended.
Messy? I agree.
Hence me still sticking to the tried and tested per camera exposure.
I personally don't like this approach one bit, but we have no way, other than talking to AD, to influence it.
The physcam also has other bugs which are less apparent, and deal with the focusing.
I MUCH prefer the old physcam workflow, so i tendentially work with that, although treating the new physcam as the old V-Ray one works too (ie. doing away with the global exposure controls, and just expose per camera.).
I do not dare think of what would happen saving a 2016 file set up the way AD wants us to, as a previous Max version which didn't have either the new physcam nor the new exposure controls.
One up for the old Physcam, too.

Lastly, from my tests, setting Highlights to 1, Midtones to 1, and shadows to 0 should give you 100% linear output.

Precisely: defaults aren't linear, and the numbers to input make no sense: they aren't multipliers (or they'd have to be all at 1.0), and they aren't ranges. (or they'd be 1-0.5-0).
Further, i'd expect a linear graph to go from 0-1 in both X and Y, while the linear setup shows a plateau before half-way through the X: so what, from looking at the curve, does it compress my highlights down to 0.45 and clip thereafter? (it doesn't, ofc, but one needs a render to make sure.)
On top of it, there's a clear separation on the 0/0 between the line end and the baseline of the graph (which i'd interpret as a lift of the blacks, but ofc it isn't.)
With good peace of the basics of color correction.
One needs an 9.04 EV to get a normal exposure (ie. white 1.0 stays white 1.0) with the default physical scale: even more convolution and multipliers chasing multipliers.
We had no input on those, and can do nothing to change them.

[LudvikKoutny]

AFAIK the rumor was that new physical camera was closely co-developed with ChaosGroup, so I'd expect it to work well. Honestly, I can't stand the new camera either, as it's one of the worst user interfaces I have ever seen in my entire life. I use it often for almost a year now, and it's incredible to see such a bad user interface that UI layout won't get into your muscle memory even after using it for 9 months pretty much daily.

As for the Image control settings, here's how they work: Highlights parameter is pretty much identical to V-Ray's Reinhard burn value. 0 means completely compressed, 1 means completely linear. Midtones is sort of gamma/contrast thing. Lowering increases overall contrast all the way from shadows to highlights, increasing it does the opposite. It's a nice way to add contrast pop to your images. Shadows is just shadow crushing... to deepen and burn shadows a bit for artistic reasons. Sure this is usually done in post, but this is a nice way to at least preview it. What's most confusing about the image control parameter set is the curve.

I think the original intention was showcase how the curve looks across entire HDR range rather than 0-1 range, but it backfired miserably as most of the people, even experienced ones, will assume their setup does something a lot different, based on appearance of that curve.

Regarding defect submissions to Autodesk, I stopped quite while ago once I noticed they just print most of them on a toilet paper. I've logged so many of the in the past, yet mouse zooming in curve editor still does not work, new scene explorer still slows down viewport heavily, skin buttons on hierarchy panel still flicker for no reason even when max is completely idle, etc...

If you think it will change something, then feel free to log it. I kinda assumed report from ChaosGroup would have a lot more importance anyways, because you guys given up on your own PhysicalCam to be replaced with something that currently does not completely work.

And about DomeLight, I think it should just be affected by default. I wonder why there are so many DomeLight related bugs, be it the Matte bug, bug that caused it to work wrong with aerial perspective, now this. It feels that DomeLight is a very special light that has lots of hacks on top of hacks on the inside. Would be awesome to see it finally go and be replaced with regular environment MIS by GI. Just pure idea of not having to have additional light source in the scene just for IBL to work is very comfortable.

[^Lele^]

The physical camera does work.
It's the exposure control which doesn't, and looks a lot like the mR one.
But that wasn't us. Phew!
Besides, if one buys, one then owns, right?
Scratches and bumps happen to the best of drivers, in the best of cars, along the way.
They'll get it fixed, eventually.

[Ihno]

as it's one of the worst user interfaces I have ever seen in my entire life.

As the wohle Max user Interface it is ugly as hell. But bad in chase of usability?
For me its rollouts make sense and i find everything immediately unlike the vray Physical cam
I think userinterface "design" is something that never will make everyone happy.

[^Lele^]

As the wohle Max user Interface it is ugly as hell. But bad in chase of usability?
For me its rollouts make sense and i find everything immediately unlike the vray Physical cam
I think userinterface "design" is something that never will make everyone happy.

Eheh, yes, there's that too.

It's been a loooong ride with Max (I was authorised just after the mass extinction of dinosaurs, for support and training, by Kinetix, in Max 1.), its quirks, and its amazing ability to get stuff done.
There was never a better time for Max at Autodesk than today: the good, the great, and the legends are there, and working hard at it.
Some (i shan't name names) will drive it forward with a sure pace because they were part of the original max dev team, or as coders were responsible for some thing or the other which has been industry-changing, others have gone to the Max team bringing over 20 years of User experiences at the highest level in a number of fields, and contribute with that expertise to workflows and such.
Some bits stay ugly and quirky as they have always been, but that is also why it hasn't been a one-night-stand with Max, for me: it's learning to love the defects of the other which keeps couples together for a long time...
Other change, for the better, and i go "eh?!?", at first, old age and habits telling me "this is so very wrong!!11one PANIC!", only to realise someone did indeed put thought into it, and i just had to give it time and get accustomed to.

The new Physcam, and the global exposure workflow, are of the latter type.
Damned if you change, whichever way you go, damned if you don't.
My saying i don't like the WORKFLOW one bit is borne out of being accustomed to something else, and not understanding very much the logic behind the global exposure mode.
And it's a MINOR annoyance which has to do with finding a menu when it used to be where my brain expected it to, as the defaults in fact respect per-camera exposure, so if i change nothing, i get the old, tried, tested and loved, behavior of linear camera-based exposure controls.
In fact, unless one's got ten cameras all looking at the same subject from the same angle, under the same lighting, local exposure has to be the only way to go.
In RL it would be. And the defaults promote that.
The little annoying bug with the target/focus target i had in SP1 was cosmetic, not functional, and only discovered because i was scripting an auto-focuser (ye oldies: yeah, it's coming back!) and the viewport preview was off what i expected.
Rendering was just fine.

Making movies raytracing with rMan 16, now, that was functionally abusive of my intelligence, time and patience (and not just mine. cue valleys with rivers of tears flowing through them...)
And an experience many who have tantrums about minor annoyances (not referring to THIS thread or its participants! generic statement warning!) should really try for size.
We (max/vray) users are spoilt children, by comparison, by too much goodness over too long a time, which we now give for granted.
And i bet we will anyways be the first ones to get a functional mind-reading interface, should it ever be invented.
To then find something wrong with it.
Can't change human.

[vlado]

The mental ray exposure control is working purely by chance because it appears that in 3ds Max 2016, Autodesk implemented the tone operator methods that we call; we didn't do anything specific to support it on our side beyond what is needed to support tone operator plugins in general.

On the other hand, we specifically don't support the "Image Control" section of the physical exposure control. I wondered whether to do this for a while and we ran out of time anyways, but my main reasons against it were:

a) The defaults of the physical exposure are set up to produce non-linear output images (and the settings the do produce linear output are not obvious). Many users have set up their pipelines relying on the fact that V-Ray produces linear output and changing this default behavior for V-Ray seemed like a very risky thing to do, especially if we wanted users to move to the new Physical Camera. I myself have been caught off-guard by the default non-linear settings of the physical exposure a couple of times.

b) I still believe that this functionality should be ultimately put into the rendered image window/VFB.

Best regards,
Vlado

[LudvikKoutny]

I actually agree here. I think Image Control settings should not be supported to prevent having non-linear output by default when using a camera type that's a default one for Max 2016 and newer.

What I was caught off guard by was, when I had different looking output out of V-Ray and V-Ray RT, that came down to V-Ray supporting image control section of MR's photographic exposure while V-Ray RT did not. The fact that MR one works shuffles things around. Almost makes me think if it wouldn't be a good idea to intentionally break it

I am a bit puzzled by this odd behavior as from what I remember, Autodesk was quite bragging about how new Physical Camera in Max 2016 was co-developed with ChaosGroup. And considering how chaotically (pun intended) its user interface looks, similar to old V-Ray's physical camera, as well as post 3.0 V-Ray Light and VrayMTL UI, I believed you had a lot of input into the development of the new Physical Camera

[vlado]

What I was caught off guard by was, when I had different looking output out of V-Ray and V-Ray RT, that came down to V-Ray supporting image control section of MR's photographic exposure while V-Ray RT did not. The fact that MR one works shuffles things around. Almost makes me think if it wouldn't be a good idea to intentionally break it

Yes, it seems to be a new thing in 3ds Max 2016; that's a good catch anyways - will see what can be done about it.

I am a bit puzzled by this odd behavior as from what I remember, Autodesk was quite bragging about how new Physical Camera in Max 2016 was co-developed with ChaosGroup.

The camera yes, the exposure control - no.

And considering how chaotically (pun intended) its user interface looks...

I'm the last person to give advice on UI... The interface was done by Autodesk whereas we provided the code that implements all the functionality. If you have suggestions on how to organize it better, it would be best to report them to Autodesk.

Best regards,
Vlado

[LudvikKoutny]

Ah, thanks for clarifying that. I guess I will bother them (AD) about it a bit

[^Lele^]

Ah, thanks for clarifying that. I guess I will bother them (AD) about it a bit

Oh, they read here, i know that for a fact.
Still, it'd be good of you to provide for a good case scenario and ideas about usage directly to them.
You'll see, there are real humans there, now (i can't vouch for the dark ages...)!