Marcus (Marcus++at++multigenuunet.UU.NET)
Fri, 2 Dec 1994 15:13:55 PST
This a bit confusing to me. A DOF bead is translated into a pfDCS
node by the OpenFlight loader. An object bead is translated into
a pfGroup plus pfGeode, pfBillboard, and pfLightPoint children as
appropriate. I gather that you're expecting to somehow convert
the object bead into a pfDCS node?
>The problem is when I run my application in Performer, the DOF nodes
>never appear.
There are no "DOF nodes" in the Performer scene graph. I assume
you mean that the geometry under the DOF bead isn't drawn.?
>I have tried attaching them to another group with no other children
>and moving the DOF to the first node under its parent, but the node
>doesn't appear in Performer. When I move the DOF node up two levels
>higher in the hierarchy, it will appear, but if I put it only one level up
>in the hierarchy, it still is not visible. Also, if I put all the DOF
nodes
>at the same level the first is visible at, only half of them are visible.
Uhm ... so you're using MultiGen to shuffle the hierarchy around in
order to figure out what's wrong? Ok. Be aware that the OpenFlight
loader does three kinds of post process editing on the generated scene
graph before returning the root node to you. These actions can be
enabled/disabled via LoadFltMode() described in the readme file
/usr/src/Performer/src/lib/libpfflt/README.V14. The actions are:
PFFLT_COMBINELODS: It combines logically related LOD beads into single pfLOD
nodes.
PFFLT_FLATTEN: It calls pfFlatten() to apply all the static transforms
represented by pfSCS nodes (group beads with [TRSM] matrices).
PFFLT_CLEAN: Lastly, it removes all redundant pfGroups and pfSCS
(identity matrices after pfFlatten) nodes. Singleton hierarchies,
like you seem to describe above, will be simplified to a top level
pfGroup with pfGeode (leaf node) children. The pfGroup created in
place of the object bead (your DCS?) will be deleted.
You should disable PFFLT_CLEAN and PFFLT_FLATTEN to see if
the pfNodes you're interested in are being deleted.
Also, it's very possible that you're running into a bug in pfFlatten().
By default the loader calls pfFlatten() when it's finished translating
the .flt file. Here's how I described the bug to John Rohlf last
September:
=============begin excerpt======================
From: Marcus (9/2/94)
To: John Rohlf
CC: Allan Schaffer
Reply to: pfFlatten bug?
Dear Mr. Rohlf,
What follows is a dialog we've had with a customer concerning a
problem loading his .flt files into Performer v1.2. I've isolated the
problem to the actions of pfFlatten. It apparently fails to apply a
parent SCS transform to the sibling of a child DCS node (see MultiGen
hierarchy below). I've enclosed 2 sample .flt files that show the
problem. They should both display the same thing, but they don't.
One is OK, the other is broken by pfFlatten.
Perhaps this is a known Performer bug?
Please let me know if you need more information,
Marcus Barnes, Member Technical Staff
MultiGen Inc., 1884 The Alameda, San Jose CA, 95126
PH: (408) 261 4118 FX: (408) 247 4329
EMAIL: multigen!marcus++at++uunet.UU.NET
--------------------------------------
Date: 9/2/94 4:02 PM
From: Marcus
More info for you and Keith:
The problem with pfFlatten is that right hand siblings of a pfDCS (DOF),
which has a pfSCS (group [TRSP]) above it, will be affected by the pfDCS.
MultiGen hierarchy (pfFlatten breaks it)
/--------\
| g1 |
| [T] |
\--------/
|____________
| |
/--------\ /--------\ ----> After pfFlatten, o1 is affected
| d1 | | o1 | by d1, because of the
transform
| | | | immediately above
d1. This
\--------/ \--------/ shouldn't be.
As a workaround have Keith and others model this way:
MultiGen hierarchy (pfFlatten does NOT break it)
/--------\
| g1 |
| [T] |
\--------/
|____________
| |
/--------\ /--------\
| g2 | | o1 |
| | | |
\--------/ \--------/
|
/--------\ -----> Any siblings here may be affected by d1
| d1 | after pfFlatten is done! So don't do
it.
| |
\--------/
I'll be reporting this pfFlatten bug to the Performer Group.
Regards,
Marcus
=============end excerpt======================
>I can't understand why the DOF's are apparently getting culled, since
>everything else at that level is in the same area and is appearing
>correctly. If I go into the DOF's attributes and enter the location
>where I want the door, MultiGen puts it out in the middle of nowhere.
DOF beads represent a local coordinate system which is usually
different from the database's. Entering database coordinates
in DOF attributes can easily place it outside the field of view.
Apply your put tranformation to the external reference or the DOF
bead's parent group, whichever.
>I have used DOF's in a smaller application and didn't have this problem.
>However, in looking back at my earlier application to try and solve this
>problem, I notice that while the DOF nodes rotate correctly in Performer
>they rotate completely wrong in MultiGen. (They are doors and they
>rotate about a point ~5m away from the edge, while in Performer they
>rotate about an axis through the edge.)
Updating a pfDCS node, derived from DOF bead, in Performer requires
the information provided by the OpenFlight loader callback for DOF
beads. The loader calculates the put and inverse put matrices that
are needed to enter and exit the DOF local coordinate system within
which the DOF transformations are meaningfull. The pfDCS in the
scene graph is only updated via pfDCSMat() with the resultant
matrix, not via direct multiplication. I have a basic demo program
and database that illustrates this concept that I can send you.
> Any help would be greatly appreciated.
>
>Perry McDowell
>mcdowell++at++cs.nps.navy.mil
Please feel free to contact me directly for more help on
this subject.
Regards,
Marcus Barnes, Member Technical Staff
MultiGen Inc., 1884 The Alameda, San Jose CA, 95126
PH: (408) 261 4118 FX: (408) 247 4329
EMAIL: multigen!marcus++at++uunet.UU.NET
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:43 PDT