 | | | programmatically accessible many to many relationships | programmatically accessible many to many relationships 2005-03-04 - By Brad Friedman
Back
indeed... probably doable. As well, the earlier suggestion regarding
scops doing something similar was also messy but doable. And I may well
get messy and do it.
A question or two:
I'm stepping a little outside my realm of knowledge here on this
question so this may not make complete sense.
Deformers (bones and nulls and such) have three groups within them for
the inclusive/exclusive bounding volume featureset with enveloping. I
just want to make sure... that functionality is hardcoded correct? I
can't get my own groups onto an arbitrary object in that manner, correct?
Second... if I were to finish up learning C++ and start coding for XSI
in C++, would I be able to say... subclass a poly-mesh and add groups
like the deformer groups? Or is that functionality simply not exposed?
Thirdly... I'm assuming there's no way to subclass outside of C++ correct?
I'm just trying to understand my options before I commit to something.
Thanks.
-brad
kim@(protected) wrote:
> 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
|
|
|