Quad rendering bug

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Quad rendering bug

Postby Ian » Sat Apr 01, 2017 5:41 am

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

Image

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

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

Original hardware
Image

Quad split 1
Image

Quad split 2
Image

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

(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
Image

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
 
Posts: 1218
Joined: Tue Feb 23, 2016 9:23 am

Re: Quad rendering bug

Postby Ian » Sat Apr 01, 2017 6:08 am

Second quad split way blending with the numbered polys ..

Image
Ian
 
Posts: 1218
Joined: Tue Feb 23, 2016 9:23 am

Re: Quad rendering bug

Postby Bart » Sat Apr 01, 2017 2:09 pm

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)?
User avatar
Bart
Site Admin
 
Posts: 2058
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Quad rendering bug

Postby Ian » Sat Apr 01, 2017 2:41 pm

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.
Ian
 
Posts: 1218
Joined: Tue Feb 23, 2016 9:23 am

Re: Quad rendering bug

Postby model123 » Mon Apr 03, 2017 10:13 am

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

Image

If it is a misunderstanding post I will delete it so please let me know
I made it to English by google translation
model123
 
Posts: 20
Joined: Wed Mar 08, 2017 8:34 am

Re: Quad rendering bug

Postby Ian » Mon Apr 03, 2017 10:18 am

you are probably right :)
The problem is the order of vertices is switched. I have an idea how to fix this .. just.. time :)
Ian
 
Posts: 1218
Joined: Tue Feb 23, 2016 9:23 am

Re: Quad rendering bug

Postby Bart » Mon Apr 03, 2017 11:39 am

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.
User avatar
Bart
Site Admin
 
Posts: 2058
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Quad rendering bug

Postby Ian » Mon Apr 03, 2017 11:54 am

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.
Ian
 
Posts: 1218
Joined: Tue Feb 23, 2016 9:23 am

Re: Quad rendering bug

Postby Bart » Mon Apr 03, 2017 1:03 pm

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?
User avatar
Bart
Site Admin
 
Posts: 2058
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Quad rendering bug

Postby HarryTuttle » Tue Apr 04, 2017 4:02 am

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.
Last edited by HarryTuttle on Tue Apr 04, 2017 5:21 am, edited 1 time in total.
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Next

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 1 guest