Render Farms 2005-04-08 - By kim aldis
Back
Batchserve started off with all the right things in place but it's suffering
right now from lack of dev resources and in may respects it's quite
seriously lacking and quite a few of the points Bernard raises aren't
specific to them. No disrespect if you're listening in Olivier but:-
It's a nightmare to set up and get going.
Lack of easily accessible output from jobs - when things aren't working, or
even when they are, it's a right royal pain to dig around and figure out
what's going on
No accessible history of renders and their states.
It should email you when done or failed.
It's extremely prone to hanging.
Linux: anyone doing any serious rendering shouldn't be using Windows.
Batchserve doesn't do Linux.
The nature of the way it renders makes it prone to incorrect renders where
some simulations are involved.
It does only XSI
It won't render Fxtrees.
It won't run scripts.
I'm sure I could think of more.
My experince, by the way Bernard, is that render reliability is more to do
with scenes than Xsibatch. I've found this latter to be pretty solid so long
as scenes aren't under-optimised or just too heavy.
> -- --Original Message-- --
> From: owner-xsi@(protected)
> [mailto:owner-xsi@(protected)] On Behalf Of Marc-Andre Carbonneau
> Sent: 08 April 2005 15:26
> To: XSI@(protected)
> Subject: RE: Render Farms
>
> Oh I see.. so it had to do more with the way your pipeline
> was setup and also your network problems... it seems to run
> pretty well here. Thanks to Biju for that!
>
> mac
>
> -- --Original Message-- --
> From: owner-xsi@(protected)
> [mailto:owner-xsi@(protected)] On Behalf Of Bernard Lebel
> Sent: Friday, April 08, 2005 10:04 AM
> To: XSI@(protected)
> Subject: Re: Render Farms
>
> Well, so many things!
>
> First, we added many functions to verify the result of a
> rendering, in case of an invalid result, it would attempt two
> more times to render the frame.
> BatchServe would sometimes do the rendering of the job, but
> not write the frame to disk at all.
> Also, when we had crashes, restart of clients or restart of
> the server, we'd get 1k frames.
>
> We had many refresh problems, of all kinds. So we had
> functions to force refreshes of scenes upon loading.
>
> To deal with hairs, we also had several custom functions.
> First, it would detect if it was a hair job. If so, it would
> deactivate any elliptical filtering in the scene. All kinds
> of things like that.
> Plus, when a character scene was loading on the farm, the
> client would replace the ref model by a local model version
> (wich had slightly different parameter values), so less
> problems afterward.
>
> Because of highly problematic network overhead, character
> textures were both on the network and on each render client.
> Users would work and save scene using the network locations,
> so when the scene was loading on a farm client, paths needed
> to be converted to the local locations.
>
> The list goes on.... pretty all this code was not to refine
> batchserve, but to bring to an acceptable level of
> reliability, an important of this lack of reliability not
> caused only by Batchserve but also because of XSIBATCH.
>
>
> Plus for some reason several of the MySQL priority rules were
> not respected by the clients, so we had to edit these rules.
>
>
> Cheers
> Bernard
>
>
> On Apr 8, 2005 8:29 AM, Marc-Andre Carbonneau
> <marc-andre.carbonneau@(protected)> wrote:
> > Hey Bern,
> > What do you mean lots of custom code? What were you missing
> from it at
> > Action Synthese?
> >
> > MAC
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in
> body:
> unsubscribe xsi
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following
> text in body:
> unsubscribe xsi
>
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
