Quad rendering bug

[Ian]

This one was spotted by Harry, honestly I never even noticed it but it is a very good catch.

The issue is this there are two ways to split a quad



You can see in Harry's comparison here, if we change how we split the quads some parts of the image start to look correct. But if you look at the lower left part under the red circle, the texturing is wrong there after the change.


Close up of the image with the first way of splitting quads

Original hardware


Quad split 1


Quad split 2


So the hardware must be switching how it splits the quads somehow ..

Anyway, I drew the scene as colour quads only. Doing this I can easily look at the RGB value and work out exactly what poly is what. A lot of opengl programs actually do this for object selection. Just draw objects/polys with a unique colour. Anyway.


(scud looks kinda cool like this:)

I've drawn the poly numbers on the quads themselves.

here is a blend of the two images so you can better see what quad matches what part of the texture

polyNumber 707 clockwise 1 sharedVerts 0
polyNumber 708 clockwise 0 sharedVerts 2
polyNumber 709 clockwise 0 sharedVerts 2
polyNumber 710 clockwise 1 sharedVerts 2
polyNumber 711 clockwise 0 sharedVerts 2
polyNumber 712 clockwise 1 sharedVerts 2
polyNumber 713 clockwise 1 sharedVerts 2

Poly 707 is where the quad strip starts. 713 is where we end on the bad poly, there might be more in the list but don't really care about them.

Maybe we should change the way the quads are split based upon if the winding changes? Not sure how else the hardware is doing this.

Suggestions welcome

[Ian]

Second quad split way blending with the numbered polys ..

[Bart]

This is a bit difficult for me to see. It looks to my like quad split 1 matches the arcade screenshot.

EDIT: well, I guess there is a little bit of difference to the right of the proiminent "v" pattern.

It's likely the clockwise bit is having some effect on how the strips are assembled. What about triangles only -- does this bit ever get used (change)?

[Ian]

Have a look on a computer monitor instead of a phone .. the differences are more obvious.
Both quad split 1 and version 2 are different to the arcade. So both are wrong.

The order is wrong somehow. Wonder if when processing the poly data we should copy the shared vertices in the reverse order.
Either that or the hardware is checking the winding between quads and flipping the order.

[model123]

I do not have any knowledge of 3D programming
I think that the rectangular polygon is divided from the upper left to the lower right



If it is a misunderstanding post I will delete it so please let me know
I made it to English by google translation

[Ian]

you are probably right
The problem is the order of vertices is switched. I have an idea how to fix this .. just.. time

[Bart]

It's a bit tough for me to follow this but would it be possible for you to identify a complete quad strip and print that out here (including which vertices are shared), along with the preceding and following triangle perhaps, and then indicate how you think the winding should work in order to look correct?

I imagine the polygon splitting direction is irrelevant in some cases, so this may be hard. But if there are quads you *know* must be split or wound a particular way to look right, those could be indicated.

[Ian]

Bart it is a complete chain. Poly 707 is where the quad strip starts.
I did some reading about opengl triangle trips. Apparently the winding actually flips every triangle, and opengl either flips the check or swaps the vertices over. Winding is set by the first triangle in the strip. Quad strips seem the same. The winding alternates every quad. But if you look at the poly data I dumped above, some of the polys repeat the same winding. My current best guess is on these we should swap how the quads are split.

[Bart]

I guess that makes sense. Let's say you have a triangle strip beginning with a triangle composed of vertices a, b, c, wound in clockwise order and stored that way in memory. Then the next triangle just specifies vertex d (let's say this is somewhere to the right of the triangle, on the screen) and asks to reuse b, c. Well, b-c-d is now counterclockwise. The hardware would want to actually process it as d-c-b (or b-d-c).

Code: Select all

   b---d
 /  \ /
a---c


Maybe the hardware always splits quads a particular way but the clockwise bit specifies whether the order of the reused vertices is reordered or not before performing the split?

[HarryTuttle]

Regarding poly winding, I've observed that the clockwise winding bit in polygon header is almost always set to zero.

Code: Select all

0x00:
xxxxxx-- -------- -------- --------      Specular
------x- -------- -------- --------      Clockwise winding
-------x xxxxxxxx xxxxxx-- --------      Polygon number (not always present)
-------- -------- ------xx --------      Discard polys
-------- -------- -------- x-------      Enable specular
-------- -------- -------- -x------      0 = Triangle, 1 = Quad
-------- -------- -------- --x-----      Poly is points
-------- -------- -------- ---x----      Smoothing ?
-------- -------- -------- ----x---      Vertex 3 shared from previous polygon
-------- -------- -------- -----x--      Vertex 2 shared from previous polygon
-------- -------- -------- ------x-      Vertex 1 shared from previous polygon
-------- -------- -------- -------x      Vertex 0 shared from previous polygon


I used this already present function in <PolyHeader.cpp> to fetch the value:

Code: Select all

bool PolyHeader::Clockwise()
{
   return (header[0] & 0x2000000) > 0;
}


So I don't know how much can be useful.