Doc talk:2.6/Manual/Render/Performance/Netrender
Review…
At first glance
Saving the file first(it sends the last saved file at this point) is the first thing to look at right now, and the target output directory should be accessible for change when in network render/client mode.
I suggest to allow the user to change the output format of images from EXR to other formats.
Other things that need some attention
The connection management seems a bit brutal at this stage and although not crashing ( yeee :D ) it happily returns tons of errors concerning broken and forcibly closed connections.
Need test users
Definitely need some people testing this, if you want to test this feature and you have no network don't worry! Blender 2.5 easily runs 3 x on an old p4, so no need for multiple computers in your (initial) test environment.
Conclusion
That said it seems an awesomely powerful addition to blender, one that definitely deserves to be further developed !
Addition by NpsIt1 (Mar 17, 2012):
Initial observation: I've been using Netrender at my workplace, with 13 machines total:
(1) 2 core client (winxp pro, 32bit) (1) 2 core master (winxp pro, 32bit) (2) 2 core slave (winxp pro, 32bit) (2) 4 core slave (win7 pro, 64 bit) (4) 16 core slave (server 2008, 64 bit) (2) 4 core slave (server 2003, 32 bit) (1) 2 core slave (server 2003, 32 bit)
It seems that part of the problem with returning errors is that the master does not wait long enough for the slaves to return a rendered frame. Obviously a 2 core processor won't be nearly as fast as a 16 core server. If I try to render a material with a mirror surface and transparency, it takes much longer and causes errors. When they slaves are rendering, they will also disappear from the slaves listing, probably for the same reason the master thinks that there are errors during rendering. During a frame render, with Blender eating up so many compute cycles, it may cause the other computer services to stall until there is a break in the render sequence, so maybe every 9 seconds, there should be a 1 second pause in the render engine on each slave machine so they can report back to the master that they are still rendering, and also report back a % done of the frame or chunk. I have my chunks set to 1 frame, and it slightly decreased the error rate, mostly among the servers. The other boxes still take a long time to render so it didn't really help those.
Trying to bake on the network just causes a "refused connection" error from the master and makes the slaves try to render until I delete the job from the temp folders they render in.
It would be nice to be able to stop a frame render while it is rendering. It seems currently that I have to wait until it finishing rendering before it will stop the render process, which may be related to the first paragraph about the compute cycles Blender takes up and the master dropping slaves from the list. If I delete the job, it stays on the master until each of the slaves is finished rendering their chunks. So if I try to render again, I have to wait until they are all done, which may take a long time, depending on the scene I am rendering.
Summary:
Overall, this will be a fantastic tool to utilize, once the kinks are worked out. Kudos!
