You just described the heirarchical render setup tool I wrote a few days
ago. Basically, it lets you define properties, partitions, overrides and
render options at a job, scene, pass or group of passes level, then you
define individual passes, partitions, overrides, etc. that descend from
parent jobs, scenes, passes or whatever. That way, depending on where you
define things, you can avoid setting up the same thing multiple times.
I'm not sure what the easiest UI for this sort of thing would be. Maybe
some sort of tree that lets you define things at any level of the tree,
and preview the fully propagated tree and what will happen if you merge
several trees in a specific order.
-Andy
On Tue, June 6, 2006 12:00 pm, guillaume laforge wrote:
> Interesting thoughts !
>
>
> Just to faire avancer le smilblic*, I think of a new type of property,
> the "ForPartitionThing". You apply ForPartitionThing on several partitions
> and they will share it as objects do with materials. This way if you
> duplicate a pass you can choose if the "ForPartitionThing" is global or
> local. If you want to edit a ForPartitionThing it will change all the
> partition using this property.
>
> On the same idea we could use an other type of property, the
> "ForPasseThing". If you duplicate a pass and apply the same
> "ForPasseThing"
> , the only thing you can change between those two passes are the render
> option parameters. This way if you add a partition in one pass, the other
> pass will be updated the same way.
>
> I don't explain more in death as I've got no idea how to design such a
> beast ( maybe a tree type relationship editor like Kim told ).
>
>
> My weird 1/2 euro
>
>
> --
> Guillaume Laforge
> freelance TD | cg Artist
>
> Cheers
>
>
> * French term : something like "trying something but not sure if it is
> very interesting"
>
>
>
> On 6/6/06, andy(at)thefront.com <andy(at)thefront.com> wrote:
>
>>
>> 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
>>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
