Vray 3.10.02, DR and Bucket Gamma issue

[o-v]

Well - all time fav...

no matter what I do - I get different gamma in buckets from the slaves. The buckets have higher gamma than the master...

all texture paths UNC, asset tracker shows no local adresses

all textures loaded with override - diffuse 2.2, bump 1.0

two lights in the scene: 1 plane, 1 dome with vrayhdri texure... UNC as well

any hint is appreciated very much!

thx guys

EDIT: Max 2014. The strange thing is: on the previous project all worked fine! suddenly on the recent one - no go with DR. The only change was the update from vray 3.10.01 to 3.10.02 (on all machines...)

[vlado]

Are your textures Bitmap textures or VRayHDRI?

Best regards,
Vlado

[o-v]

VrayHDRI is only as texture in the dome light.

all other textures (geometry) are bitmaps.

[vlado]

Can you try to convert them to VRayHDRI with the bitmap conversion script? There seems to be a bug in 3ds Max 2014 (and maybe later versions) when they introduced the automatic gamma and sometimes render servers use different gamma than the client.

Best regards,
Vlado

[o-v]

So you mean - all bitmaps shall be hooked in via the vrayhdri texture..

Thx - i'll give it a try. Will report as soon as possible.

[Deflaminis]

The VrayHDRI slot makes things render faster too I believe right? Or does simply disabling the bitmap pager produce the same speed up?

[o-v]

The VrayHDRI trick did it. Aside of that, if this "autodesk autogamma went bonkers thing" is a fact - what the heck?

the only thing is: when I load the texture via VrayHDRI node it looks like it has a gamma of 1. so way to bright. and theres no option for an override in the VrayHDRI node, right? so I need to hook the color correction node in?

EDIT: in case of linear workflow and output gamma of 1.0.

the standard setting in max is 2.2 - as to be found in

C:\Users\%username%\AppData\Local\Autodesk\3dsMax\ 2014*-64bit\ENU\en-US\defaults\MAX\CurrentDefaults.ini

* or what ever version is installed

Look at the bottom of the page...

So editing that file and set it to 1.0 shall fix the 2.2 issue for linear output. There's even a script at scriptspot making it easier without having to edit the ini file.

Can this have an effect on the bucket problem? No matter if I set it here to the default 2.2 or change it to 1.0 - the bucket gamma problem remains the same. The input gamma in the ini file is set to 2.2, and the prefs in the max LUT and gamma UI dialog are set to 2.2 - therefore I can't explain the too bright texture in the VrayHDRI slot and the rendering as well. Setting the gamma in the vray render settings to 1 or 2.2 has no effect. the texture renders to bright.

[Svetlozar Draganov]

VrayHDRI node has an option to control the Color Space of the loaded textures:

[o-v]

Oh

thank you very much! dumb me...

[o-v]

imagine: I have to rebuild the shading networks for all my assets....

[Svetlozar Draganov]

Why do you have to do that?
Can you give us more details about it?

[o-v]

if the bucket issue remains and yet all my textures are connected via the standard bitmap node... I'm afraid of consistently reattaching the VrayHDRI node instead. not funny.

but I realized, that only a few shaders produce the bucket divergency. some shaders with textures connected via the standard node works just fine.

the concrete shader works without any issues


the ebano shader drives me mad. In the attached example its already fixed with the VrayHDRI.


Sample scene is here:

http://89.26.13.201/pf/buckets.zip

[Svetlozar Draganov]

V-Ray is equipped with tool for automatic Bitmap to VrayHDRI conversion.
http://docs.chaosgroup.com/display/V...yHDRIconverter

You don't have to manually modify the shading network just run the tool and all the Bitmap nodes in the scene will be automatically converted to VrayHDRI ones.

[o-v]

Hello. Thank you for that hint. May I ask you a question:

Did you design that converter because of this problem? Or do you recommand converting the bitmaps everytime into an exr format? I mean not only by the means of your script, but in general: saving out every image (tif, png, jpg, tga...) as exr?

[vlado]

Did you design that converter because of this problem?

Nope. There weren't any issues with older 3ds Max versions; we added the converter for different reasons. But once this issue came up with 3ds Max 2014, it turned out quite handy. I'm still hoping that a fix for the problem will be available at some point (though it might need to come from Autodesk).

Or do you recommand converting the bitmaps everytime into an exr format? I mean not only by the means of your script, but in general: saving out every image (tif, png, jpg, tga...) as exr?

No, I wouldn't recommend that unless you have specific reasons to do it (i.e. too many textures that overflow the RAM). Otherwise it's fine to leave the bitmaps in their original format.

Best regards,
Vlado