Performer questions

New Message Reply Date view Thread view Subject view Author view

Robert Webb (webb++at++cgl.citri.edu.au)
Fri, 18 Feb 1994 18:48:21 +1100 (EDT)


Howdy all, I have a few Performer questions for anyone who feels like helping
out:

- The Performer documentation we have describes a function pfGlobalGState(),
  but this function does not seem to actually exist (and there is no prototype
  for it in the header file). How do I set up global pfGeoState defaults
  without it?

- 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.

- 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?

  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()?
   
  Again I would like to use pfGlobalGState() to define global non-moving
  lights, but this is unavailable.

- 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?

Many thanks to anyone who answers any of these questions.

-- 

Rob. (webb++at++godzilla.cgl.citri.edu.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:50:10 PDT

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