Re: Bug 895099 proposed fix

[James W. W. <os...@jw...>]

On Jun 15, 2004, at 6:57 PM, Dair Grant wrote:

> Although I'm not sure why that's not working then - the idea was that 
> by
> swapping out we coud handle things like the box. The box is a group of
> faces, so it would be equivalent to:
>
>     group
>         texture
>         face0
>         face1
>         face2
>         face3 { texture }
>         face4
>         face5
>
> When the box group is entered its texture becomes active, and when 
> face3
> renders it temporarily swaps in the texture from its attribute set then
> restores the box texture afterwards.
>
> Presumably the swapping can't affect faces 0/1/2, so is it that faces
> 4/5 don't get textured? In which case are we restoring the texture
> correctly once face3 finishes?

Yes, faces 4 and 5 do not get textured because the texture is not 
restored after face3.  When a texture is submitted separately, as in 
the beginning of your example, it goes through 
E3View_State_SetShaderSurface and e3view_stack_update, which set a flag 
in the top of the view stack indicating that the texture needs to be 
restored once the view stack is popped.  But when a texture was in the 
attribute set of a TriMesh, as in face3, the view stack knew nothing 
about it, so the texture was not restored.  My fix for this problem was 
the most obvious solution, but I'll grant that it may not have been the 
most efficient.  Maybe we need a way that the renderer can induce the 
view state to be restored without popping it.
--
<http://www.jwwalker.com/>