One Transform, two shapes?

[warpcat]

Anyone know how, or if it's possible, to have a transform that has two (or more) shape node associated with it?

Furthermore, how you could "swap shapes"? Say you have a cube and a sphere. How could you "move" the sphere's shape node under the cubes transform, and move the cubes shape node under the sphere's transform?

[empleh]

Try this:

parent -s -r "sourceShape" "dest";

And here is a neat trick that uses it.
http://www.geocities.com/wilwhaley/uv.html

good luck,
ww

[warpcat]

The parent command, wow, whodathunk? I knew I must have left my brain at home today... Thanks a lot, my life just got 1.3% better

[markwilkins]

I've known for a while that it was possible to have two shapes under one transform, but does anyone have a reason that it would be desirable? I've never thought of one myself, but the instant I say that I know someone will come up with something!!

-- Mark

---

Mark R. Wilkins
author of MEL Scripting for Maya Animators
www.melscripting.com

[nonquad]

I've wanted to do that a few times (but wasn't able to at the time, because I always forgot how when I needed to...).

An example would be if you want to have two pickable representations of the same object - particularly if you want two geometries of different types; like a nurbs curve and a polygon sphere. Or if you want a simple way to ensure that two geometries share the same space for rigging reasons - without depending on a fixed parenting structure.

Also, if a hybrid object with many geometry types is going to be instanced a lot (like in a particle flock) it would be a definite advantage to reduce the total number of transforms by keeping polys and nurbs in the same space.

While I can't think of any situation where multiple shape parenting is essential, I'm positive that the ability has niche applications, if only for an interface-aesthetic or simplicity reason.

edit: also, come to think of it, it would be great way to impliment LODs

[joojaa]

Well you could allways use groups for this but yeah this essentialy makes for slightly less data to parse. BUt on the downside they would inherit same local space (this is not necceserily a bad thing), atleast in theory!

[warpcat]

The reason I was asking is in regards to character rigging. I like to use Nurbs curves to create nodes the animators can pick to animate on. A simple framework of the character that makes picking intuitive. By default, you're limited to a single curve per transform. This means, if you want to make neat little selectors like smily faces, rocket ships, or a bunch of bubbles, you have to use the "etch-a-sketch" effect, where it's actually one long curve making up the entire shape. Nothing really wrong with that, other than it looks a little silly having all these lines connect the elements of your smily face. On the other hand, grouping curves together won't work, because if the animator chooses a child curve, it won't select the "parent" curve that the animator would be keying on. By having the ability to have multiple curve shape nodes under a single transform, it allows a TD to generate custom selectable shapes that can be independent form one another, but selecting any part of the shape will select the whole. Convenient.

[nonquad]

Ahhh yeah. I remember now. That's the same reason I used to have =)

I use polygon objects for pickables these days. It's not necessarily a better plan (since it takes more time to set up; and in the end the rig will be judged on functionality, not aesthetics...) but personally I think the end result is easier to pick on than NURBS.