|
That's a nice idea. There are a couple of potential problems I can
think of, but they might all be solvable. One is that objects are
really heavy in XSI. One of the big reasons we use clusters is to make
our scenes lighter. Another problem is that a lot of properties of the
cluster (most notably visibility) are effectively overridden by the
properties of the object in some sense. So, you'd have to find a way to
make the interface and implementation consistent. I think ultimately,
it doesn't really make much difference whether the clusters look like
objects or not, because they fundamentally can't work like objects.
Unless they can... But to me, the concept of a polygon cluster makes a
lot of sense. We just need the ability to control them a little better.
On the other hand, something similar that I think could be useful is a
nice, integrated way to make "blown apart" objects, where you have
several objects that are essentially extracted polygons from one single
mesh. For example, this could be a way to get a lot of control over
different parts of character meshes, where for the purpose of enveloping
you want a single mesh, but for materialization and passes, separate
objects are beneficial. So, if you've got a character where the clothes
are sort of attached to the skin, you can still deal with the skin and
clothes like they're totally different objects. You can of course do
this sort of thing in the software in several ways already, but it's
ugly. Of course, if clusters are improved a little, the need to do this
sort of thing decreases. But there are still probably cases where you
want smooth, continuous surfaces that behave like multiple objects.
- Andy
Alan Jones wrote:
Why not just have clusters appear as objects instead? Or at least a
metaobject which has an unfreezable history linked to the cluster
under the original object? Disable applying materials onto the
original cluster and only have them apply to the metacluster object. I
can't see any disadvantage to having the metaobject fixed underneath
the original object.
Cheers,
Alan.
On 5/2/07, Guillaume Laforge <guillaume(at)alamaison.fr> wrote:
>...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
---
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
|
