pfQueryGSet() is bizarre!

New Message Reply Date view Thread view Subject view Author view

Robert Webb (robertw++at++wormald.com.au)
Mon, 20 Mar 1995 16:33:52 +1000 (EST)


Howdy all,

Does anyone have any idea why pfQueryGSet() is done the way it is?
These are the semantics I would expect from a function such as this:
     
    long pfQueryGSet(pfGeoSet *gset, ulong which);

where which is PFQGSET_NUM_VERTS or PFQGSET_NUM_TRIS, and the return value
is the result of the query. But instead it is done like this:

    long pfQueryGSet(pfGeoSet *gset, ulong *which, float *dst);

where the answer is written to the address in dst, and the number of bytes
written is returned from the function.

So I have the following questions:

    - Why is the value put in dst rather than just being returned?

    - Why is dst a pointer to a float, since all the types of data that can
        be requested are integers?
     
    - Why is the number of bytes written returned at all? Should I look at
        the return value?
     
    - Why is the which argument a pointer, rather than an integer?

    - Which of these is correct usage (if any)?:

        long num;
        pfQueryGSet(gset, (ulong *)PFQGSET_NUM_VERTS, (float *)&num);

      or:

        long num;
        ulong which = PFQGSET_NUM_VERTS;
        pfQueryGSet(gset, &which, (float *)&num);

Finally, may I suggest that some more query types be added for future
releases of Performer. For example, pfGetGSetAttrLists() can be used to get
the array of colors used, but it is not easy to work out how long this array
is! It depends on the type of binding (off, overall, per_prim, or
per_vertex), as well as the number of vertices or triangles/primitives in
the GeoSet. Same goes for texture coordinates and normals. These can be
calculated at the moment of course, but some convenience functions would be
greatly appreciated.

Thanks,
Rob.

------------------------------------------------------------------------------

Robert Webb. robertw++at++wormald.com.au

------------------------------------------------------------------------------


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:51:05 PDT

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