Robert Webb (robertw++at++wormald.COM.AU)
Mon, 15 May 1995 16:12:03 +1000 (EST)
> pfGetGSetBBox(..., NULL) is supposed to cause a recomputation of the
> pfGeoSet bounding box, instead it core dumps. This is is a bug,
> which I've just fixed. So no problem in 2.0.
OK, great. The man page in 1.2 only has this to say about pfGetGSetBBox:
pfGetGSetBBox copies the current bounding box into bbox.
It does not mention what should happen when bbox is NULL. Although it does
for pfGSetBBox. So in 2.0, these two functions are identical when passed a
NULL bbox?
> As for why it was invoked: pfGSetISectMask was doing a clean of the
> pfGeoSet's dirty attributes. In 1.2, when you change a pfGeoSet
> attribute, the bounding box is marked dirty, with the updating done
> at will thereafter. We can't recompute the bounding box whenever an
> attribute changes, because we don't know if the data are valid yet
> In the absence of a pfOKThisGSetIsDone() API, we implicitly make the
> assumption that the pfGeoSet is self-consistent (i.e. either empty
> or fully set up) when something other than an attribute set/get is
> done. We could defer the "clean" to the first cull or isect
> traversal, but this would require locks and would add non-
> determinism, since the first time the object is "touched" would be
> considerably more expensive.
I'm still a bit confused: if I had not called pfNodeTravMask() at all,
surely the dirty attributes would still have been cleaned?
I am now using PFTRAV_SELF rather than PFTRAV_SELF|PFTRAV_DESCEND, since I
can't see what difference it really makes. In either case the children of
the given node will be pruned for intersection traversals (I believe), but
if I just use PFTRAV_SELF then I avoid my original problem.
Thanks,
Rob.
------------------------------------------------------------------------------
Robert Webb. robertw++at++wormald.com.au
------------------------------------------------------------------------------
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:29 PDT