Vray Scans - Gamma option removed from material

Hi everyone.

Upgraded to the newest version of Vray. Upon rendering, we noticed that the vray scans material is not rendering as it previously was. Upon further investigation, it appears that the gamma control for the material that was located below the saturation modifier is no longer present. is this intended?

Need to find a fix for this asap.

Thanks!

Today we made the exact same experience! This needs to be addressed as soon as possible! Nearly all of our renderings rely on that feature in one form or another.
To the devs: Before making such a far-reaching decision, would you please get in touch with your userbase first?

The gamma option is nonlinear, this means - it changes the color when the light intensity is increased or decreased. It was added long time ago, before anny additional color tweaks were available just to give some control.
Nevertheless, both of them (gammaand saturation) must be still working for already existing scenes and can be tweaked with script. If this is not working, it’s not intentional and will bre fixed.

As a compromise, can the gamma feature be moved to advanced rollout together with a warning? It will keep novice users from touching it, but experienced users could still tweak it.
Also, that change was nowhere documented. Neither in the changelog nor in the V-Ray Docs.

This would be the move.. Regardless as to why it was there in the first place, its still useful and a lot of scenes are predicated on this function working.

Assuming one has a scanned material in the first material editor slot, running the script line below will set the material gamma to 2.2:

meditmaterials[1].gamma=2.2

Running the line below will print out the gamma for all materials in a given scene.

for m in scenematerials where classof m ==VRayScannedMtl do
(
print ( m.name + " has a gamma of " + (m.gamma as string))
)

Regardless, Gamma should be preserved from old scenes, is it not the case for you guys?

A lot of times we would use the gamma slider to adjust the tonal darkness of each material. I’m not sure if this is getting confused with a different part of the material but that was my understanding as to why that was available to us in the slider.

currently materials that had that slider adjusted are rendering much lighter.

Well, you just perfectly demonstrated how misleading this parameter is. Every CG guy knows “the default gamma value is 2.2”, but this parameter is not overriding the general gamma. The normal gamma 2.2 is introduced by the render engine after the rendering is finished, and the origin of this operation is to make the result suitable for displaying on CRT monitors, thats why the value is 2.2 but not 3 or 5. The CRT technology has gone, however the gamma is still introduced, because beside the CRT compatibility it gives us a very valuable “side effect” - high dynamic range or high contrast level. But as i said, this general gamma is introduced by VRay, it’s not VRScans job to add it. The value 2.2 suggested in the script above reveals that Lele is understanding the VRScans gamma as kind of override of the general gamma, and Lele is a power user, not a newbie. The VRScan’s gamma must be 1 in order to get the original appearance, not 2.2
So, apparently the parameter is used, so it will be restored in the UI (it was removed only from the UI) but under different name (suggestions are wellcome).
However, another question is more important -as i said, the parameter is not removed, only the UI is affected. How it happens that old scenes are rendered differently? Any additional observation thatcanhelp to clarify this question is wellcome

I will post some images together with a suggestion for the name later.

I used the sRGB 2.2 gamma for the sake of ease for users without scripting practice (it’s a recogniosable value), not as a mean to illustrate what values it should be set to.
If the gamma was a power, then we all know how to use it as we also do some form of compositing or another. :slight_smile:

This gamma slider is a quick way for controlling the overall brightness of the Scans, it is something I use every day .. And similar to to how Gamma/contrast works in a ColorCorrection texture for example. This is very common in look-dev
It is not about EOTF or linearizing data for rendering,

Okay, here is a description of what we use the Gamma value for in a quick IPR session.

The task was to render a car in BMW Tansanitblau II. The paint was delivered on a speedshape, the rough reference looks like this:

Instead of sending the speedshape to Chaos for scanning, carpaint_blue_13_s from the ScannedMtl library was used, because of the tight deadline. The material at default values gave us something like this:

Setting the Gamma value to 0.7 gave this result. Pretty close to the reference!

Same process for the wheels. We already had a kind of anthracite-grey wheel paint in our own library which we modified to black. Here with default Gamma:

And with Gamma 0.6 to make it darker:

So please please bring this feature back (in a hotfix, because we use it a lot). A suggestion for the name could be Brightness, or even Contrast if you wish.

However, we never had an issue with this value. No weird artifacts, no additional noise or fireflies. The worst that could happen is that some materials are getting more saturated with lower values, but this can be compensated through the saturation parameter already.

OK, the slider will be restored.
But i still can’t reproduce the 5.2/4 difference, here is the result from rendering of material with gamma=2 , it’s the same.

It seems to be related to loading a ScannedMtl from our .mat files on the server. Somehow the values seem to get to reset to default values.

I cannot repro this locally: if i set the gamma with maxscript, and save the material to a library, when i load it back in a new max session the gamma value is preserved.
It’d be interesting to see one material which does misbehave.

I’m not able to fully reproduce this, either.
However, if the Gamma parameter is going to come back under a new name, this would not cause any trouble. We would be happy if it indeed does come back!

Hello,

The parameter is back in the stable nightly builds starting from build number 31077 (Chaos).

Best regards,
Yavor

Great, thanks!

Is this already implemented in the 5.2.1 hotfix from Nov. 4th?

Yes it is.