>...If I'm not misunderstanding the
> setup you're describing, I think it also has the problem that you can't
> override the same material on two different clusters two different
> ways. So, for example, if you want to make a set of objects blue and
> another set of objects green, you can't really gaurantee that it's
> possible if you're using cluster materials.
I completely agree Andy. For this scenario, it is not really an "override cluster material" problem but just the actual design of cluster object in xsi.
To be able to drag and drop clusters in partitions could be handy but it could be really messy too. A such re-design work doesn't look simple.
Maybe a "Partition Material Manager" showing only objects, clusters and materials like this :
partition A :
____Material A used by "objects A" and "object Z.cluster 1".
____Material B used by "objects Z" and "object A.cluster 1".
partition B :
____Material A used by "objects C" and "object Z.cluster 2".
____Material B used by "objects D" and "object A.cluster 2".
The UI will have to be extremely user friendly to avoid headache ;-).
> I think we need a) a much improved implementation of the "texture map"
100% agree. "texture map" are really useful and to be able to apply them on a cluster would be nice. Again, it looks like a re-design of the actual cluster object.
About the texture map property, it could be really useful if we could use them for the bump too...
1/2
--
Guillaume Laforge | La Maison
On Wed, 02 May 2007 01:03:50 +0200, Andy Jones <andy(at)thefront.com> wrote:
> This is my experience as well. The hack of getting at cluster materials
> through proxy objects, while occasionally a useful hack, isn't really a
> scalable production-worthy strategy. If I'm not misunderstanding the
> setup you're describing, I think it also has the problem that you can't
> override the same material on two different clusters two different
> ways. So, for example, if you want to make a set of objects blue and
> another set of objects green, you can't really gaurantee that it's
> possible if you're using cluster materials. Also, this doesn't give you
> cluster visibility control, or overall material overrides. Just shader
> overrides.
>
> I think we need a) a much improved implementation of the "texture map"
> property that works with clusters and allows mapping of values, textures
> and shader sub-trees, b) a way to put clusters in partitions (with some
> of the logical conundrums worked out. Like, is every cluster in the
> background objects partition?), and c) a thing I've never actually heard
> anyone ask for yet:
>
> Multiple partition sets. Currently, in each pass, you get one set of
> partitions and they're mutually exclusive. So, you have to define
> properties at the most granular level, with objects sorted into lots of
> highly specific categories. Instead, I'm proposing that it should be
> possible to have sets of partitions grouped together so that they're
> only exclusive within each group. That way, you could have, for
> example, a dedicated partition set just for dealing with visibility.
> Then, you'd do all your shader stuff elsewhere. In the current
> implementation, you end up with a horrible multiplicitive relationship,
> the more things you try to control, forcing you to need lots of
> partitions with highly specific behaviors that are difficult to
> understand. I think with objects, it's not so bad, but once you start
> partitioning at the cluster level, you really need something more
> specific. Especially since overrides for clusters often work a little
> differently than overrides for objects.
>
> - Andy
>
> Graham D Clark wrote:
>
>> Hey Guillaume, yeah thats similar to the technique I setup on Barnyard
>> for subassets, using dummy geo as a standin and presets to switch to
>> various subassets so we didn't have to have tons of extra models of
>> characters with only a few parameter differences.
>> Unfortunately things change in a story and we have to rebuild assets
>> and then automate the cluster overrides and presets, and for some damn
>> reason it didn't always work (not suprising being a kludge) requiring
>> manual eval by a TD each time.
>> And you've touched on our tracking issue requiring attaching a node to
>> the model.
>>
>> Regarding passes SDK no its not impossible, we did it too, it just
>> wasnt as pleasant as the rest of XSIs areas via SDK (except for
>> fxtree), The partitions part still needs work.
>
>
> -
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
