Re: Bug 895099 proposed fix

[Roger H. <rog...@mi...>]

Thanks Dair, that is crystal clear now.




On Thursday, June 17, 2004, at 02:04  pm, Dair Grant wrote:

> 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=red                     }
>         Triangle2 { attributes: color=green; texture=TextureB }
>         Triangle3 { attributes: color=blue                    }
>
> For 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/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>