Polygon clusters already are a type of a meta-object (actually a sub-object is more apt).
The fun part starts when you have to consider overlapping clusters and visibility overrides on them. For example: Cluster A and B overlap. If you set cluster A to be non-visible (render/viewport), will it reveal the overlapped section covered by B?
- ½
-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Alan Jones
Sent: 02-May-2007 07:29
To: XSI(at)Softimage.COM
Subject: Re: slight OT: they want what we got!
Yeah, but it's so annoying to go digging in there. ;-) Oh and I forgot to mention being able to add them to groups/partitions which would override inherited properties the same way groups/partitions override branch inherited properties etc now.
Cheers,
Alan.
On 5/2/07, Andy Nicholas <andy(at)andynicholas.com> wrote:
> 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
>
---
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
