Re: [Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

(sorry, sent this to the cvs list by mistake)

=46rank C wrote:

>1). Edge/point fill styles are textured if an object has a texture=20
>shader further down the pipe.

Hmm, yes, that sounds like a bug - the edge/point styles should never be
drawn textured.


>2). Face and geometry attribute sets on primitives don't always get=20
>along. e.g. Add a texture shader to a Box's attribute set, then add a=20
>face attribute set with another texture shader to a single face. This=20
>will result in the other five faces drawing without a texture. QD3D=20
>handles this correctly, drawing the first texture on the other five=20
>faces.

This has been a long-standing problem, whereby we don't correctly handle
attributes that are shared across faces.

After going round this several times, I think the proper solution is to
divide the TriMesh rendering code into two paths:

1. Pass the TriMesh data directly to OpenGL (or whoever) with no further
processing.

2. Break anything more complex down into individual triangles, and shove
them into a triangle buffer.


We've been back and forth between the two approaches over time, but this
is really the only way to handle it - if you have to accept arbitrarily
complicated objects (a TriMesh with a unique texture object on each
triangle), we should just take the hit of breaking them up to simplify
the actual submission.

In practical terms this is probably fine: the best performance is always
going to come when we don't have the CPU touch the data and can just
give it straight to the GPU.

Breaking things into individual triangles will mean those submits are
slower than the ideal case, but if they're that general then they're
always going to be slower anyway.


We have most of this in place already, since we have a triangle buffer
to batch up individual triangles into as much of a TriMesh as we can.

All we really need to do is to make the TriMesh renderer handle the
simple case itself, and break anything else up and feed it to the
triangle buffer.


>3). Diffuse/Transparency colours (either global, or on a face or=20
>vertex) have no effect on textured geometry. ir_texture_set_state sets=20
>TexEnv to modulate when lighting is enabled, so it appears the intended=20
>behaviour is too modulate geometry color as well. QD3D has this same=20
>problem, but modulates geometry colour when a null shader is being=20
>used, something Quesa explicitly prevents - So - What's intended here=20
>and what's broken? Personally I'd like to see geometry colour modulate=20
>with textures regardless of the current illumination, or at least the=20
>same behaviour as QD3D.

We should be as per QD3D, and were at one point, however I think this
was broken a while ago.

We really need to think about moving past what QD3D offered here (have
been meaning to reply to Frank's mail on this to the old list for a
while).

Nowadays there is a lot more control over how colours and textures
interact to produce the final fragment colour. QD3D predated all of
that, so what we should do is decide what our updated API is going to
look like and then implement the "classic" behaviour in terms of that.

By "lot more control" I mean texture combine and multi-texturing: those
are two key concepts in any modern 3D API, but QD3D predated those
appearing on consumer HW.


>- Transparent objects are jumbled when some or all vertices are outside=20
>the frustum (can lead to infinite point errors). I mentioned this on=20
>the old list before the move to Sourceforge - it seems to be tied to=20
>the new view transforms.

Yes, that's when this broke.

I'm going to go through the old Bugzilla and log bugs in the SF bug
tracker for them - can you do the same for these issues?


>- Major sorting errors. I realize some geometry simply can't be sorted=20
>properly, but it's consistently bad frame-to-frame.

I think this is a side effect of the above: we're now doing all the
sorting in frustum coordinates but that's either invalid or we're not
doing it correctly.


>I can plop these into the bug base, but I'm not sure which: Sourceforge=20
>or the old Bugzilla? I'm also hoping to have some sort of regression=20
>suite built later this week to help track these down.

Use the SF tracker: the old Bugzilla will still be around for a while,
but I'll get the contents moved over this week.


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