Mailing List
Home
Forum Home
Softimage
Carrara
trueSpace
Dir3d-l
Maya - a powerful 3D animation and visual effects software
Macromedia Flash Development
Subjects
Cameras
scaleDown command
black out solved
Aircraft Tutorial
Mathematical XYZ ?
Its done This vs That
Its done first week
recommendations for screen video captures?
3DExplorer "Oddity "
New Director
ProTeam renewals
Fuel 's new websites (X post)
Blue peter create a make toy
targeting groups question
XPost: Shockwave 3D game ( sort of )
RES: RES: RES: Fish Modeling
Emitting particles from object intersection
Fuel 's new websites (X post)
Texturing
Big Break Contest Videos
New Plugins
Models and Texture on my updated site
Error Installing Patch tS6 6
Plasma?
Looking for Inspiration
Weird EMail Q
It 's done first week ?
Cherry not cranberry
New game
Camera Animation Problem
Particle plugins?
 
programmatically accessible many to many relationships

programmatically accessible many to many relationships

2005-03-04       - By Matt Lind

 Back
Reply:     <<     11     12     13     14     15     16     17     18     19     20     >>  


If you already know the structure of your rig, then storing all the names of
objects isn't necessary and probably won't help you as much as you'd think.
You'd be better off checking the hierarchical structure of your rig to
ensure it's integrity as needed.  If your rig changes, then simply update
your tools to recognize the change, but also provide an update funciton to
upgrade rigs from old scenes to current standards.

A simple way of identifying objects would be to tag them with an ID number
or label within a userdata blob or custom parameter.  The userdata blob has
the added advantage of being readable from compiled code such as shaders.
When a tool traverses the rig, it looks for the tag on each object it
encounters and responds based on whether it's present or not.  The ID's and
labels could be classified based on functionality so lookups can provide
useful information other than just stating an object is part of a rig or not
(eg: use numeric ranges to classify whether a rig component is a curve,
null, or envelope, and assign specific digits to indicate which body part
they're assigned).  The most important aspect is one you'll probably design
using pencil and paper - organization.  Consistency and logic will be the
hallmarks that make or break your system.


Matt

-- ---- ---- ---- -----
Matt Lind
Animator / Technical Director
Softimage certified instructor:
   Softimage|3D
   Softimage|XSI
Mantom, Chicago
Matt(at)Mantom.net





programmatically accessible many to many relationships
Date : Fri, 04 Mar 2005 09:15:24 -0500
To : XSI(at)Softimage.COM
>From : Brad Friedman <xsibrad(at)fie.us>
Subject : programmatically accessible many to many relationships

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(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi