pale/dark DR buckets

[svetlozar.draganov]

Thank you very much for the detailed explanation.
How did you set up the gamma via 3DSMax Gamma settings or from Vray Color Mapping Rollout?
Which Vray/Max versions have been used?

[samuel_bubat]

I use max2014/vray2.40.04.
As color mapping I use Reinhard. Before I discovered the explanation above, I tried basically
every possible variations within the vray! color mapping including: Gamma 1, 2.2 values inbetween.
Of course different Multiplier and Burn value settings. All possible modes, with and without clamp and subpixel mapping.
But the problem was still there. The annoying thing about this bug sometimes it seems to be gone and everthing works perfect
for days and suddenly it happens dozens of times in a row. I allready thought I could blame it on the color mapping modes
(no gamma, and gamma). But after some days it happend again.
I have one other suspicion I can not really confirm. But it seems to happen when more than one person is rendering.
We have 20 slaves and the dongles are local. So usually everyone has DR on with all 20 slaves but because of the
dongle limitation it will use 10 and someone else is using the remaining 10 slaves. So maybe that´s where someting goes wrong.

I tried one other thing last friday, let´s wait how it turns out.
1. I made sure on every workstation are the same gamma settings. (Some had max gamma off while other had max gamma on with gamma 1.0)
2. I manually set all gamma settings on workstations and slaves to the exact same values.
I did this here
...\AppData\Local\Autodesk\3dsMax\2014 - 64bit\ENU\en-US\defaults\MAX
and here
...\3ds Max 2014\en-US\defaults\MAX.vray\FactoryDefaults
and altered the [gamma] section of the CurrentDefaults.ini to

[Gamma]
DisplayGamma=1
Enable=0
DisplayCorrectionMode=0
CorrectColorPickerState=0
CorrectMtlEditorState=0
InputGamma=1
OutputGamma=1
LUTFileName=

It´s a bit a shot in the dark So far the problem did not occur again. I ´ll let you know if it happens again
or in some weeks if it´s gone.

[svetlozar.draganov]

The issue should not be related to the dongle in any way at least in theory.
Changing the default gamma-settings is a good idea but it should also match the gamma-settings saved in the file.
Let us know if this works or not.

[digitalx3d]

Just thought I'd weigh in here as another user who sees this problem frequently, and for quite a few years as well. I've never been able to find a solution either. Though I do like the Gamma Issue theory. That seems most plausible because the buckets are simply lighter, the texture is present. I've always experienced my 2 slaves as the machines that rendered the "bad" buckets, as the IR map starts calculating locally first during which the buckets all render correctly. Only when the 2 slaves kick in do the lighter buckets start showing up. Then once the ray tracing begins I get the lighter buckets all throughout. I don't think it just sticks to where they were located in the IR pass. However, I've never really made a big effort to pinpoint the cause because I'm usually don't have the time. I can usually solve the problem by letting Max finish the rendering and then rendering the image again (without restarting anything). Sometimes the problem is persistent and then I restart max on my Local machine and that works. However, if I see the problem buckets and I cancel the rendering, and then restart the rendering immediately I ALWAYS get the same light buckets. I either have to let the rendering finish and wait a couple minutes (presumably for the spawners to restart on my slaves, as I have that option checked in my DR settings), or restart Max on my workstation and/or the spawners on my slaves.

[glorybound]

I have found that this happens when I have a small bucket size set. I stopped using anything smaller than 32 and Ihaven't seen the issue since.

[digitalx3d]

Bobby,
Do you experience this right at 32? I rarely use any size other than 32, and so obviously this does occur at 32. I've never paid attention whether or not this happens or not at a different size, so next time it does, I'll up it to 48 or 64 and see what happens.

[samuel_bubat]

I have found that this happens when I have a small bucket size set. I stopped using anything smaller than 32 and Ihaven't seen the issue since.

Thanks I ´ll give it a try. I usually use 32 or smaller. I allready changed, as suggest, before the bucket size and it worked for a certain time,
but I think I never went larger than 32px.

[samuel_bubat]

Sorry for bringing this up, once again. But I had some time to test a bit and I think I could narrow it down now quite a bit. The problem in (my case) seems to be the "awesome" new autogamma function for bitmaps in 2014. When assets are loaded from older max versions with different settings this problem occurs. So I made a demo scene that reproduces the problem. It´s a pretty basic scene in my case no gamma 2.2 was used. (Please use scene settings when open them.) I merge an asset, some bush as proxy from another max scene. I save the scene and reopen it again just to make sure all network path are there in the asset tracking. I render the scene several times and from 10 renderings I get 5 to 6 with dark buckets. I was now able to fix the problem by simply going into the 3 maps from this bush material click on the button that opens the bitmap file dialogue and hit open. I do this with all 3 maps and after that the problem is gone. Simply clicking "reload" does not fix the problem ! I save the scene, reopen it and the problem is still gone. So now I have 2 identical scenes. 208kb in filesize. One is broken, one is not. I attached both files including the proxy and the 3 maps. I you open the _broken scene, put and link all the assets to a network path and render DR you should get the problem in every second rendering. If you open the _working scene the problem should be gone. Pretty strange. We´re still on max2014/Vray2.4.04. We plan to upgrade to Vray 3, soon but want to keep 2014 at least till 2016 comes out. Did something change in Vray 3 regarding the gamma handling ? I hope there´s anything that can be done about it. Some assets have dozens of bitmaps, and we have tons of assets in our scenes. This steps needs to be done whenever something is merged. It´s quite time consuming.

s_dark_bucket.zip

[tashko.zashev]

Hello Samuel,
We are going to run a few tests here, hopefully we will be able to reproduce it.
We will keep you informed.

[tashko.zashev]

Hi again,

It is very odd, we did a lot of render tests and the issues seems to not appear. There are no visible difference in brightness between the buckets from the main and render slave machines.


We tried to keep exactly the same setup , so we have created new mapped drive "R" and copied all textures there. This way we don't need to edit the file paths from the Asset tracking manager.
Would it be possible to attache one render result from s_dark_bucket_broken file ?

[samuel_bubat]

Attached is a screenshot. Could you try rendering the file with file gamma settings ? I see you use Gamma 2.2.
The gamma settings in the file should be 1.

[tashko.zashev]

I did a series of tests with Gamma set to 1, but the final render is always correct.


The problem definitely seems to be the 3DS Max Gamma correction added for the input file.

but it is very strange that the workstation and the dr node load it differently.
If we could reproduce it here, we would be able to find if it's V-Ray or 3DS Max issue.

Do you have any service pack installed on your 3DS Max version? I did my tests on 3DS Max 2014 SP3.

[samuel_bubat]

A pitty it can´t be reproduced. Yes we also have Service Pack 3 on the workstations as well as the renderslaves. So I found another kind of workaround
by converting all bitmaps to a VrayHDR Loader, wich works well with just on click for a whole scene. I made some tests and it seems to work without any problem.
Looks like it consumes a bit more RAM but slightly less rendertime. Is there any reason not to use a Vray HDR for all (LDR) images in a scene ?
So we could meanwhile just go that way and see how it turns out once we have Vray 3. Anyway thanks for your efforts !

[tashko.zashev]

Is there any reason not to use a Vray HDR for all (LDR) images in a scene ?

The V-Ray HDRI map could replace the native 3DS max bitmap loader. It has more options and advantages like loading tiled OpenEXR and tiled TIFF files.
However, just keep in mind that it still doesn't support some image file formats, vector file formats and video files.

[samuel_bubat]

Ok great this an acceptable solution. But I did another test and now i´m sure what´s wrong. Everything I wrote before is still valid but I know now what triggers this behaviour. The following may sound stupid but I can now exactly reproduce the problem. The problem is "restart slaves on render end". Ok where should I start... I ´m monitoring one slave with remote desktop. When "restart on render end" is on you can see max closing and restarting in the task bar. When a rendering is finished and you hit render immediately again you´ll get "could not connect" because the slave didn´t restart, yet. When I wait long enough until max in the taskbar starts blinking and I render again everything is fine, no dark buckets. But If I start
rendering when max is allready open but does not yet blink , there is a timeframe of some seconds when you hit render and the dark buckets will appear. So In my case I render a scene,
wait till the rendering is finshed, I wait till max is closed on the slave. In the moment max appears again in the taskbar, I count to 8 (yeah really) hit render and I have dark buckets.
Of course the time may vary depending on the machine.

This also explaines why it never happend in a final rendering. Because setting up a final render usually takes some time and the slaves have enough time to load the vraydummy scene completely. But when I adjust materials or lighting, I see the rendering. Adjust some setting wich takes only some seconds and than I have a good chance to run into this timeframe.
NOW IT ALL MAKES SENSE .. well let´s see... maybe I just made a complete fool of myself... but I´m pretty sure that´s the reason.