GeoState corruption

New Message Reply Date view Thread view Subject view Author view

Jean-Francois Richard (jfr++at++cae.ca)
Wed, 14 Dec 94 12:28:30 EST


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?

-------------------------------------------------------------------

 J.F. Richard
 CAE Electronics Ltd
 Montreal, Canada

-------------------------------------------------------------------


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:44 PDT

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