still strange xref/backburner-problems

[digitarch]

hi everybody!
did another rendering with backburner, splitscanlines, vraydome and direct light, several xref-scene, softshadows, displacement, trees are vrayproxies, vrayfur
slices look like this (but sometimes there are just five buckets missing),
bucket-errors "flow" over xrefs and objects
some slices (randomly) are correct, slaves do randomly render fine.
dr doesnt work with xrefs also, scene doesn´t render with everything merged.
tried xrefs readonly readonly, also rendering slices only on one machine.
server is nt-server, cant be the 10-user-problem.
tried smaller buckets, tried smaller stripes....(rendertimes explode as there is the overlap-bug)
tried dynamic memory - rendertimes explode
tried maxframebuffer, vrayframebuffer, no framebuffer

as i do lots of scenes like this ANY help with getting stable backburner/xref-renderings would be REALLY wonderfull
matthias





here you can see 4/10 slices:



and the should-be:

[DanielBrew]

Hi Digitarch

The only thing I can think of is to when you send the job to render via Backburner only select one server to start with. Then add the rest one by one using Backburner Manager leaving a gap of 30 secs. I've had problems sending large jobs to render using backburner especially ones that reference a large number of other files (textures, IR maps, XRefs etc.).
Basically you can saturate your network if you send a large scene to 10 servers at the same time.

Dan

[digitarch]

dan
you mean not "use all server" but only one, then "add server to current job"?
well, i give it a try, but i really ask myself how the "big ones" are doing their renderjobs, this can´t be true. we have nice servers, gigabit, straight filemanagement and still this praying for stable renderings....
but thanks anyway!

[mike.edel]

there are third party tools for network rendering, some of them written by the "big ones" you mentioned

deadline by frantic films:
http://software.franticfilms.com/ind...?page=deadline

rush
http://seriss.com/rush/

smedge
http://www.uberware.net/

most of these are able to also integrate your compositing software
there is one major catch though: they tend to be quite pricy

[digitarch]

well wonderfull, but do i really have to buy another additional software only to get one single still with 2600x1950 rendered reliably? vlado, please tell me "just wait a little bit for 1.5"

[DanielBrew]

dan
you mean not "use all server" but only one, then "add server to current job"?

Yes, I'm afaid I do. Starting the servers one by one has certainly helped me in the past. Max doesn't appear to wait very long for a response from the fileserver before deciding to start rendering with missing maps, XRefs etc. Someone will more Windows networking experience than me might be able to shed more light on this.

Dan

[RErender]

running bb manager on a server os should help, it's the 10 concurrent connection limit in XP that gets in the way.

[digitarch]

eric, the manager is running on nt-server, everything is gigabit, shouldnt be the 10-connects-thing. also, its a small scene in filesize (splitted in xrefs even helps with sequential loading) big meshes are vrayproxies, there are view textures, only two bigger masking-bitmaps ....

i´ll try that server-after-server-solution, we´ll see tomorrow....

[mike.edel]

i read about problems with xref in general before - are you sure yours aren't caused by the xrefs themselves?

[finalcut]

digitarch,

once I had similar problems with large maps, many nodes, bb and strip render jobs. some buckets of the stripes looked similar to your's.

Since then I decided to always distribute all maps with a batch script to each node prior to job start. Before that I edit all (new) references to maps like

\\127.0.0.1\texture\projectname\map1.tga

where 'texture' is a share on each node. I do the map path tweaking with the Bitmap/Photomatic paths under utilities (of course you know that). To select a map locally just type in \\127.0.01\ + ENTER in a select bitmap dialogue. All shares apear, then select the project folder. this way each node looks for texture maps through the loopback adaptor. no network traffic. no 10 user/connection problems, no server os needed.

The batch only distributes maps that were changed or are newer than the existing one on each texture folder. By doing that, the procedure won't take that long exept the first time. To copy I use robocopy.exe from the windows ressource kit 'cause it is faster than xcopy and has several switches to save time and observe the process.

I know it is only a workaround... maybe that helps.

If you need any resources or some lines of code for the batch I could post it here.

Now I just struggle with xref problems when using vray's distributed rendering. Some of the buckets miss the xref scene objects. the upper procedure for xref scene did not help.

[finalcut]

matthias,

update to my last post: the procedure with the xref path to the *.max set to sth like

\\127.0.0.1\xref\projectname\xref.max

where xref is a share on each node works well with dr and bb3 / strip rendering.
bad news: it only works with xref objects, NOT with xref scene. weird!

gerrit.

[digitarch]

well, now it works EVERYTIME when using only ONE renderslave, means it has to be something like network timeouts and rights? can´t be the scene, bitmaps, mesh, ....

[DanielBrew]

Does it work whichever slave you choose or have you only tried one? Also have you tried adding more slaves once the job has begun?

Dan

[digitarch]

dan, yes i tried starting them one after one. doesn´t help cause its 10 slices on 4 machines.... the first 2-3 slices do work well, then the dropping starts.
replaced the big maps with optimized versions, didn´t help. i´ll have a closer look at the meshes now, maybe collapse or looking for unused uvw might help. really want to solve this
matthias