We do fairly large architectural projects here with a small team. As such we’ve found the best way to break things apart is to use xrefscenes of chunks of the project (ie main bldg, surrounding environment, site, landscape, cars) and xref em into a master file that only has lights, cameras and render settings.
We often have a problem where distributing a render will work at first, then will have black buckets returned from the dr nodes. I haven’t been able to put my finger on the exact cause but I know it’s related to xrefscenes because sometimes (if frustrated and under urgent deadline) we’ll merge all the xrefscenes into the master file to render and it’ll distribute fine after that (but the file will be huge and slow of course).
Nothing concrete to post back but do have some slight news. Had the black buckets happen yesterday (in a project w/o VRS) so I cloned the camera and re-rendered (thanks Tricky for the suggestion!) and the black buckets were gone. Hours later (after closing / re-opening) I tried to DR from my original camera and it didn’t work so this time I cloned it, deleted the original and rendered from the clone. It worked fine. It almost seems like the camera gets corrupted and somehow cloning it fixes the problem… Weird…
The cams in question are vrayphysical cams with fairly default settings - only thing slightly out of the ordinary is we use the vertical shift value…
I’ll keep looking into this over the next days / weeks to see if I can get a reproducible case.
We have also found that if you start adding a few more XREFs to your scene, the camera may ‘turn to arse’ again, so you just clone it again and it will be fine. It is definatly a bug.
We’ve also had this problem at our company but resolved it in a different way.
We think the reason why the black buckets occur is because the Vray spawner was holding onto old data from previous renders. Probably something to do with the network connections. We’ve even encountered buckets that render from a previous scene. We’ve often had to do these fixes:
-Re-saving the scene with the distributive render button checked sometimes helped.
-Relaunching the V Ray Spawner on the slave machines always helped, but if you have a lot of machines it might be daunting.
What version of V Ray you have? Because in version 1.50.SP3a there is a check box in the Distributive Render Settings tab called “Restart slaves on render end”. (See Attachment) This will reset your slaves back to normal. If you have an older version of V Ray the other two suggestions should work.
As for the X-Ref problem… Is it rendering the Xrefs in the buckets that are good? Because if it is rendering fine in those buckets than i would say.. Xrefs aren’t the problem.
The only real problems I’ve had with Xrefs was when i was X-Refing from a different drive. Such as textures library on a different drive. So i suggest keeping everything your X-Refing on the same drives. This will also help if you have to Archive a project. Ive found that archiving jobs with stuff pathed to differen’t drives sometimes it would miss textures.
I hope this info was helpful…
Good luck
-Fizzgig
Had same problem here. Black buckets after merging XRef scene. Restarted Max, restarted slaves with no effect.
Cloning the camera worked for me.
Is it a Max bug or Vray bug? I use Vray physical camera.
Still happens to me. Scene with 5 or 6 Xrefs in it. Rendered fine yesterday. Started work again this morning and it happened again. Cloned the camera (vray camera) and problem went away. Downright annoying!
Thanx for your workaround on cloning the camera. Now this finally works for me to work with x-refs and complex scenes with lots of x-reffed filles! It took me hours and hours with all sorts of settings and testing.
I really hope this bug gets fixed in a future release…
We had issue with xrefs when there were cameras with the same name in the master file and the xref files in Max 2009. Especially when setting up a batch render lsit. Max 2010 seams more stable with xrefs. Now we always xref the masterfile with cameras back into our working files with overlay checked instead of having copies of cameras.
Also to note is that DR requires all assests (images, xrefs, xrefobjects, vrayproxies) to be full UNC path. Using relative to project doesn’t work with DR (but OK with backburner).
