Re: Bug 895099 proposed fix

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

On Wednesday, June 16, 2004, at 06:43  pm, Dair Grant wrote:

> Roger Holmes wrote:
>
>> I think we need some more specific terminology here.
>>
>> ' The renderer ' is not always the Quesa interactive renderer, the
>> same source code should be able to run under QD3D or Quesa. We need to
>> have some way to differentiate between the plug in renderer layer and
>> the layer which comes between it and Quesa's submit calls.
>
> 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.

>
>
>> Which are we discussing here?
>
> When a(ny) renderer is asked to render a geometry with a texture stored
> in the geometry attribute set, it needs to render that geometry using
> the texture in the attribute set rather than the currently active
> geometry.

Yes but most plug in renderers use the 'renderer-support' code to 
convert
from the many different geometries into just TriMesh (not even that with
some renderers), Triangle, Line, Point and Marker. I think that any 
required
change should also be put into this conversion code.

> This is the same behaviour as QD3D and means that if you submit texture
> A followed by a box with a texture B on one of its face attribute sets,
> then the box should be rendered partly with texture A and partly with
> texture B.

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.e., the face with the texture attribute overrides the default 
> texture,
> and the other faces inherit the default texture from the parent object
> (which, since the box doesn't have a texture itself, inherits it from
> the current view state, which works back up the enclosing groups until
> it finds a texture).
>
>
> The underlying bug here is that when we activated texture B, we didn't
> restore texture A - instead we did SetTexture(NULL), i.e., turned off
> texturing for any following objects in the current texture scope.
>
> James' initial fix was to handle this attribute-set-overrides-current
> state by pushing/popping the texture in Quesa's renderer support code.
>
> That doesn't work for immediate mode submits, as we don't know what the
> instance data actually looks like at that point. We could add a big
> switch at that level which would try and identify it, but that won't
> work for plug-in geometries (where we would have no way to find the
> attribute set given the void* that would be the geometry data).
>
> Renderers can handle both immediate and retained mode submits, as any
> plug-in geometries would get broken down into something that they know
> what the instance data looks like.
>
>
> So, all this means is:
>
> 1. The IR needs to save/restore the active texture correctly when it
> sees a texture in an attribute set that overrides the last-submitted
> texture object.
>
> 2. Any renderer that wants to support texturing needs to do the same
> thing, or it won't render "group with texture and three geometries the
> middle one of which has a texture in its attribute set" correctly.
>
> This would be another example of where a test suite would be good: once
> you know of a corner case that needs to be supported you just write up 
> a
> test case and that can be used for renderer verification as well as
> catching regressions.
>
>
> -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
>