Re: GeoState corruption
John Rohlf (jrohlf++at++tubes)
Fri, 23 Dec 94 10:47:16 PST
>
>
> Hi everybody.
>
> I'm currently trying to integrate into my Performer program
> the great looking Flight format models that the good folks
> at Viewpoint were giving away at I/ITSEC.
>
> The problem is that the models are doing something to the
> lighting and/or material definitions (I'm not exactly sure
> which) that affects the lighting over the rest
> of the displayed scene. I am specifying default lights and
> light model and I tried adding a default material
> (pfApplyMtl( pfNewMtl( ... ) ) ) but the overall lighting
> still changes after one of the Viewpoint models is displayed.
>
> All my database geosets have geostates that do not specify
> lighting or material characteristics. These are all set globally,
> but, according to the pfGeoState man page, should be restored
> from the global state before the database's local geostates are
> applied.
>
> The following note from the pfGeoState man page attracted my
> attention:
>
> >> In some situations it may appear that pfGeoStates do inherit from each
> >> other. This is because IRIS Performer currently does not provide any
> >> defaults for the state attributes listed above such as PFSTATE_TEXTURE
> >> and PFSTATE_FRONTMTL. Consequently, if the application does not expli-
> >> citly set these attributes, it is possible for pfGeoStates which inherit
> >> these attributes to inherit them from previous pfGeoStates.
>
> Ok, so maybe there is a global state attribute I am not setting that is
> being changed by the Viewpoint models. The phrase "such as PFSTATE_TEXTURE
> and PFSTATE_FRONTMTL" seems a bit vague to me. What exactly are
> all the modes and attributes I should watch out for? I am specifying
> a global front material, and local textures, so is there anything
> else I should set?
>
> Is there an elegant way of insuring that an imported model or
> database leaves the graphics state unchanged after it gets
> drawn (without having to push/pop the state in pre/post-draw
> callbacks)?
>
>
> This isn't exactly a matter of life and death and I'm
> sure I could hack my way around it but I am curious about
> what exactly is going on here. Anybody knows the right way
> of dealing with this?
pfGeoStates are *the* elegant way of ensuring that graphics
state is not inherited across geometry. pfGeoStates
have been thrashed to death so I doubt that you've run
into a geostate bug. Exactly how is the lighting changed
by the Viewpoint models? Can you point me to the models
which cause the problem?
N.B.: The graphics state is not immediately popped after
a pfGeoState is applied. Rather, any "dirty" state is popped
*after* the next pfGeoState is applied so that no state
is unnecessarily popped. Consequently after a pfGeoState is
applied, the graphics state is that of the pfGeoState. If you
want a return to the global state, either apply a pfGeoState
which inherits everything or call pfFlushState().
This lazy popping of state is a significant performance
feature of pfGeoStates.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:50:46 PDT