🚀 go-pugleaf

In article <1993Jan21.221541.17405@seas.gwu.edu> burr@seas.gwu.edu (Timothy J. Burr) writes:
>I've linked a bunch of SoShapeKits together via their childLists to 
>create a hierarchical object - a hand.  Everything works fine except,
>and its a big except, I don't want the scaling transformation of
>a parent to affect the child.  Rotations and Translations should, it
>seems to me, affect the stack but not scaling.  If you want to 
>uniformly scale the entire object then stick a SoScale node at the
>top off of the scene node.  How do you do component specific scalings
>without affecting those components further down the hierarchy? There
>seems to be no way to tell the SoTransform node, or any node to use
>the field but don't push it on the stack.  My only alternative seems
>to undo the scaling done by the parent at each child.  This is rather
>ugly.  Is there a way around this?
>
>Tim

[the next paragraph refers to previous postings...]
Okay, since you've gotten this far I assume that now you understand how the
top node of the SoShapeKit can be a separator but still allow for 
articulated motion. Is that correct? If not, let me know and I'll try to
explain.


Now, the problem you describe here is quite valid, but not tragic.
You have pointed out the SoShapeKit has this structure:

			    kit
			      |
			    separator
			      |
			  -------------------------
			  |           |           |
			transform   shape   childList

instead of this structure:

			    kit
			      |
			    separator
			      |
			  -------------------------
			  |           |           |
			transform   separator   childList
				      |
				-----------
				|         |
			      scale     shape

And you have noted that this means that the scale of "shape" will affect
all children in the child list.  Your problem is that you want to give
"shape" a scale all its own.

First, I'll show you how to do this using the SoShapeKit we gave you, then
I'll explain why we didn't use the structure that you have proposed.

How to do what you want:
You need to move the separator-scale-shape cluster as a group
into the childList as the first child.  So the top level kit gets used 
for translating and rotating only, without drawing a shape. Then, the first
child is the scaled shape. The other children in the childList are still
remaining pieces you wish to move along with this one.

The result is sort of like this:

	    kit
	      |
	    separator
	      |
	  -------------------------
	  |                       |
	transform           childList
	(rot&trans)
				  |
                           -------------------
			   |                 |
			   kit     other children....
			   |
			   separator
			   |
                    --------------------
		    transform        shape
		    (scale)

Why we didn't do it the way you suggested:
First of all, let me say that it was a toss-up. Here were the pros and cons:

PRO-adding-extra-scale-node:
    [1] adds control over shapes within hierarchies, as you have pointed out.

CON-adding-extra-scale-node:
    [1] always adds an extra separator node above "shape", even when the
	scale feature isn't used.
    [2] Adding the extra scale node would mean there were two parts in each
	kit that performed transforms. We wanted to keep the conceptual model
	simpler, if possible, and thought that the extra part might be 
	confusing to users.

It was a tough decision, and you are the first person to pick up on it; however
you are also the first person we've heard from to use nodekits for 
articulated figures.  Right now we're working on nodekit revisions for 
Inventor 2.0, and we're seriously considering adding the feature you suggested.
After all, to the programmer using SoShapeKit, it will really just be
the addition of a single new part ("geomScale", or some such name).


Thanks for your questions and comments, and don't hesitate to post some more...

pauli.