DR buckets with different gamma [SOLVED]

[DP]

Hello,

We're seeing this pest again and can't seem to shift it.

vray_adv_37001_max2019_x64
max 2019 3.4
windows 10

even checked color correct versions even though the scene isn't using it

other scenes render ok on this setup so the issue is file related

all paths are UNC and we've checked the nodes can see a license

The slaves are continually rendering bright areas just a little darker.


Tried Motion blur on/off/ embree on/off overide material on/off max ray intensity on/off, sub pixel on/off clamp on/off gamma 1 or 2.2 in colour mapping

running brute force, tried changing bucket size

Any ideas on what to check? Whatever it is it's consistent

Thanks in advance

[DP]

Found the issue

The file had the max Enviroment to use Linear Exposure Control.

Setting this to No Exposure Control made all buckets the same.

Thought we'd leave this here for others. vlado might advise on why this isn't sent to DR slaves and if it's fixed on newer versions which are being developed still

[VanWijnenVR]

Unfortunately for me this does not fix the issue. It's been affecting my render passes in a lot of different ways. I render in bucket and there may or may not be a difference in butckets for the slave and main unit. Sometimes the RGB looks fine and then the Zdepth, RenderID, diffuse filter or whichever pass is messed up. A lot more often than not at least one thing is wrong. It results in gamma/color difference when it's RGB/Effect Result but for the other passes it results in just plain black / what it should be. This has started happening about 2 weeks ago and it's getting rather problematic.

I hope someone could explain / investigate what's going on because this is starting to be a real problem for me.

[^Lele^]

Ensure there are no warning in the log, and if there are address them (f.e. incompatible maps or materials, with the scene converter.).
If the problem persists, you may want to send a scene to investigate, and some more details, to support.

[nikoleta.garkova]

VanWijnenVR, to add to Lele's comment: can you share your V-Ray/host platform versions? Are you sure you've got the same service packs on all your slave machines? Have you got any screengrabs demonstrating the issues, or can you show us what the passes look like?

Best would be to forward a scene to support@chaosgroup.com (make sure to mention this thread in the email) so we can try and reproduce this in our environment.

[VanWijnenVR]

Ensure there are no warning in the log, and if there are address them (f.e. incompatible maps or materials, with the scene converter.).
If the problem persists, you may want to send a scene to investigate, and some more details, to support.

VanWijnenVR, to add to Lele's comment: can you share your V-Ray/host platform versions? Are you sure you've got the same service packs on all your slave machines? Have you got any screengrabs demonstrating the issues, or can you show us what the passes look like?

Best would be to forward a scene to support@chaosgroup.com (make sure to mention this thread in the email) so we can try and reproduce this in our environment.

Thanks for the replies. I haven't updated anything so all the versions should still be the same. I'll check it nevertheless cause that would make sense. I'll try to cut the scene up since as of now it's huge with all the XREF's (it's an entire neighbourhood with a lot of FP, RC etc.) As soon as I get the chance I'll check and send a scene. Not sure when due to all too familiar deadlines and meetings.

I've attached some of the passes in which the problem is visible. Note that the only visible alteration is in the parking spots and the ridge tiles. This particular scene gives no alteration on the RenderID pass. Over the past few weeks I've had all sorts of different passes coming out with visible buckets. Zdepth seems to be the one that is affected the most.

[^Lele^]

Ok, so if it's a massively Referenced scene, you'll want to run a v-ray scene conversion on each of the incoming material.
It ought to simply be Open->Convert->Save: no biggie, time-wise, and with no need for user input.
If any xRef had incompatible nodes (say, very old stuff), you'd run out of luck quickly.