John Rohlf (jrohlf++at++tubes)
Tue, 1 Mar 94 10:34:43 PST
This is a mistake in the documentation. The routine does not exist.
You set up global default by calling normal libpr routines such as
pfApplyMtl(), pfEnable() etc.
> - In one of our applications at least, the culling does not work properly.
> Objects suddenly vanish before they leave the viewing frustrum. Any ideas
> why this could be? We are not changing any of the GeoSets or other data in
> the hierarchy after it has been initially set up.
Print out the scene with pfDebugPrint and make sure your bounding
boxes are reasonable.
> - I've read the pfLight man page and I'm still not sure how to position lights
> properly. It says that for lights like the sun, which have a fixed position
> in the world, pfLightOn() should be called every frame with only the viewing
> transformation on the matrix stack. I understand the concept, but how do I
> actually do it? Performer does all the drawing and transformations for you
> so do I need some sort of call-back to call pfLightOn() at the right moment?
Call pfLightOn in your draw callback set by pfChanDrawFunc().
> If I set up lights in a pfGeoState with:
> pfGStateAttr(gstate, PFSTATE_LIGHTS, lights);
> and associate this with a pfGeoSet, then is that the same as using
> pfLightOn() with the modelling transformations for that GeoSet on the stack?
> That is, will the lights then move with the object like lights on a car? Or
> does this simply use the lights but not affect their position? Do you still
> need to call pfLightOn()?
Yes, Yes, No, No.
> Again I would like to use pfGlobalGState() to define global non-moving
> lights, but this is unavailable.
You do not need this. Just call pfLightOn and you have defined a
global non-moving light.
> - Ultimately it would be nice if pfGeoStates could be attached to any node,
> and inherited by children. A pfGroup which holds all the various geometry
> nodes for an object could then define materials etc. for all its children,
> without each pfGeoSet having to do this itself to override the global state.
> Does every little pfGeoSet really need its own pfGeoState? If so, is this
> efficient provided consecutive children use the same pfGeoState?
On the surface this seems like a nice concept but it is
contrary to Performer doctrine and will never happen. Inheritance
in a scene graph causes more problems than it is worth because
you have to potentially examine large portions of the scene graph
to decide how to draw something. It's like a deep C++ hierarchy
where you have to chase a chain of 15 constructors to see
what's going on. With the pfGeoSet/pfGeoState
combination we know immediately how to draw a chunk of
geometry (except for transforms) and we can use this information to
efficiently sort geometry by mode and add other optimizations.
pfGeoSets can share pfGeoStates at little or no cost. Believe
me, the pfGeoSet/pfGeoState combination is pretty damn efficient.
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:11 PDT