|
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
|
