Seems like no one (including myself) is really using layers and partitions
in concert. It's too bad, though, because if you use both, you can get a
sort of mutiplicative relationship where, for each layer, you can control
different partitions somewhat differently. For example, consider a scene
with two characters in an environment. Typically, one might render this
using a set of passes (diffuse, spec, etc) for the environment and for
each of the characters (for the sake of example, suppose for the moment
that there's a compelling reason not to render the characters together --
say, one has animation that's likely to change, and they don't interact).
To do this with just partitions, you'd need a set of partitions to divide
up the background and each of the two characters. For us, we often end up
with 3 or 4 partitions per scene element (such as the environment or the
character or whatever). So, if we have two characters, that's 3 x 4 = 12
partitions. Or for 5 characters, it quickly gets out of control with 6 x
4 = 24 partitions. And worst of all, if we want to change the way a
character partition works, we are stuck recreating the partition change n
times for each of the n characters. Obviously, this would be a terrible
way to work, and we don't work this way, but bear with me. Maybe a better
example is a scene that's only renderable in chunks of geometry...
Anyway, using layers with partitions, this problem could basically go away
because we can keep a master scene with each of the characters in a layer,
and use just one partition set for foreground and one partition set for
background. So we'd end up with a consistent set of 8 partitions that
never requires modification for hiding and showing different characters in
the scene. Then, when we want to check the renderability of a layer, we
just hide all the character layers we don't want rendered. Obviously, you
lose the advantage of having one monolithic scene, since there's no
built-in layer configuration switcher, but you gain a reasonable scaleable
render structure for multi-layered, multi-pass rendering. And the process
of splitting off render scenes based on existing layers is both simple (by
only having one set of visibility switches to control instead of a set for
each render pass -- spec, diffuse, etc) and automatable. In practice, you
might want to just delete the objects in the hidden layers just before
rendering anyway, to save memory, so you'd be breaking out scenes either
way. Too bad deleting takes so long...
Interesingly, if you restrict the settings you override in both layers and
partitions to just a single explicit value and a "leave alone" behavior,
the propagation becomes commutative, and it no longer matters which of the
layers or partitions (or any of a large number of groups) is applied
first, resulting in a much simpler, more robust system. For example, if
you never use the "show" option in any visibility property, you can verify
for yourself by considering all the possibilities that it doesn't matter
which order the overrides are applied in. If any one of the overrides
sets the value, nothing can reverse that override, so the value propagates
all the way to the end. Otherwise, the default value propagates. You
could apply this generally to common boolean overrides, like secondary
rays, whereby you never override secondary rays to be on. You either
override them to be off or don't override them at all. By doing this,
each layer of property propagation has the ability to turn off secondary
rays without having to worry about its setting being overridden later by
something with higher precedence. Obviously, the system breaks down with
non-boolean values, but I've found those to be overridden pretty rarely in
practice.
I believe it can be shown that any resulting assigment of a set of boolean
values achievable using direct overrides (hide/show) can be achieved using
this sort of set/don't set boolean behavior instead. The key is just to
make sure everything starts out with the value you can't assign directly
("show" or "secondary rays on" in my examples) by default, and you have to
do a little more work for objects that only occasionally need the default
value, such as proxy objects that would normally be "unhidden" in a
conventional hide/show workflow.
The alternative of dealing with partition/layer collision I assume works
fine too, but based on the fact that none of us seem to use them together,
it seems like maybe it's just too hard to keep track of. Plus, in a
pipeline like ours or Bernard's, where the layering and the partitioning
are done at different stages, what seems consistent at an earlier stage
can cause chaos for a later stage. Doing things this way allows each
stage to be transparent, in the sense that it's no different from dealing
with a default scene setup with objects hidden and shown, regardless of
what's going on in the other layers of property application (even the
"later" ones).
Just to be clear, I'm not suggesting that we shouldn't have a show option
in the visibility settings for group-like objects, but just that in some
workflows it might be advantageous to strictly avoid using it, thereby
eliminating the most common precedence problems. Something to think about
anyway.
-Andy
On Tue, June 6, 2006 6:56 am, guillaume laforge wrote:
> A central window sound good but in fact I'm convinced lot of user ( or
> just me ? ) never open those special windows. I think about all the
> relational view we can find in XSI and that I never use...
>
> Maybe it could be better to improved what xsi users are used to ? For
> example, the explorer in pass scope could show partitions visibility
> (icons
> or little table like layer, I don't know...). I always try to name
> partition with their visibility setting ( "Characters_Hide" for example )
> just to be able to see those setting at a glance.
>
> Explorer is a great tool to check objects properties, I'm not sure that
> an other window is a good idea. As there are more and more people doing
> scripts with XSI I'm sure than a "relational view octa-pane" with groups,
> layer, partition control will be released soon if needed.
>
> Just my opinion.
>
>
> Cheers
>
>
>
> --
> Guillaume Laforge
> freelance TD | cg Artist
>
> On 6/6/06, Luc-Eric Rousseau <lucer(at)softimage.com> wrote:
>
>>
>>> -----Original Message-----
>>> From: Tim Leydecker
>>>
>> [...]
>>
>>>
>>> P.S: Hey Kim, I didn´t want partitions not to have priority over
>>> Layers - I just felt it worth noting that managing these interferences
>>> could be optimized through a global collection of parameters in a
>>> ppg. But then, that would collide with Luc´s determination to bring
>>> the amount of windows in XSI down to the absolutely required minimum
>>> and may also prove dogslow in refresh (given the amount of partitions
>>> Bernhard seems to throw into an average scene :-)
>>>
>>>
>>>
>>
>> Actually having a central window where you'd have all the rendering
>> information, passes, partitions, render options, etc, both in an
>> overview mode and for individual editing, is something I'd like to see
>> in the future. It makes more sense IMHO to have a render setup view
>> than having a render toolbar with a few commands that don't seem to have
>> any effect in the viewports, then needing to open explorers and property
>> pages to figure it all out. It's too generic; managing all that stuff
>> is something you can spend a lot of time doing so it's worth having
>> everything in once place. This would need to be prototyped by someone
>> using a Relationnal View.
>>
>>
>> ---
>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
>> body:
>> unsubscribe xsi
>>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
