Sounds good.
Actually, if they implemented it like that, they could just place the meta
objects in the same place as the clusters currently are... and call them
clusters ;-D No need to tell anyone anything - except the improvement in
cluster functionality!
> Hi Andy,
>
> Well I was thinking with the metaobject (object fixed underneath the
> original mesh) that it would be pretty consistent with current XSI
> behaviour beyond being fixed.
>
> So by default it would inherit visibility etc from the parent object
> (that would be a difference between a real object - it could inherit
> local properties from it's parent as well as branch ones). Though you
> could still make local versions of them etc.
>
> I'd probably see implementing it as being done by keeping the existing
> cluster system in place, but having the ability to create a
> meta-object from clusters (possibly only polygon clusters as they
> relate directly to renderable items whereas edges etc don't).
>
> Limit materials to only being appliable to objects (and meta-objects)
> - i.e. remove that from clusters to ensure consistency. Backwards
> compatibility would just convert clusters with materials to
> meta-objects and apply the material.
>
> Meta-objects should only behave like objects for the purposes of
> properties (like visibility) and materials. They should have no
> construction history etc as the stack already has operators which can
> only be applied to clusters.
>
> This would give you a robust framework for handling properties on
> clusters while maintaining consistency with the rest of the
> architecture. It also doesn't require the overhead of a real object
> (such as a transform state etc).
>
> Cheers,
>
> Alan.
>
> On 5/2/07, Andy Jones <andy(at)thefront.com> wrote:
>> 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
>>
> ---
> 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
