Re: Bug 895099 proposed fix

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

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.


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

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.

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/