|> From: softimage-boun...@listproc.autodesk.com
> > |> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf
> > |> Of Morten Bartholdy
> > |> Sent: Monday, May 23, 2016 10:43 AM
> > |> To: Steve Parish; softimage@listproc.autodesk.com
> > |>
|> -Original Message-
> |> From: softimage-boun...@listproc.autodesk.com
> |> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf
> |> Of Morten Bartholdy
> |> Sent: Monday, May 23, 2016 10:43 AM
> |> To: Steve Parish; softimage@listproc.autodesk.com
> |> Subj
Parish; softimage@listproc.autodesk.com
|> Subject: Re: Maya the server destroyer
|>
|> Hmm - we don't really have any problems with Maya and RR
|> even on large scenes. As Ed said, when simulating, cache
|> locally and distribute the cache to render clients in a
|> local tem
Hmm - we don't really have any problems with Maya and RR even on large scenes.
As Ed said, when simulating, cache locally and distribute the cache to render
clients in a local temp folder - this lightens the network load quite a lot,
and definately use tiled, mipmapped textures if your renderer
Hi
Scenes:
- Yes, Softimage is the only application that supports multi-machine skip
frames. RR has a workaround for some render apps, you
have to enable "Keep scene open".
- Enable "local scene copy". This copies the scene file once to the client. You
might get issues if xgen files, textur
ene at every frame? I was thinking only 3dsmax had
>> this awful behavior. If they would know how elegant softimage batch
>> rendering actually is…
>>
>>
>>
>>
>>
>> From: softimage-boun...@listproc.autodesk.com
>> [mailto:softimage-boun
> *Sent:* Friday, May 20, 2016 10:13 PM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Maya the server destroyer
>
>
>
> It's not Maya's fault. It's how the render manager, in this case Royal,
> has its options set.
>
>
>
> There is s
image-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ed Manning
Sent: Friday, May 20, 2016 10:13 PM
To: softimage@listproc.autodesk.com
Subject: Re: Maya the server destroyer
It's not Maya's fault. It's how the render manager, in this
mage batch
> rendering actually is…
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ed Manning
> *Sent:* Friday, May 20, 2016 9:15 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:*
Sent: Friday, May 20, 2016 9:15 PM
To: softimage@listproc.autodesk.com
Subject: Re: Maya the server destroyer
* use the "render local" option, which writes the images to a temp
directory on the render machines, then copies to the server.
* set chunk size to a large number t
check your logfiles to see where the biggest latencies are.
On Fri, May 20, 2016 at 3:30 PM, Ed Manning wrote:
> and stagger the start times -- Royal might have a built-in delay option
> for this. that way the machines don't all hit the server at once for the
> same files.
>
>
>
> On Fri, May 20
and stagger the start times -- Royal might have a built-in delay option for
this. that way the machines don't all hit the server at once for the same
files.
On Fri, May 20, 2016 at 3:28 PM, Ed Manning wrote:
> and if your renderer supports proxies (I think most of them do), use them!
>
> On Fr
and if your renderer supports proxies (I think most of them do), use them!
On Fri, May 20, 2016 at 3:14 PM, Ed Manning wrote:
>
>- use the "render local" option, which writes the images to a temp
>directory on the render machines, then copies to the server.
>- set chunk size to a lar
- use the "render local" option, which writes the images to a temp
directory on the render machines, then copies to the server.
- set chunk size to a large number to minimize the number of times the
scene has to be loaded by the network machines
- turn off any unnecessary aovs
- t
14 matches
Mail list logo
