Re: Bug 895099 proposed fix

[Dair G. <da...@re...>]

James W. Walker wrote:

>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.

Oh, OK - I think the problem is in IRRenderer_Texture_Postamble: we
never actually restore the previous texture, we always clear it to NULL.

I thought that we just did an internal swap-out-then-swap-back, but it
looks like that has changed at some point: I'm not sure if that was the
bug before, or if this was changed as part of this?


It looks like the push/pop approach are checked in now, so actually we
have redundant code in the IR that's submitting the texture twice:

1. IRGeometry_Attribute_Handler is checking for the surface shader and
if it finds one submits it.

2. IRRenderer_Texture_Postamble is clearing the current texture to NULL
afterwards.

Both of these ought to be redundant - if there's a texture on the
attribute set then E3Renderer_Method_SubmitGeometry will submit it for
us, along with a push/pop that avoids the need for us to restore the
state afterwards.

We also have some commented out code in IRGeometry_Attribute_Handler
that can go - if the responsibility for textures-in-attribute-sets is
now at the Quesa renderer level, individual renderers don't need to
handle it.


Having said that, I'm not sure how the current scheme handles immediate
mode submits? If I submit an immediate mode box with a texture in the
attribute set then how is that applied?

Right now it's handled by IRGeometry_Attribute_Handler: so removing that
double-submit wouldn't be harmless after all.


Immediate mode is the reason it was done at the renderer level, because
it's only once we're in the renderer that we know what the immediate
mode form of the object we're dealing with is.

E3Renderer_Method_SubmitGeometry could have a list of object types and
parse them by hand, but it wouldn't be able to handle plug-in
geometries.


So it may be better to keep this fix in the renderer: and just make sure
that when we push/pop the state (either with a real push/pop or just by
saving the current texture and restoring it rather than restoring to
NULL.

=46or the latter have some code commented out in
IRGeometry_Attribute_Handler which will find the current texture: this
should be moved before we do the submit to grab what's on the top of the
view state stack (can either be put back in for this purpose or removed,
not sure when/why it was removed but it does nothing right now).

Or alternatively we could track the current texture object in our
instance data, and save that off when we need to swap it out.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/