 | | | programmatically accessible many to many relationships | programmatically accessible many to many relationships 2005-03-04 - By softimage@(protected)
Back
Maybe an alternative could be to add a custom parameter set on the related
objects, with only a single parameter (one that is animatable). Than having the
objects proxied with the "master". So in theory if you change names, it has no
impact on "links".
I use a similar approach with my lighting toolset. Every light created with this
toolset has a cpset with an ID parameter (an integer slider), every referenced
object (not ref model) have this parameter proxied to the "source". Then
scripts can traverse the scene to collect ID numbers and act on those matching
a specific one. Therefore, there is no need to maintain lists.
Cheers
Bernard
Quoting kim@(protected):
> the issue here is not how to store the references, that's easy. real The
> problem is how to ensure that they update on name change or dissolve on
> delete. One thought would be maybe to set up a bunch of constraints on the
> objects and mute them? Messy but doable?
>
> softimage@(protected) writes:
>
> > One simple way to handle this could be to attach annotations to objects
> that
> > will list the related objects. Once in a while you would have to update
> these
> > lists with a script. Not very elegant from a technical perspective but if
> you
> > remember to update lists that could work.
> >
> >
> > Cheers
> > Bernard
> >
> >
> > Quoting Brad Friedman <xsibrad@(protected)>:
> >
> >> I'm looking for a good way to manage programmatically accessible many to
> >> many relationships.
> >>
> >> In other words... I have a whole mess of meshes, curves, clusters and
> >> nulls. I want any given object to be able to contain a list of any
> >> number of other objects in the scene. I want the lists to remain valid
> >> through object name changes.
> >>
> >> In my specific application that I'm working through, I have curves that
> >> are used as templates to create muscles. I have meshes with nulls as
> >> children (mini rigs with constraints and scops and all that jazz) that
> >> are the muscles. I have clusters on other meshes (character's envelope,
> >> or skin) that need to be cage deformed to the muscle meshes.
> >>
> >> I can set up the whole rig manually and it works great. But I'm looking
> >> into extending my toolkit to sort of... regenerate the muscles and bind
> >> the skin via cage deforms (and probably other methods while I'm at it)
> >> procedurally. Because I'm finding a good amount of the work of tweaking
> >> a muscle rig involves seeing how it deforms... then changing the
> >> underlying muscle and re-binding the rig. Sometimes you want to build a
> >> new muscle. Or Build 3 to replace the one. Sufficed to say, if I could
> >> automate the skin binding process, this would go much quicker.
> >>
> >> I'd like the skin clusters to maintain lists of muscle creation curves.
> >> I'd like the muscle creation curves to maintain a list of muscles
> >> created from them. The rest of the setup should be trivial. But I'm
> >> kind of new to XSI scripting and programming so I'm not sure how best to
> >> accomplish this without a name change messing the whole thing up.
> >>
> >> I thought of using groups but unfortunately, groups don't seem to be
> >> able to be properties of most objects... only models (is this correct)?
> >>
> >> I thought of somehow throwing an array of strings on the objects which
> >> would hold other object names... but then a name change breaks the whole
> >> system.
> >>
> >> In maya (I know I know... "groan... maya") I would approach this by
> >> creating a named parameter of type "message" (which is basically a null
> >> parameter type) with multiple connection capability [0-N]. Then I'd
> >> just make connections willy nilly from other objects "message" ports to
> >> the new parameters... resulting in nice easily workable many to many
> >> relationships.
> >>
> >> So... what is the best way to approach this kind of thing in XSI? I'm
> >> sure there's a way. I've just not run into it yet. Can anyone point me
> >> to a term or document that might help me find what I'm looking for?
> >> ---
> >> Unsubscribe? Mail Majordomo@(protected) with the following text in body:
> >> unsubscribe xsi
> >>
> >
> >
> >
> > ---
> > Unsubscribe? Mail Majordomo@(protected) with the following text in body:
> > unsubscribe xsi
> >
>
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|