Still the same DR bucket problem

Hi there!

It seems that I have a quite common problem: When I use distributed rendering, the buckets of the render slave pc renders its pixels darker than the local machine. Both machines newest builds, same spawners. I already searched the forum for this problem and found many questions but no real answer. Is there a solution for this problem in the meantime?

Thanks for a helpful reply.
Cheers
Toni

This usually happens when something is not accessible for the slaves - these could be textures , IES-lights , Pre-saved Global Illumination or any other external asset.
Sometimes V-ray has troubles with accessing assets through Mapped Drives - and we usually recommend using only UNC-paths.
Another reason for this bug is if you have different Vray builds installed across the machines - make sure that all machines have the same build installed.

The best way to find out if the issue is related to something missing would be to prepare a very simple scene with a few primitives and a light, without any textures , precalculated GI and etc and run a Distributed Rendering - if the result is what is expected then most likely the issue is related to missing assets for the slaves.

Toni, maybe you can see an error message at the spawner progress window.

Thanks for your replies.

Well the problem is, that there doesn’t seem to be any logic, when the error occurs. Sometimes it works and sometimes not. We are working with a nas-server and all the files are on this server, with the paths being the same for each machine. And as I already wrote: same versions of vray. Very strange. I’ve attached a rendering to this post to show you the output. Help is very appreciated.

Wow, that’s strong. Only I know light different buckets of frozen glass materials. But your looks like GI passes and textures are not right working. And you see no error messages at the spawner windows?

I had no problems with the last few rendering, so I could not check the spawner messages for errors. But I will do as soon as the problem occurs again.

If you do get this again, see if restarting the spawners (or computer) and re-sending the render changes (ie. fixes) the result. Our interpretation of spawner performance is that they sometimes get “clogged” with data from prior work. If you restart the spawners and resend with no (predictable) change in result, that suggests it is related to the path/performance of getting the assets to the machine, as suggested above; if re-starting does resolve the problem (predictably), that suggests the spawners themselves are the issue. At least it’s a way to try to pull apart the problem.