distributed rendering vfr4

[martin1012]

hello out there, did someone get the "distributed rendering" option to work :? I'm just wondering if I'm doing something wrong in vray to set it up or if I have general network/firewall/ip problems to reach my second machine... so first I would like to know if it's supposed to work properly already...
basically the setup should be very easy, but, I dunno
thx,
martin

[dalomar_cg]

Re: distributed rendering vfr4

There were a number of issues that were going on with distributed rendering. Joe has fixed a good deal of them, and it will be working much better when we release the next beta.

As far as the set up itself it should be relatively easy. Start the spawner on the other machines. Find out there IP addresses. And use those IP addresses in the distributed render dialog box. I'm not sure if your network could have contributed to some of the issues, but I've used it on machines with firewalls on both ends. Maybe you have to configure the application to communicate through your network. Either way it won't be fully operational till the next release, so I wouldn't worry about it until then.

[martin1012]

Re: distributed rendering vfr4

ok, thanks.
I'll fiddle around a bit, so what's a spawner and where/how do I activate it? If it's too complicated I will wait for the next release to go in further.
ciao,
martin

[Theory13]

Re: distributed rendering vfr4

distributed rendering setup was pretty easy here....
but time test say that it took just as long to render the same scene. (no speed improvement)
also.... any textures applyed to surfaces did not render in the distributed rendering machine... only textures in the local machine squares.

after re-reading the last few posts.... sounds like you know there are issues and i should wait for the next beta (i'm using beta 2). i'm VERY intrested in distributed rendering for VfR.

cheers,
--j.andre.

[martin1012]

Re: distributed rendering vfr4

...as long to render the same scene. (no speed improvement)

...not render in the distributed rendering machine... only textures in the local machine squares.

... and you're sure your slave participates in the rendering (missing textures would proove this...) one render bucket had the name of the local machine and the second of the slave?

I was using beta 1 a few days ago, no spawner and simply did not work, but this is obsolete now. I hoped beta 2 would work :'(

my problem is now that at home I have one machine with xp64 and one with xp32.... quote from corey in his beta 2 e-mail announcement:

...o There is a bug with the current V-Ray Core in which 64bit machines cannot communicate properly with 32bit machines under DR conditions

... but in the office it could work, all xp32 machines... so it's a bug which will be solved in beta3 ? or is someone out there getting it working? :

v-ray is already fast, but with distributed rendering as easy to setup as supposed to it would be "lightspeed baby" ;D

ciao,
martin

[dalomar_cg]

Re: distributed rendering vfr4

but time test say that it took just as long to render the same scene. (no speed improvement)

In order to actually use the other machine there is a certain amount of time/energy/processor power/memory that is expended by the host machine in order to send the required information to the slave computer(s). Depending on the nature of the scene itself the may be significant task, and this has to happen for every bucket because it is unknown exactly which bucket is next, and therefore what info will have to be sent. There are also network speed considerations to go along with this as well. Ultimately the time spent on these tasks may not significantly speed up the rendering as much as one would expect (ie thinking your times will be cut in half by a second machine is quite wishful). How much the speed changes is directly linked to a number of factors, but ultimately it starts at the nature of the scene itself. A scene that can render in <1-2 min may render the same or longer. A scene that renders in 3-8 min may only show a minor improvement. The scenes that tend to take longer and with slower moving buckets may show more significant improvement because the set up and transfer time is proportionally less the the actual render time (these approximations are assuming only one slave machine w/ relatively the same processor power of the host machine).

Several things that may be a culprit of "stealing" speed.

1. In LC the number of phases may be set to a number lower than the available number of threads. Check the no. of threads and set accordingly.

2. All the IM calcs are done in one pass instead of multiple which is a significant slow down. I'm not sure y this is, and I'm not sure if it is like this in max either (I could never get vfmax dr to work)

3. The bucket size is too small, and therefore more setup/transfer time. Setting buckets to a larger size may help

Thats my explanation/suggestions...hope it helps

[Theory13]

Re: distributed rendering vfr4

i was using a pretty small render test... maybe 450x200-ish... and the default bucket size. i have 2 processors on my local machine and one on the slave. it did put the names of the computer on each of the buckets.
yes, it was doing 4 pre-passes locally, and with distributive computing on, it only did one pre-pass.

the missing texture issue is the big one for me at this time. (kinda makes it worthless)

but thanks for the Tips dalomar. they all make sense and i'll try to impliment them if i do some "white model" renderings (textureless).

it is great to see distributive computing moving forward with rendering with VfR!! i look forward to Beta 3! ;D

cheers!
--j.andre.

[Travis Serio_cg]

Re: distributed rendering vfr4

yes the absolute maps path thing is an interesting problem. for us we configured our scene and made sure that we created a generic C:\Maps\ then we made sure all of our scenes maps were in that folder. Lastly we transfered the local C:\Maps to all the nodes C:\ to insure we had all the paths absolute. Not fun by any means but it worked.

I think DR will be a major advantage for the 20+ minute renders. I guess you have to take a guess at whether or not vfr can transfer data back and forth between the nodes faster than you local machine can render that particular bucket. My 840EE can bucket render pretty dang quick with its 4 available threads. It's fun to imagine me having a network full of equal ability machines. But.. I have access to about 30 to 40 P4 2.0ghz to 3.0ghz machines on my work's lan, some HT's and some single thread P4's. On the big renders I think even the slower machines will help a little bit.

[dalomar_cg]

Re: distributed rendering vfr4

In my opinion the ultimate DR is basically the whole screen is completely filled with buckets, so the amount of time it takes to render is only the time of one bucket basically. There are two issues that I see with that though...First is that with that much transferring of info to that many computers, it would be much better to exclude the host machine from the actual rendering (I believe someone here has asked for that). And secondly the whole system would have to be stable enough across all of those machines. I'm not sure if this would really turn out to be that much of a problem, but I could see problems with slaves crashing or even worse the host machine. Maybe there's somebody who has stretched DR to this limit in Max, but my initial impression is to be cautious.

[Travis Serio_cg]

Re: distributed rendering vfr4

once the spawner is working a bit better i will try it out on 20+ machines at once and see what happens. lol when i did a simple default gray test, you know, the scene that has no materials assigned. It rendered the scene before it even transfered the info to the first node. thats about when i realized that i was going to have to give nodes "real" work to do.

[Micha_cg]

Re: distributed rendering vfr4

Does the DR process not automatic upload the textures to the slaves first and than start the rendering?

[dalomar_cg]

Re: distributed rendering vfr4

I haven't been able to get it to load textures either...which unfortunately doesn't make it very useful (unless you do what Travis did and transfer them manually ). I'm also still getting the darker/brighter buckets (even with beta2). I have also tried it going from a 32 bit machine to a 64bit, and the DR process has worked...but not really any better or worse than doing it regularly. I've also had problems with special materials (vray2SdMat to be specific)transfering their properties to the slave machine.

Has any one tried DR when using textures on a network drive??(obviously twould have to be the same letter for each machine)

[Travis Serio_cg]

Re: distributed rendering vfr4

networked drive or mapped drive letter works.

[dalomar_cg]

Re: distributed rendering vfr4

networked drive or mapped drive letter works.

Thats good news...Thanks for testing that one out.

[joe_b]

Re: distributed rendering vfr4

Does the DR process not automatic upload the textures to the slaves first and than start the rendering?

No I don't do that now. I can - but if you have a lot of textures you are going to drastically reduce the speed of the DR process.