Re: Bug 895099 proposed fix

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

Roger Holmes wrote:

>> In this case, it's the currently-running renderer - i.e., some
>> plug-in, not the renderer-support code in Quesa.
>
>OK, so it IS relevant. I don't think we should be doing anything which
>breaks existing renderers.

This change won't break existing renderers - it fixes a bug in the
interactive renderer (a bug that may also be present in other renderers,
but I don't think we can solve it for all renderers automatically).


>Yes, but with Quesa, the caching code converts most things to
>TriMeshes whether I like it or not. Apart from the interactive
>renderer, are there any which handle boxes directly? If not then I
>guess I'm just wasting your valuable time. If so, then sorry and I'll
>shut up about it.

I don't think anything does handle boxes directly, but there's no reason
why they couldn't.


The box thing is a bit of a red herring - the bug is actually:

    Group
        TextureA
        Triangle1 { attributes: color=3Dred                     }
        Triangle2 { attributes: color=3Dgreen; texture=3DTextureB }
        Triangle3 { attributes: color=3Dblue                    }

=46or this case, the interactive renderer would have rendered Triangle1
with TextureA, Triangle2 with TextureB, and Triangle3 without any
texture.

This is because it temporarily makes TextureB active while processing
Triangle2, but doesn't restore the previously active texture when it's
finished Triangle2.


The proposed fix was to handle this push/pop at the renderer support
code in Quesa - that would fix it for all renderers, but that wouldn't
handle immediate mode submits.

Although you can't submit an immediate mode group, you can submit a
geometry which is equivalent - e.g., submitting a texture followed by an
immediate mode box that had a face with an attribut set that also had a
texture would display the same symptoms.


That's the case which precludes fixing it in the renderer support code:
that code can know where to find the attribute set of built-in
geometries, but wouldn't know where to find the attribute set for
plug-in geometries (not relevant today, but would like to support them).

If you had a plug-in geometry which a renderer didn't support, it'd be
fine: the geometry would be broken down into something it did support
and as part of that the attribute set wold be found.

If you had a plug-in geometry which a renderer supported directly, you'd
have the same problem as today - the renderer would need to be
responsible for swapping out the texture if the attribute set also held
one.


So all this means is that renderers that want to support textures in
attribute sets (as QD3D's IR did, and so our IR does too), the renderer
needs to restore the previous texture correctly once it's finished the
attribute-set-textured object.

The bug is that at the moment we don't, so any subsequent objects lose
their texture.


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