From: Marcin Romaszewicz (marcin++at++asmodean.engr.sgi.com)
Date: 10/23/2001 15:15:41
Performer state management is very lazy, meaning that it tries to make as
few state changes as possible - it's especially messy when it comes to
textures, since some hardware must have texturing enabled for things like
seting texEnv or sending the texture data.
When a texture has been enabled, performer will not disable it until
another geoset which has it turned off is applied. The reason we do this
is that if you have two geosets with texturing turned on, we will not turn
texture off at the end of using one and turn it back on for the second
one.
Since you are not applying a geostate with no texture, or explicitly
disabling texture, then performer does not find it necessary to disable
the GL_TEXTURE_2D. It will do so when you apply a state that necessates
this, so the fact that texturing is turned on is correct behavior.
However, I'm not really sure why pfState is telling you texture is off
since pfFlushState should guarantee that performer state matches opengl
state. What happens if you explicitly disable texture on your channel
geostate? pfState should tell you it's off and so should OpenGL. Does this
happen? If not, I think performer has a bug.
-- Marcin
On Tue, 23 Oct 2001, Isabelle Lafon
wrote:
> Hi,
>
> Do I miss something about the pfGeoState::apply and pfTexture::apply
> behaviour or is this a Performer Bug ?
>
> Perhaps someone can explain me what exactly pfTexture::apply does or
> does not in that case ?
>
> I'm using the multiProcess mode PFMP_APPCULLDRAW | PFMP_CULL_DL_DRAW.
> and I am drawing bins.
>
> I have an object with a pfGeoState on it. The pfGeoState has a
> pfTexture set on it and texture mode on. The pfTexture image pointer
> is null at the beginning (we use image subloading). There is a preFunc
> method on the pfGeoState in which the pfTexture::setLoadImage followed
> by the pfTexture::load is done, if required (if we have a new image
> buffer ready to use).
>
> It happens that the GL_TEXTURE_2D state is still enable at the end of
> the first frame draw even the pfState says that texture is disable.
> I was expected that the GL_TEXTURE_2D state would be DISABLE and so
> coherent with pfState current value.
>
> Note that I do a pfFlushState at the end of the frame draw.
>
>
> First frame:
> ===========
>
> - pfGeoState::apply. Perhaps pfTexture::apply doesn't do much here
> because the image pointer is null. But GL_TEXTURE_2D is enable. That
> seems OK since the texture mode is on in my pfGeoState.
> - pfGeoState::preFunc: the image buffer is set on the pfTexture and
> the pfTexture::load call is issued.
> - Then the object is drawn.
> - End of the frame draw: pfFlushState is called. GL_TEXTURE_2D on!
> - SwapBuffer: Object is visible with the texture image.
>
> When performer draw an object with a pfGeoState attach to it, he is
> doing some pfPushState before applying the pfGeoState and some
> pfPopState after drawing the object. I can see that in the pfState
> stack. But at the end of this first frame draw, pfState says texture is
> disable but GL_TEXTURE_2D is still enable. WHY ?
>
>
> Second frame:
> ============
>
> Now that there is an image pointer and that the texture has been
> loaded, I suppose that pfGeoState::apply do a bit more when it applies
> the texture. In the pfGeoState preFunc nothing is done on the
> texture. And at the end of the frame draw pfState and OpenGL agree
> that texture is disable.
>
>
>
> First frame - explicit pfTexture::apply call:
> =============================================
>
> NOW, If I add a pfTexture::apply call in the pfGeoState preFunc, the
> GL_TEXTURE_2D state is disable at the end of the first frame draw,
> which is what I was expected in the first place.
> Why do I need this second call to pfTexture::apply?
>
>
>
>
> --
> Isabelle Lafon Discreet Logic
> Tel: (514) 954-7157 10 Duke
> Fax: (514) 393-0110 Montreal (Quebec)
> isabelle++at++discreet.com Canada, H3C 2L7
>
This archive was generated by hypermail 2b29 : Tue Oct 23 2001 - 15:15:45 PDT