“overrides from partitions had biggest performance gain so far”.
ok, so if you put all objects in a partition and put a default phong material
on the partition (rendering everything as grey phong, no textures, no
displacement...) – does it become really fast (or normal speed)?
there are different ways to use overrides on partitions, and they have some
caveats/consequences.
if you add an override material on a partition, you are replacing the
material/s of the object/s completely with this material. it comes at very
little performance cost – use at will, but keep in mind that if objects have
displacement for instance you are loosing that too.
if you put an override on say the surface port, and plug something in there,
something quite different is going on – if you look at the material, you will
see that a new branch replaces what was in the surface port, while keeping
everything on all other ports. (great, you get to keep the displacement and
so). But this has some important consequences for performance. The way this is
handled is that for every affected material, a duplicate is made, which is
modified. (you can see this in the explorer if you look at the material
libraries). if there is one object in the partition it hardly matters. If you
have thousands of objects though, each with their own material, this can
seriously slow down scene interaction and rendering.
And you can do more than one thing in an override: override various ports on
various shaders, override parameters, add properties, all at the same time –
which complicates things even more. I’ve seen production scenes increase up to
30 fold in size when breaking out passes - switching passes in the interface
would take up to 30 minutes! It was faster just to kill the scene, edit the TOC
to switch to another pass and reopen the scene – which in itself was fairly
slow as well.
We spent some time on the rendering pipeline to do things another way, and
avoid some of the pitfalls of overrides – and it made a huge difference in
performance as well as the daily life of the artists.
If your scene is really pushing the hardware’s capabilities as it is, and you
add fancy overrides – you can make the scene unmanageable.
Without going in too much detail – if you can nail it down to the overrides
being the cause for slowdown – perhaps you can approach them differently, and
get the result you’re after, with less of a performance hit.
Now I come to think of it – there are different ways to render passes.
One way is to render one pass completely, then switch to the next pass and so
on.
Another is to render the one frame for all passes, then the next frame for all
passes and so on. This approach can be very ineffective and cause considerable
slowdown or become unstable with complex scenes and overrides.
Say it takes a minute to switch passes, and you have ten of them. If you render
with skip frames that way, it would take 10 minutes per frame, to render
nothing at all - and many machines on the farm could be doing it at the same
time.
A render manager should avoid all of this, by telling the machines which frames
to render - so they don’t need to verify it themselves using skip frames – as
well as avoiding switching passes – for instance by sending each pass as a
separate job – and giving priority to the machine/s already working on a
certain pass, to continue on it.
From: Ales Dlabac
Sent: Thursday, March 26, 2015 9:16 AM
To: softimage
Subject: Re: Fwd: very slow skip frame
Yes you are right with difference between viewport skip and render skip what we
are dealing with is the rendering skip.
it's is happening on renderfarm and as well as in local GUI session. There's no
simulation just non simulated ice tree, our findings so far showing us that if
we delete part of the scene objects than it will gain some speed back but
doesn't matter which part.
In other words there isn't particular object which is causing the slowdown only
amount of objects. We are using Arnold and we tried to replace some geometry
with ass standins, this helped a little. We also suspected udims textures from
confusing XSI as not existing texture paths but with no luck.
Regarding network traffic overload even if we removed all external resources
like textures from scene it didn't help. Removing overrides from partitions had
biggest performance gain so far. We keep searching.
On Wed, Mar 25, 2015 at 1:37 PM, pete...@skynet.be wrote:
just a few stabs in the dark:
is this on renderfarm / using a rendermanager?
is there any simulations (not just ice, also syflex...) ?
if so, any chance that the caches aren’t working and it’s simulating – on
each machine?
lot’s of huge textures or other data from a shared server that isn’t up to
the task?
how is the pre-render time?
there is a big difference between skipping frames in the viewport and
skipping frames while rendering – which is: rendering. so any render
