network rendering - random issue

[NicoC]

Hello

I'm totally lost with a problem we have now, since we switched to v2.40.04 (on 3dsmax 2012 x64, Windows 7)
We use either DR or BackBurner, and the problem is the same: luminosity variations, and it's never on the same node. To summarize:

- with DR, we regularly (randomly) have at least one machine rendering brighter buckets.
- with BB, we regularly (randomly) have at least one machine rendering brighter image.

For the DR problem, we have to close the Spawner app and re-run it to solve temporarily the problem - it occurs again, but without being predictable.
For the BB problem, no workaround found so far.
Finally, it even happens sometimes when rendering only locally: the rendering suddenly becomes much brighter (looks like physcam exposure has been tweaked for example). BUT if we render again just after, the result is correct again !!

I've to precise that all assets (maps, proxies ...) are located on our server, and all paths are UNC. Lastly, every machine has the exact same 3dsmax version, including SPs, and same VRay version.

I feel completely lost in front on this problem, all the more that we have about 35 cameras to run in this scene tonight !

Thanksin advance for any help you guys could provide ...

Best regards.

[svetlozar.draganov]

Thank you very much for the detailed information about the issue.
At first we have to find out if the bug it related to the scene - or it is something with the configuration.
Please create a very simple scene with a few primitives , lights and materials and proxies - try to keep it as simple as possible.
Then run separate tests for DR and BB and watch out for the same issue - if everything is rendered correctly here then the issue is scene-depended.

We have two options if the issue is scene-depended - the first one is to send us the scene along with all external assets for investigation in our environment , and the second one is to connect remotely to your machine and to run first hand tests directly in your environment. In general we prefer to tests the scene in our environment - and to move to remote-session only if it is needed.

Have you tried to activate "Check For Missing maps" option from Vray>System Tab ? If not , please turn it on and run another test with DR and BB.
Would it be possible to provide more information about the scene - for example a few screen-shots good/bad frames with DR and BB.
How much RAM 3DSMax/Vray occupies during the rendering - and how much is available on the machines ?
How many machines are you using during DR / BB rendering ? Does the issue exist if you are using less machines - 2,3 for example ?
Have you got this issue with earlier Vray version ?
Are the Vray-spawners started manually or as a service ?
Make sure that all camera-names are unique - BB has some troubles with that , make sure that they all are unique.
You already mentioned that you all 3DSMax/Vray installations are the same but could you please double check that because very often the reason for this bug is different Vray-versions.
Do you have any X-refs / IES-lights in the scene ?
Are you using any other 3rd party plugins in the scene ?

Please check all those things and run the tests we suggested above, then let us know about the results.
Could also give us information about the machines-specification - are all the machines with similar performance or some of them are older ?

[NicoC]

Hello

Thanks for your answer and suggestions. Unfortunately, we're on an heavy deadline right now, and I don't have the time / opportunity to investigate much more now ... so we'll run a maximum of views while we're still at the office, so that we can cancel / re-run views when we get the problem. However, since we're waiting a few previews to be rendered and the validated before running hidef images, I can already answer a few questions.

- "Check for missing maps" was one of my first ideas, it didn't help - we use UNC paths for every asset in the scene, and every machine can access the path without problem
- 3dsmax uses between 10-12 Go RAM when rendering, the machines have 24 Go
- DR or BB rendering use 4 machines at maximum (each of those has its own dongle - I know DR or BB don't require licensing, but I'd rather precise it)
- problem is still the same when we use only 1 node with DR, even the master machine can show this luminosity problem !
- we didn't have this issue at all with the previous VRay version
- Spawners are started manually
- all camera names are unique
- 3dsmax / VRay installations double-checked (even triple-check :P)
- no XRef, no IES light, only 1 proxy (which doesn't have any impact on the illumination)
- no 3rd party plugin, apart VRay

[svetlozar.draganov]

Would it be possible to send us this scene in order to test it in our environment ?

[NicoC]

It's highly confidential, not sure my boss would like that I think I could send you a stripped-down scene, without accessories, but that would change the test conditions ...
I'll ask him anyway, so what email adress should I send the scene to ?

Thanks.

[NicoC]

Hello,

I've got some news. It seems I've managed to isolate something ... it seems related to VRay Light material with a map !! I've unchecked direct illumination as well as VRay Properties of the object related to GI (send / receive) and placed a VRay light to replace the lighting this object was supposed to emitt. And NO problem at all on any of the 36 cameras that were rendered over the week-end
So I'll send you a stripped down scene of the project once it's delivered, in case it can help you to solve this crappy bug for the upcoming v3.0

Regards.

[svetlozar.draganov]

Thank you very much for the feedback.
Yes stripped down version of the scene will be helpful for us in order to reproduce and fix this bug.
Please send the scene to support@chaosgroup.com with a link to this thread - we can also provide you access to our FTP-server if it is needed.

[NicoC]

Good morning

ok, thks !
btw, it's definitely related to the problem I described - because I had only 2 views framing on several light-diffusing shelves, still using mapped VRay light material ... and the problem with differents buckets appears on these areas again !!!

I'll post the stripped down scene later this week.

Regards.

[svetlozar.draganov]

We will be looking forward about it.
Additional information like screen-shots , screen-cast , 3DSMax/Vray versions will be very helpful.

[danio]

I recently had a very similar problem. Whenever I used an HDRI dome light with a texture my node buckets would end up looking different. It was particularly noticeable with Reinhard with a lower burn value than 1 but I recently noticed even Linear Multiply at 1.0 was giving me a lot of noise with the node buckets and very clean on the local machine.

Anyway I went through my node files one by one and noticed that, despite uninstalling VRay 2.40.04 multiple times and subsequently re-installing the latest version, two of my files were still a different size than the ones on my local machine. I guess maybe the uninstaller or re-installer didn't have the permission to delete the files or overwrite them?

Anyway, I copied vray.dll and vray2013.dll from my local machine to each of my nodes and voila! Problem solved. I hope it helps you too.

Cheers,

Daniel Temple

[svetlozar.draganov]

Hello danio

Would it be possible to send us a scene with that issue ?

[danio]

PM sent.

This scene is as simple as it gets, though, and the problem isn't specific to it. It was just the dlls, I think. The problem seems to have been fixed by the solution I listed above so it's not an ongoing issue for me. I didn't keep any of the images showing the different gamma in node buckets.

[NicoC]

Hello Daniel

Thanks for your suggestion, I'll try to do that ASAP. Unfortunately, we've got so much work here that I haven't managed to find sometime and prepare a scene to narrow the bug down, so ...

Cheers.

[danio]

You might just look at the file sizes of those DLLs on your local machine and on your nodes. For me they were slightly different sizes which obviously indicated a mismatch.

Good luck!

Hello Daniel

Thanks for your suggestion, I'll try to do that ASAP. Unfortunately, we've got so much work here that I haven't managed to find sometime and prepare a scene to narrow the bug down, so ...

Cheers.