pfHit/isect/pick: confused by manuals/example

New Message Reply Date view Thread view Subject view Author view

Dirk Luesebrink (crux++at++artcom.de)
Tue, 23 Apr 1996 13:02:25 +0200


confusion with the pfHit datastructure used for picking/intertsection.
    i wrote to document it for myself and to deconfuse me just be getting it out
    of my head onto paper/elektrons. I hope its of some use to other.

    LOCATION:
         $PFHOME/usr/share/catman/p_man/cat3/Performer_libpf_c++/pfChannel.z

    i found the declaration for picking in a channel. this is the same like
    at some other places(eg: Intersection):

        int pfChannel::pick(
            int mode, float px, float py,
            float radius,
            pfHit **picklist[]
        );

    what im interested in is the pfHit datastructure defining my Hit. because we
    can have more then one Hit we need an array.
    as doctumented ::pick will return a pointer to an INTERNAL list of pfHits.

    LOCATION:
        $PFHOME/usr/include/Performer/pf/pfIsector.h

---
    class _pfIsector : public pfTraverser
    {
    PFINTERNAL:
	_pfIsector();
    
    
    PFINTERNAL:
	...
    
	pfHit               *hits[32];      // array of pointers to hits

...

---
    this is the declaration where I found the datastructure I get a handle to.

In the examples:

LOCATION: $PFHOME/usr/share/Performer/src/pguide/libpf/C++/intersect.C

---
	pfHit **hits[32];
	isect = root->isect(&segset, hits);
	if (isect)
	{
	    pfVec3 pnt, xpnt;
	    pfMatrix xmat;
	    (*hits[0])->query(PFQHIT_POINT, pnt.vec);
	    
	    ...
---
    which works ! BUT its plain wrong !
    /* hits here */  pfHit** hits[32];	// is identical(a least to some degree) to 
                     pfHit*** hits;	// 

isect will contain the number of hits. this example(and most of what i found) is dereferencing always hits[0] for query. when isect > 1 and the application dereferences hits[i > 0] it coredumps.

as manuals say we get a pointer to an INTERNAL list os hits. pfHit *hits[32]; // in $PFHOME/usr/include/Performer/pf/pfIsector.h

pfChannel::pick( ... ) has to have a place where to store this pointer to an array of pointer to pfHit structures.

pfChannel::pick( ... ) is writting exacly one pointer(4 bytes) to the address given as the last parameter. so the last parameter in this call is a: pfHit*** hits; and pfHit **hits[32]; // is such a pointer

but this is an array of 32 pointer to pointer to pfHits. and in the very first entry hits[0] will stand the result of the ::pick call. address hit[i > 0] will not be touched by the ::pick(...) call

in the implementation of ::pick(...) must ne something like: LOCATION: $SILICON_GRAPHICS: location unkown :-)

---
	int pfChannel::pick(
	    int mode, float px, float py,
	    float radius,
	    pfHit **picklist[]
	) {

... *picklist = _pfIsector::hits; ... }

---
    
    which tempted me to implement the following:

LOCATION: $DIRK_LUESEBRINK: D-FACTS bv :e-mail crux++at++artcom.de

---
	pfHit** hits;
	long picks = chan->pick(mode, px, py, radius, &hits);
	for(int i = 0; i < picks ; i++) {
	    pfHit* hit = hits[i];
	    
	    ...
	}
---
    which works well and let me loop over the collection of hits i have.
    (it saves me 31 * 4 bytes on the stack( hits[1..31]) :-)

Dirk Luesebrink 'having serious fun with sirius boards'


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

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