home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / graphics / 198 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  4.3 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!olivea!sgigate!sgi!fido!pauli
  2. From: pauli@sgi.com (Paul Isaacs)
  3. Newsgroups: comp.sys.sgi.graphics
  4. Subject: Re: Inventor: scaling components in a hierarchy
  5. Message-ID: <1k1ko8INNki@fido.asd.sgi.com>
  6. Date: 25 Jan 93 21:06:16 GMT
  7. References: <1993Jan21.221541.17405@seas.gwu.edu>
  8. Distribution: usa
  9. Organization: Silicon Graphics
  10. Lines: 108
  11. NNTP-Posting-Host: uniblab.asd.sgi.com
  12.  
  13. In article <1993Jan21.221541.17405@seas.gwu.edu> burr@seas.gwu.edu (Timothy J. Burr) writes:
  14. >I've linked a bunch of SoShapeKits together via their childLists to 
  15. >create a hierarchical object - a hand.  Everything works fine except,
  16. >and its a big except, I don't want the scaling transformation of
  17. >a parent to affect the child.  Rotations and Translations should, it
  18. >seems to me, affect the stack but not scaling.  If you want to 
  19. >uniformly scale the entire object then stick a SoScale node at the
  20. >top off of the scene node.  How do you do component specific scalings
  21. >without affecting those components further down the hierarchy? There
  22. >seems to be no way to tell the SoTransform node, or any node to use
  23. >the field but don't push it on the stack.  My only alternative seems
  24. >to undo the scaling done by the parent at each child.  This is rather
  25. >ugly.  Is there a way around this?
  26. >
  27. >Tim
  28.  
  29. [the next paragraph refers to previous postings...]
  30. Okay, since you've gotten this far I assume that now you understand how the
  31. top node of the SoShapeKit can be a separator but still allow for 
  32. articulated motion. Is that correct? If not, let me know and I'll try to
  33. explain.
  34.  
  35.  
  36. Now, the problem you describe here is quite valid, but not tragic.
  37. You have pointed out the SoShapeKit has this structure:
  38.  
  39.                 kit
  40.                   |
  41.                 separator
  42.                   |
  43.               -------------------------
  44.               |           |           |
  45.             transform   shape   childList
  46.  
  47. instead of this structure:
  48.  
  49.                 kit
  50.                   |
  51.                 separator
  52.                   |
  53.               -------------------------
  54.               |           |           |
  55.             transform   separator   childList
  56.                       |
  57.                 -----------
  58.                 |         |
  59.                   scale     shape
  60.  
  61. And you have noted that this means that the scale of "shape" will affect
  62. all children in the child list.  Your problem is that you want to give
  63. "shape" a scale all its own.
  64.  
  65. First, I'll show you how to do this using the SoShapeKit we gave you, then
  66. I'll explain why we didn't use the structure that you have proposed.
  67.  
  68. How to do what you want:
  69. You need to move the separator-scale-shape cluster as a group
  70. into the childList as the first child.  So the top level kit gets used 
  71. for translating and rotating only, without drawing a shape. Then, the first
  72. child is the scaled shape. The other children in the childList are still
  73. remaining pieces you wish to move along with this one.
  74.  
  75. The result is sort of like this:
  76.  
  77.         kit
  78.           |
  79.         separator
  80.           |
  81.       -------------------------
  82.       |                       |
  83.     transform           childList
  84.     (rot&trans)
  85.                   |
  86.                            -------------------
  87.                |                 |
  88.                kit     other children....
  89.                |
  90.                separator
  91.                |
  92.                     --------------------
  93.             transform        shape
  94.             (scale)
  95.  
  96. Why we didn't do it the way you suggested:
  97. First of all, let me say that it was a toss-up. Here were the pros and cons:
  98.  
  99. PRO-adding-extra-scale-node:
  100.     [1] adds control over shapes within hierarchies, as you have pointed out.
  101.  
  102. CON-adding-extra-scale-node:
  103.     [1] always adds an extra separator node above "shape", even when the
  104.     scale feature isn't used.
  105.     [2] Adding the extra scale node would mean there were two parts in each
  106.     kit that performed transforms. We wanted to keep the conceptual model
  107.     simpler, if possible, and thought that the extra part might be 
  108.     confusing to users.
  109.  
  110. It was a tough decision, and you are the first person to pick up on it; however
  111. you are also the first person we've heard from to use nodekits for 
  112. articulated figures.  Right now we're working on nodekit revisions for 
  113. Inventor 2.0, and we're seriously considering adding the feature you suggested.
  114. After all, to the programmer using SoShapeKit, it will really just be
  115. the addition of a single new part ("geomScale", or some such name).
  116.  
  117.  
  118. Thanks for your questions and comments, and don't hesitate to post some more...
  119.  
  120. pauli.
  121.