quesa-develop — Mailing list for Quesa development

Re: Test Suite

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

Jose' Cruanyes wrote:

>I'm considering wxWindows for a new project, seems that it could be a=20
>fairly decent platform to write our samples and tools

Yes, that would be a good idea - would need to see if we can distribute
binary builds of the library through our CVS/releases (i.e., we probably
don't want to have to build it from source for each platform so could
check in prebuilt libs for Mac/Windows/x86-Linux for linking to).


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

Test Suite

[Jose' C. <cru...@ce...>]

On Jun 16, 2004, at 2:38 AM, Dair Grant wrote:

> I've opened 973627 to
> track a test suite, as this is the kind of thing that would be ideal to
> add to that if it existed.

I'm considering wxWindows for a new project, seems that it could be a 
fairly decent platform to write our samples and tools


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

[ quesa-Bugs-967958 ] Trimesh transparency vertex attributes not applied properly

[SourceForge.net <no...@so...>]

Bugs item #967958, was opened at 2004-06-07 01:40
Message generated for change (Comment added) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967958&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trimesh transparency vertex attributes not applied properly

Initial Comment:
Transparency color vertex attributes in a trimesh do not appear to 
properly flag all vertices/triangles as transparent.

This screenshot: <http://webhome.idirect.com/~frankco/
transerror.jpg> shows a heightmap that has been flooded with 
transparency color vertex attributes and should draw entirely in 
the transparent color, but it appears that (possibly) every-other 
triangle is solid. The same model works as expected in QD3D.

----------------------------------------------------------------------

>Comment By: Frank Condello (pox)
Date: 2004-06-16 17:15

Message:
Logged In: YES 
user_id=171509

I think I've isolated the issue...

When ir_geom_trimesh_build_transparent checks for transparent vertices 
it flags transparent triangles by running through all the vertices and 
finding their parent triangle. However, ir_geom_trimesh_build_triangles 
only assigns the first triangle that references a given vertex as a parent, 
potentially leaving some "childless" triangles in the mix. The diagram 
below illustrates a tristrip that would exhibit this bug (hopefully my ASCII 
art comes out ok):

A-----B
|\    || \ 3 | |  \  |  | 1 \ | 2 |    \|    C-----D-----E

vertex A parent = triangle 1
vertex B parent = triangle 2
vertex C parent = triangle 1
vertex D parent = triangle 1
vertex E parent = triangle 2

ir_geom_trimesh_build_transparent won't flag triangle #3 as transparent 
in this case, even if all it's vertices are transparent.

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-15 20:15

Message:
Logged In: YES 
user_id=439944

Can you attach the model to this bug, or make it available?

The list of transparent triangles is constructed in 
ir_geom_trimesh_build_transparent: do you see anything odd if you step 
through there? Also, does the TriMesh have a usage array for this vertex 
attribute?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967958&group_id=45158

[ quesa-Bugs-967950 ] Trimesh diffuse color vertex attributes don't override

[SourceForge.net <no...@so...>]

Bugs item #967950, was opened at 2004-06-07 05:31
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967950&group_id=45158

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trimesh diffuse color vertex attributes don't override

Initial Comment:
If you have a trimesh containing an attribute set that uses a diffuse 
color, then add diffuse color vertex attributes, the color remains 
that of the main attribute set rather than the vertex colors.

QD3D overrides the attributes in the main set with any like-
attributes in face/edge/vertex attribute arrays.

----------------------------------------------------------------------

>Comment By: Dair Grant (grantd)
Date: 2004-06-16 20:57

Message:
Logged In: YES 
user_id=439944

OK, closing as invalid.

----------------------------------------------------------------------

Comment By: Frank Condello (pox)
Date: 2004-06-16 19:14

Message:
Logged In: YES 
user_id=171509

Sorry - this was an observational error on my part (a problem with 
QD3D rendering on my GeForce3 card threw my logic off). Quesa works 
as intended, so this bug can be closed.

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-16 00:11

Message:
Logged In: YES 
user_id=439944

This actually should be implemented - we have a couple of optimisations 
to avoid calculating it unless we have to (so one of them might be going 
off incorrectly), but IRGeometryTriMesh.c's 
ir_geom_trimesh_vertex_colours_inherit should perform the full 
inheritance.

Can you attach a model that demonstrates the problem? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967950&group_id=45158

[ quesa-Bugs-967950 ] Trimesh diffuse color vertex attributes don't override

[SourceForge.net <no...@so...>]

Bugs item #967950, was opened at 2004-06-07 01:31
Message generated for change (Comment added) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967950&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trimesh diffuse color vertex attributes don't override

Initial Comment:
If you have a trimesh containing an attribute set that uses a diffuse 
color, then add diffuse color vertex attributes, the color remains 
that of the main attribute set rather than the vertex colors.

QD3D overrides the attributes in the main set with any like-
attributes in face/edge/vertex attribute arrays.

----------------------------------------------------------------------

>Comment By: Frank Condello (pox)
Date: 2004-06-16 15:14

Message:
Logged In: YES 
user_id=171509

Sorry - this was an observational error on my part (a problem with 
QD3D rendering on my GeForce3 card threw my logic off). Quesa works 
as intended, so this bug can be closed.

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-15 20:11

Message:
Logged In: YES 
user_id=439944

This actually should be implemented - we have a couple of optimisations 
to avoid calculating it unless we have to (so one of them might be going 
off incorrectly), but IRGeometryTriMesh.c's 
ir_geom_trimesh_vertex_colours_inherit should perform the full 
inheritance.

Can you attach a model that demonstrates the problem? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967950&group_id=45158

Re: "Most Wanted" list

[Joseph J. S. <jo...@st...>]

At 12:50 PM -0400 6/16/04, Frank C wrote:

>Jose committed my patch yesterday, so perhaps Joe missed that this 
>has already been fixed.

Oops, yes, sorry -- was out of town last weekend and am still not 
caught up on mail.

Best,
- Joe

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: Bug 895099 proposed fix

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

=46rank C wrote:

>On a related note: Is there ever a good reason to bind a NULL texture?=20

It shouldn't really matter - as long as texturing is turned off at the
same time, even if something was bound it would never apply.


>I've gained some speed by removing all NULL binds and wrapping=20
>glBindTexture in a GL_Util*** routine that compares the last texture to=20
>the requested one, avoiding redundant uploads.

The texture won't be uploaded when it's bound: unless it got bumped out
of vram by something else since the last time it was bound, it'll still
be there.


>This helps the transparent pass quite a bit since it often
>binds/unbinds the same texture over and over (for every triangle) when
>drawing a mostly self-sorted mesh.

I guess it removes the need to call GL, but I would expect glBindTexture
to not do anything if the same object is already bound - although I
suppose it could be implementation dependent (perhaps some drivers do no
checking at all: seems unlikely though, checking for a no-change is such
an obvious thing to do if you were writing glBindTexture).


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

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/

Re: Bug 895099 proposed fix

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

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.

Which are we discussing here?


On Wednesday, June 16, 2004, at 04:41  pm, Dair Grant wrote:

>  What do you
> think about moving the push/pop sequence into the renderer, so that we
> swap out at the point we were before but now actually restore rather
> than just reverting to NULL?
>

Re: Bug 895099 proposed fix

[Frank C <li...@si...>]

On 16-Jun-04, at 11:41 AM, Dair Grant wrote:

> James W. Walker wrote:
>
>> If there was ever a swap back, I never saw it.
>
> Yes, it looks like that's been setting it to NULL (rather than setting
> it back to what it was) forever.

On a related note: Is there ever a good reason to bind a NULL texture? 
I've gained some speed by removing all NULL binds and wrapping 
glBindTexture in a GL_Util*** routine that compares the last texture to 
the requested one, avoiding redundant uploads. This helps the 
transparent pass quite a bit since it often binds/unbinds the same 
texture over and over (for every triangle) when drawing a mostly 
self-sorted mesh.

Frank.

Re: Bug 895099 proposed fix

[James W. W. <ja...@wr...>]

Dair Grant <da...@re...> wrote:

>What do you
>think about moving the push/pop sequence into the renderer, so that we
>swap out at the point we were before but now actually restore rather
>than just reverting to NULL?

Sounds reasonable.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: serious texture mapping bug in current code

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

=46rank C wrote:

>Yes - Not sure if you noticed, but hitting command-A in that example=20
>app I posted will swap in a solid model for a quick comparison.

Yep. What would be handy actually would be a build with a fixed camera
(perhaps snap the camera to a failing position on Button()), as that
would make it easier to see exactly what was being submitted to GL.


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

Re: "Most Wanted" list

[Frank C <li...@si...>]

On 16-Jun-04, at 10:59 AM, Dair Grant wrote:

>> This is clearly using the hardware texture & lighting, except that
>> it's not actually using the lighting portion -- it's faking it with
>> vertex coloring.
>
> The T in T&L actually means Transform - normally "do your own lighting"
> means doing what QD3D's IR did, i.e., transform the geometry from the
> world to the camera coordinate system, light it as appropriate, and
> produce a final colour of:
>
>     output = calc_light(vertex_colour * texture_colour)
>
> And then push down your fully-lit triangle to the rasteriser.
>
> The normal reason for doing it is so that you can use a different
> lighting model than the one GL allows, e.g., to introduce different
> light types or use a different illumination model.

The DIY lighting I'm referring to would be static and pre-calculated by 
tracing rays from each light to each vertex. This is generally too slow 
to do at runtime, but has some nice side effects like self-shadowing. 
Basically a poor-man's lightmap...

>> But we're supposed to be binary compatible with QD3D; this is
>> something QD3D can do, and is clearly not incompatible with OpenGL,
>> so shouldn't Quesa's IR behave the same way?
>
> I think it does, doesn't it? I went through my backlog of mail 
> yesterday
> so may have missed it in that, so is there still a situation that's not
> handled by using a null shader?

Jose committed my patch yesterday, so perhaps Joe missed that this has 
already been fixed.

Frank.

Re: "Most Wanted" list

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

Joseph J. Strout wrote:

>Frank's point was that this isn't working.  But I haven't reproduced=20
>this myself (it's not a feature I ever use), so hopefully he'll chime=20
>in here with more details.

Hmm, seems to be working at the moment - use the null shader, turn on
texture, select the triangle in Geom Test and you get a red-blue-green
tinted textured triangle.


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

Re: serious texture mapping bug in current code

[Frank C <li...@si...>]

On 15-Jun-04, at 9:57 PM, Dair Grant wrote:

> Frank C wrote:
>
>>> But when I load the same floor model used in the screen shots posted
>>> earlier, the bug is clearly happening in Geom Test.  You can try the
>>> same model here: <http://www.strout.net/temp/Floor.3DMF>
>>
>> The texture is ARGB32... I've seen this, and it appears to be the same
>> (or related) problem I mentioned earlier;
>
> Yep, I think it's the same thing - i.e., bug 967765.
>
> I had a quick look and confirmed that the vertices for your
> closer-than-hither test weren't coming out as nans or anything: but the
> fact it shows up when texturing a poly that's entirely in view suggests
> that our projection is incorrect.
>
> Swapping the texture type to RGB32 will put us back onto the opaque
> path, which in theory should be doing exactly the same projection:

Yes - Not sure if you noticed, but hitting command-A in that example 
app I posted will swap in a solid model for a quick comparison.

Frank.

Re: "Most Wanted" list

[Joseph J. S. <jo...@st...>]

At 3:59 PM +0100 6/16/04, Dair Grant wrote:

>I'm not sure I understand what the problem is then - this is also how
>things work under Quesa: if you use a NULL shader, the final vertex
>colour is the colour you supply * the texture.

Frank's point was that this isn't working.  But I haven't reproduced 
this myself (it's not a feature I ever use), so hopefully he'll chime 
in here with more details.

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: Bug 895099 proposed fix

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

James W. Walker wrote:

>If there was ever a swap back, I never saw it.

Yes, it looks like that's been setting it to NULL (rather than setting
it back to what it was) forever.


>My changes to fix the bug were in just 2 places:
>IRGeometry_Attribute_Handler to submit the shader rather than calling
>IRRenderer_Update_Shader_Surface, and E3Renderer_Method_SubmitGeometry
>to push and pop the view state.

Although this fixes the retained mode bug (but with a double-submit of
the texture), it won't fix it for an immediate mode box. What do you
think about moving the push/pop sequence into the renderer, so that we
swap out at the point we were before but now actually restore rather
than just reverting to NULL?


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

Re: Bug 895099 proposed fix

[James W. W. <os...@jw...>]

On Jun 16, 2004, at 3:54 AM, Dair Grant wrote:

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

If there was ever a swap back, I never saw it.  My changes to fix the 
bug were in just 2 places: IRGeometry_Attribute_Handler to submit the 
shader rather than calling IRRenderer_Update_Shader_Surface, and 
E3Renderer_Method_SubmitGeometry to push and pop the view state.
--
<http://www.jwwalker.com/>

Re: "Most Wanted" list

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

Joseph J. Strout wrote:

>In OpenGL, and in QD3D, he "does his own lighting" by applying vertex
>colors to textured TriMeshes.  The color applied at each vertex as
>calculated based on the lights in the scene

I'm not sure I understand what the problem is then - this is also how
things work under Quesa: if you use a NULL shader, the final vertex
colour is the colour you supply * the texture.


>This is clearly using the hardware texture & lighting, except that=20
>it's not actually using the lighting portion -- it's faking it with=20
>vertex coloring.

The T in T&L actually means Transform - normally "do your own lighting"
means doing what QD3D's IR did, i.e., transform the geometry from the
world to the camera coordinate system, light it as appropriate, and
produce a final colour of:

    output =3D calc_light(vertex_colour * texture_colour)

And then push down your fully-lit triangle to the rasteriser.

The normal reason for doing it is so that you can use a different
lighting model than the one GL allows, e.g., to introduce different
light types or use a different illumination model.


>But we're supposed to be binary compatible with QD3D; this is=20
>something QD3D can do, and is clearly not incompatible with OpenGL,=20
>so shouldn't Quesa's IR behave the same way?

I think it does, doesn't it? I went through my backlog of mail yesterday
so may have missed it in that, so is there still a situation that's not
handled by using a null shader?


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

Re: "Most Wanted" list

[Joseph J. S. <jo...@st...>]

At 2:38 AM +0100 6/16/04, Dair Grant wrote:

>  >....or do your own lighting, which is impossible with Quesa at the 
>>moment...
>
>It's perfectly possibly - you just need to write a plug-in renderer. :-)
>
>The current IR tries to push as much work down towards OpenGL as
>possible, as doing your own lighting takes you off any HW T&L path.

I'm not sure that Frank's point was caught here.  In OpenGL, and in 
QD3D, he "does his own lighting" by applying vertex colors to 
textured TriMeshes.  The color applied at each vertex as calculated 
based on the lights in the scene; these are lights in the 
application's internal description of the scene only and are NOT 
lights known to the rendering engine at all.

This is clearly using the hardware texture & lighting, except that 
it's not actually using the lighting portion -- it's faking it with 
vertex coloring.

>Which isn't to say that a different lighting model wouldn't be useful,
>but the best way to do it nowadays would be to use a vertex shader that
>would allow you to plug your own model in/use QD3D's model as desired.

But we're supposed to be binary compatible with QD3D; this is 
something QD3D can do, and is clearly not incompatible with OpenGL, 
so shouldn't Quesa's IR behave the same way?

Best,
- Joe

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

[ quesa-Bugs-907880 ] Stale (cached?) data saved in 3DMF file

[SourceForge.net <no...@so...>]

Bugs item #907880, was opened at 2004-03-01 21:42
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907880&group_id=45158

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Stale (cached?) data saved in 3DMF file

Initial Comment:
I have a TriGrid with a custom attribute attached to it. I draw it, 
that works fine. I change the value of the custom attribute and 
save the file. What gets saved is a TriMesh (fair enough) with the 
original version of the custom attribute rather than the new value.

----------------------------------------------------------------------

>Comment By: Dair Grant (grantd)
Date: 2004-06-16 13:49

Message:
Logged In: YES 
user_id=439944

OK, marking as closed - Roger confirms this is now working correctly.

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-06-15 23:02

Message:
Logged In: YES 
user_id=439944

Roger, I believe this one came from you or RobinL - do you remember 
the context, or if it's still an issue?

----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 2004-05-29 08:41

Message:
Logged In: YES 
user_id=433183

I cannot reproduce this.  If the bug still exists, we need more 
information.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907880&group_id=45158

Re: [ quesa-Bugs-907880 ] Stale (cached?) data saved in 3DMF file

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

Have just tested a recent CVS version and an old CVS version and the 
old one
shows the fault and the new one does not so the fault has been fixed.

Thank you.

Roger.


On Wednesday, June 16, 2004, at 12:02  am, SourceForge.net wrote:

> Bugs item #907880, was opened at 2004-03-01 21:42
>


> Initial Comment:
> I have a TriGrid with a custom attribute attached to it. I draw it,
> that works fine. I change the value of the custom attribute and
> save the file. What gets saved is a TriMesh (fair enough) with the
> original version of the custom attribute rather than the new value.
>
> ----------------------------------------------------------------------
>
>> Comment By: Dair Grant (grantd)
>
> Roger, I believe this one came from you or RobinL - do you remember
> the context, or if it's still an issue?

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/

Re: Bug 895099 proposed fix

[James W. W. <os...@jw...>]

On Jun 15, 2004, at 6:57 PM, Dair Grant wrote:

> Although I'm not sure why that's not working then - the idea was that 
> by
> swapping out we coud handle things like the box. The box is a group of
> faces, so it would be equivalent to:
>
>     group
>         texture
>         face0
>         face1
>         face2
>         face3 { texture }
>         face4
>         face5
>
> When the box group is entered its texture becomes active, and when 
> face3
> renders it temporarily swaps in the texture from its attribute set then
> restores the box texture afterwards.
>
> Presumably the swapping can't affect faces 0/1/2, so is it that faces
> 4/5 don't get textured? In which case are we restoring the texture
> correctly once face3 finishes?

Yes, faces 4 and 5 do not get textured because the texture is not 
restored after face3.  When a texture is submitted separately, as in 
the beginning of your example, it goes through 
E3View_State_SetShaderSurface and e3view_stack_update, which set a flag 
in the top of the view stack indicating that the texture needs to be 
restored once the view stack is popped.  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.  My fix for this problem was 
the most obvious solution, but I'll grant that it may not have been the 
most efficient.  Maybe we need a way that the renderer can induce the 
view state to be restored without popping it.
--
<http://www.jwwalker.com/>

Got object merging and 4x speedup

[Keith W. <kw...@cs...>]

I got object merging to work, with textures, properly mapped to each 
individual object added to the trimesh.  It wasn't too hard once I 
figured out the underlying structure of the trimesh arrays.  I got a 4x 
speedup for the effort.  Pretty cool.

Thanks.


________________________________________________________________________
Keith Wiley                                kw...@cs...
http://www.unm.edu/~keithw                 http://www.mp3.com/KeithWiley

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________