Mario Veraart (rioj7++at++fel.tno.nl)
Thu, 29 Oct 1998 14:11:26 +0100 (MET)
Thanks Dick, Steve and Marcus it was something different.
I finally found some time to look at this anoying effect.
Implemeting the requirements of the application had to be done first.
It turned out to be something completely different than the
suggestions that Marcus have. They can be the case for others but for
me it had to do with an pfOverride(PFSTATE_ENTEXTURE, PF_ON).
This was called in the application based on some required settings.
When I coded this I was probably not aware of the possible
consequences. I found it out by traversing the flight loaded models
and look at the pfGeoState they have and what they inherit from the
global state.
The loaded models where not able to DISABLE the texturing and so they
got stuck with whatever there was left on the OpenGL state. They got
textured with the last used texel colour, and that can change from
frame to frame.
Mario Veraart
Marcus Barnes wrote:
>
> On Oct 23, 1:16pm, Mario Veraart wrote:
> >The effect that I see is that the Flight objects are drawn brighter or
> >darker depending on the viewpoint, just a minute change in heading can
> >cause a sudden lightening or darkening of the flight objects.
> >When I disable the drawing of the terrain with a draw traversal mask
> >then the effect does not happen.
>
> Sounds like your objects have a pfGeoState that has incomplete lighting
> specifications while the pfGeoSets have normals. Depending upon your viewpoint
> the order of rendering causes different values to be latched by OpenGL. OpenGL
> uses these "last" values to rendering vertices (polygons).
>
> I bet that the flashing will change (or stop) if you turn off cull sorting too.
>
> >The terrain is a textured mesh of triangles with color and normal
> >attributes in the pfGeoSet. All terrain tiles use the same pfGeoState
> >that is fully defined. The flight objects are non-textured and
> >modelled with Gouraud shading.
>
> This implies that they don't have normals. Now if you have disabled
> PFFLT_COMPUTENORMALS this will in fact be true. So the pfGeoState used by the
> objects, created by the loader, will leave PFSTATE_ENLIGHTING unspecified.
>
> Hmmm ... along time ago the OpenFlight loader was changed for Performer 2.0
> when pfGeoState modes were all PF_OFF by default. That has changed for 2.2 it
> apears. The 2.2 man page says that all state elements are now inherited by
> default.
>
> Your application probably has called pfdMakeShared() as well, which complicates
> matters a bit. Anyways, your application is ending up with a global state of
> PFSTATE_ENLIGHTING == PF_ON and your unlit objects are being randomly lit.
>
> As work around you can traverse the subgraph containing all your unlit geometry
> and set each pfGeoState to PFSTATE_ENLIGHTING == PF_OFF.
>
> I consider this a buglet in the OpenFlight loader and will be fixed in the next
> release.
>
> >When I look at the flight models with perfly they all look fine.
>
> Perfly is setting up a different global state or it's computing normals for the
> unlit geometry.
>
> Regards.
> --
> + Marcus Barnes, Technical Staff mailto:marcus++at++multigen.com +
> + Multigen-Paradigm Inc. http://www.multigen.com +
> + 550 S. Winchester Blvd. phoneto:1-408-367-2654 +
> + Suite 500 San Jose CA 95128 faxto:1-408-261-4103 +
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
This archive was generated by hypermail 2.0b2 on Thu Oct 29 1998 - 05:13:24 PST