Re: pfGeoState

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Tue, 11 Mar 1997 09:58:30 +0000


I've seen similar problems but caused when I've created textures in the
draw or in a data structure rather than with a 'new' operator in the app.
Even if that data structure exists in shased memory, an array of pfTextures
is problematic work,, and I need to 'new'.

Cheers,
Angus.

On Mar 10, 3:32pm, Len Granowetter wrote:
> Subject: pfGeoState
>
> Hi,
>
> I'm hoping that someone can shed some light on an apparent Performer
> bug we've seen in our Performer-based application.
>
> Under some circumstances, some polygons appear with the wrong
> textures on them. The scene will look completely normal, then we'll
> change the position of the eyepoint so that some new vehicle is in
> view, or something, and suddenly, a texture from the vehicle replaces
> the texture on the cloud polygon, or on some piece of the terrain.
> Move the eyepoint back, and now the right texture is restored. By the
> way, this problem does NOT seem to happen if lighting is disabled.
>
> It would seem that the problem is related to the following note that
> appears in the pfGeoState man page:
>
> 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
> explicitly set these attributes, it is possible for pfGeoStates which
> inherit these attributes to inherit them from previous pfGeoStates.
>
> However, all of our geometry is built by the MultiGen .flt loader, and
> Marcus Barnes at MultiGen assures me that:
>
> > I'm trying to figure out though, why our scene graph would contain
> > GeoStates with the texture unset.
>
> The .flt loader always sets them exactly. They are either bound and
> enabled or null'd and disabled
>
> Marcus and others say they've seen the problem too. This is from
> Marcus:
>
> I've seen this too. I reported it to SGI a year or 2 ago as a
> pfGeoState::apply() bug. Something going wrong in the push/popping.
> Once, I spoke with Sharon Clay about it and she thought that it was
> really a GL bug (Irix 5.3/Iris GL) and that there wasn't much
> Performer could do about it. I haven't seen the problem since I've
> been using Irix 6.2 myself.
>
> I myself _have_ seen the problem under IRIX 6.2/OpenGL/Performer 2.1
> as well.
>
> Does anyone have any fixes, workarounds, etc? Or know of any patches
> that solve the problem?
>
> -Len
> ----------
> |\ /| . . | / Len Granowetter
> | \/ | _ | ( MaK Technologies
> | | /-\ | \ (617) 876-8085 Ext. 121
> T E C H N O L O G I E S lengrano++at++mak.com
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Len Granowetter

=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


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:54:52 PDT

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