Behavior of "empty" GeoSets

New Message Reply Date view Thread view Subject view Author view

Thomas Hudson (hudson++at++cs.unc.edu)
Thu, 14 Mar 1996 23:08:29 -0500 (EST)


Can anybody explain the way Performer 2.0 treats "empty" GeoSets?
Over the past 48 hours I've been bedeviled by the following behavior:

  * Create a pfGeoSet with a PFBOUND_STATIC bounding box.
    call setNumPrims(0), setPrimType(PFGS_TRISTRIPS),
    setPrimLengths(NULL),
    setAttr(PFGS_COORD3, PFGS_PER_VERTEX, NULL, NULL),
    setAttr(PFGS_NORMAL3, PFGS_PER_VERTEX, NULL, NULL).

    Place this GeoSet into a Geode with a PFBOUND_STATIC
    bounding sphere.

    Behavior: although every parent node in the hierarchy
    inherits the Geode's bounding sphere (which properly
    contains the GeoSet's bounding box), everything is
    culled - the pfGroup at the root of the scene returns
    0 for pfGetCullResult() in the pre-cull callback, as does
    its children should we issue a pfCullResult(PFIS_ALL_IN).

  * Take the above Geode. Add more GeoSets, containing nontrivial
    geometry. (Fitting within the same bounding box/sphere)

    Behavior: exactly the same. Everything gets culled away.

  * Create a pfGeoSet like the first, with a PFBOUND_STATIC bounding
    box, calling setNumPrims(0) and setPrimType(PFGS_TRISTRIPS).
    However, create a 1-entry lengths array and 3-entry arrays
    for the normals and vertices.

    Behavior: everything renders "as expected" - we traverse
    the culling hierarchy all the way down to the Geodes, and
    hit the post-draw callbacks (indicating to me that we've
    drawn the "empty" geosets)

Does this make sense?

Thanks for any insight you can give. I've got source code if it's
helpful.

(While this occurred, the Onyx we were running on changed chassis,
but this really shouldn't have affected our program performance,
should it?)

Tom Hudson
UNC-Chapel Hill Walkthrough and Modeling Groups
// hudson++at++cs.unc.edu


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:33 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.