Edit>Create Non Overlapping Cluster?
E.g
Polys 1,2,3,4 are in Cls A
Sel Polys 4,5,6,7
Edit>Create Non Overlapping Cluster
Cls B = Polys 5,6,7
> -----Original Message-----
> From: Andy Jones [mailto:andy(at)thefront.com]
> Sent: Wednesday, May 02, 2007 1:43 PM
> To: XSI(at)Softimage.COM
> Subject: Re: slight OT: they want what we got!
>
> Which reminds me -- I've been meaning to request some sort
> of non-overlapping clusters... Sort of like a miniature pass
> system with "partitions" for polygons. Like, there's a
> default cluster, and when you add polys to another one, they
> get pulled out of the default. Maybe what we really need is
> just some sort of generic "set manager" that attaches to
> things like clusters or partitions or groups and
> automatically manages the membership according to some set of
> rules and filters...
>
> - Andy
>
> Steven Caron wrote:
>
> > hmmm...didn't think about overlapping clusters...
> >
> > steven
> >
> > On 5/2/07, *Halfdan Ingvarsson* <hingvars(at)softimage.com
> > <mailto:hingvars(at)softimage.com>> wrote:
> >
> > 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>
> > [mailto: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 <mailto: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
> > <mailto: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
> > <mailto: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
> > <mailto: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 <mailto: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
> > <mailto:Majordomo(at)Softimage.COM> with the following
> > > >> >> text in
> > > >> >> body:
> > > >> >> unsubscribe xsi
> > > >> >>
> > > >> > ---
> > > >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
> > <mailto:Majordomo(at)Softimage.COM> with the following text
> > > >> > in
> > > >> > body:
> > > >> > unsubscribe xsi
> > > >> >
> > > >>
> > > >> ---
> > > >> Unsubscribe? Mail Majordomo(at)Softimage.COM
> > <mailto:Majordomo(at)Softimage.COM> with the following text
> > > >> in
> > > >> body:
> > > >> unsubscribe xsi
> > > >>
> > > > ---
> > > > Unsubscribe? Mail Majordomo(at)Softimage.COM
> > <mailto:Majordomo(at)Softimage.COM> with the following
> text in body:
> > > > unsubscribe xsi
> > > >
> > >
> > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM
> > <mailto:Majordomo(at)Softimage.COM> with the following
> text in body:
> > > unsubscribe xsi
> > >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM
> > <mailto:Majordomo(at)Softimage.COM> with the following
> text in body:
> > unsubscribe xsi
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM
> > <mailto: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
