Render Farms 2005-04-08 - By Bernard Lebel
Back
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
|
|
