Page 1 of 1

animation vs distributed render...

Posted: Thu Aug 17, 2006 11:33 am
by naxos
I've posted here a serious limitation using distributed calculation with animation...

http://www.maxwellrender.com/forum/view ... sc&start=0

in 2 words :
when sending an animation with network rendering, each PC renders a single frame (instead of all PCs rendering the same frame)...
Problem is if you have some X2, some P4, and some CoreDuo PCs... they all render at different speed...

so, if you ask 2 hours per frame, some PCs will give grainy pictures and some others won't...

and that IS a big problem !

Posted: Thu Aug 17, 2006 12:09 pm
by tom
Hi Naxos,

Instead of time, we suggest you using Sampling Level as a termination critera when rendering animations on your network. The following steps may help you:
- Make a test render and find a satisfactory sampling level for your animation. (eg. SL 16)
- Send frames across the network with setting the parameter -sl:16 and the time something like -t:9999 which will prevent an immature termination due to time.

Best regards,
Tom

Posted: Thu Aug 17, 2006 12:15 pm
by naxos
Hello Tom,

thank you for answer...

I've thought also using SL as a solution...

but for short film animation, we do need to manage the rendertime preciselly, as you know...

Won't it be possible in future version to just ask all network to act on animation just like it does for one distributed picture rendering ?

so we can set rendertime to 20minutes ofr ex. on 50 PC and at least rendering films ?

regards.

ps : from my first use of MX, i can read your posts / tips, etc... so big big thank you for all you've done yet !

Posted: Thu Aug 17, 2006 12:22 pm
by tom
Yes, I can understand you need a time-per-frame critera for your plans. However I think you also agree this is not a Maxwell based problem but it's related to having different computers in your farm and the situation wouldn't be different with any other engine. There are other solutions to this problem. You should either use same hardware rendernodes for being able to use a fixed time or you should try cooperative rendering. With cooperative rendering you can engage all nodes for a single frame, so this will let you define time as a termination factor while keeping the quality of frames along the animation same.

Also thank you for your nice words, it's pretty motivating hearing them. I'm very glad to be helpful.

Best regards,
Tom

Posted: Thu Aug 17, 2006 12:47 pm
by naxos
I agree... more or less ;-)

FinalRender for ex. always render in bucket manner, so the whole network is rendering the current frame...
Of course, in case of disparate network PCs, some fast ones will render two bucket while another PC will render only one... but all frames will have the same rendertime, statistically...

i'm not coder (well i was during ATARI ST's GFA basic ages...) but i think changing the network part that tells MX "it is an animation, each renderNode will render one frame" into "it is an animation, but ok, i'll act like usual as if it was simply some frames one by one, so in real distrib manner".... seams not so hard...
did i miss something ?

Posted: Thu Aug 17, 2006 1:02 pm
by tom
...but all frames will have the same rendertime, statistically...
Sorry, I couldn't understand this. Slower machines will reach the same result in longer time, no?

Posted: Thu Aug 17, 2006 1:25 pm
by naxos
if you have let's say a 'classical' PC, renders at 100% speed.
then a X2 : 180% speed
and a 3rd : core duo : 270% speed...

if each PC renders a 3 frames animation, each PC renders a single frame, in a given rendertime (1hour for ex.), you agree that you'll get 3 different quality, regardless of witch PC rendered the frame...
toll rendertime will be 3 * 1h = 3h...
Solution is to ask for a given SL... let's say it asks 2h to reach the wanted SL on the fast PC... toll rendertime will be the slowest PC's rendertime to reach SL, and so for each frame... so if 2h is for the fast 270% PC, we will get minimum of 2.7 * 2h to get the 3 frames (fast and medium PC will finish before and wait) = 5.4 h.

if now you think about for my vision of anim distrib render...

If all PCs are rendering one single frame each time...
2h is for 270% fast PC ok ? so if we put the 3 PCs, it is +- = 100+180+270 % = 550%... so to reach the same SL, we need 2h * 270 / 550 = 0.98 hours (59 minutes...)
for the 3 frames anim, it gives us 3 * 0.98h = 2.94 h, let's say 3h...
so, it is faster to get rid of that animation (not faster, but we don't have waiting PCs then), and more of that, all frames will be the same quality...

I hope it is clear to understand...

and i appologies for my approx. english ;-)

Posted: Thu Aug 17, 2006 1:34 pm
by tom
Yes, now your wish is clearer. You suggest auto detection of termination time for given quality per hardware. It's not impossible for sure, but it needs more investigation and benchmarking factors we're already studying for a long time. However, given SL would automatically engage the machines that long while making sure of final quality more precisely. Because in your scenario an external factor (a user action or a resident software) may slow down the computer from time to time during this render process which would break the expected result. You can still run a testrender with one single frame and take notes of some parameters practically. However, I wouldn't suggest this as a good solution due to possible changes of scene complexity along frames. Unbiased approach makes it quite hard to determine required time per frame at different entropy levels.

Best regards,
Tom

Posted: Thu Aug 17, 2006 2:51 pm
by naxos
that is why i'm requesting to possibility to let full network working on a single frame when rendering an animation...

In fact, it is the way it goes when network-rendering a single frame...
just please let user to choose between 2 options when rendering over a network / renderfarm :

1 - each rendernode renders one single frame (what is now the default way)

2 - each frame is rendered by all rendernodes in a distributed way (like when rendering a single picture)...

i'm quite sure it is not a big deal to change animation management into a "several frames"...

Posted: Tue Aug 22, 2006 5:21 am
by Maxer
Naxos, I don't understand why you are having any problems, the two ways in which Maxwell renders (network rendering & cooperative rendering) do exactly what you are asking for. If you want all of your computers to work on one frame of an animation they can do that it's called cooperative rendering. You would have to submit each frame of your animation separately in order for Maxwell to do this but it is possible although I don't know why you would want to do it this way. It's much more efficient to allow your entire render farm to render out separate frames of an animation rather than have the whole farm work on one frame at a time. I see no need for it to work any other way and in the end I don't believe you would finish your animation any quicker using the entire farm to render one frame at a time.

Posted: Tue Aug 22, 2006 9:48 am
by naxos
Maxer, i think you did not understand my explanations...

never mind... or re read my second last post...

submit each frame of a 2000 frames animation is a pain...

Posted: Tue Aug 22, 2006 5:26 pm
by Maxer
naxos wrote: submit each frame of a 2000 frames animation is a pain...

I realize that, and I know that's not what you want to do, but my point is that even if you could submit all 2000 frames and have all the computers work on one frame at a time I'm pretty sure you wouldn’t finish the animation any faster than if you had done one frame per render node. The reason I say that is because you would have to merge all the MXI files for each image which would require a long time to do, so you would in effect be adding additional render time to an already slow process.

Posted: Tue Aug 22, 2006 5:42 pm
by naxos
Agree, that is one more reason for NL to make distrib / coop animation rendering more efficient ;-)

Posted: Tue Aug 22, 2006 5:59 pm
by Maxer
I can't argue with that, right now I'm trying to render out a 900 frame animation and the MXS files are taking up about 200GB of space, plus it's taken about 15 hours to export all those frames. It's really ridiculous that each frame of the animation has to export the entire scene file, there has to be a better way.