Here in scud race there is what appears to be a missing poly on the car windscreen (windshield for you yanks).
There actually existed a prototype version of scud race for the dreamcast, and there is some footage on youtube of it, running under demul.
The exact same poly errors shows up here too, so I assumed that the car was just modeled badly originally. Without high quality footage of car from the original model3 hardware I had no way of knowing if this was a bug or not, so I just wrote it off.
Then Harry showed me this screenshot, and hardware comparison.
And on the model3
Oh god, what's going on with the texturing? Why is it so broken. To debug this thing first I took a look at the actual polys themselves.
(Scud race looked actually quite awesome like this lol)
Poly 712 and 713 were the most visibly broken ones.
Here is the polys overlayed with the original rendering. The white lines show how they are being split into triangles.
Okay maybe we've split our quads the wrong way? There are actually 2 ways you can split a quadrilateral, and you can get quite different results depending on which split you take.
Okay so let's see the rendering with the splitting into triangles flipped.
Parts of the model look better.. other parts look more broken somehow. My original thoughts were, the splitting could have been related to how the vertices were arriving at the input buffer, but that turned out not to the case. There actually exists algorithms to split quads to give better results. For example you can split a quad into triangles by the shortest distance between the vertices. I tried this, and results were better but still no cigar. I realised later on that, both ways of splitting the quad were wrong, and actually the hardware was natively rendering quads, ie with quadratic interpolation (between 4 points) This is somewhat problematic, because virtually all hardware in existence renders only triangles (interpolation between 3 points). Besides the DS? The only hardware that rendered quads were made 20+ years ago, sega saturn, nvidia NV1? Not much is known about how they render quads, and what kinds of limitations they actually had.
Quads are actually quite interesting .. by interpolating between 4 points per vertex lighting suddenly looks a lot better.
The left is triangles per vertex, middle quads, right pixel shaders. The per vertex quad version looks almost identical to the pixel shader version ... which is a massive improvement over triangles.
You can also do this with quads
To texture that properly with triangles, you'd have to really tessellate that down to the pixel level. There are papers online that recommend tessellation to solve this problem and that was the first solution I tried. But splitting a quad into 4 quads, and splitting again to render as triangles 1 quads becomes 8 triangles, and all you've done is halved the error. Do a 2nd or 3rd level of splitting really explodes the number of polys and basically chokes the renderer. Not a viable solution.
Nvidia has a paper where they recommend rendering quads with a geometry shader and gl_lines_adjacency. You can then pass all the 4 attributes to the pixel shader and do custom interpolation there.
An algorithm for this exists and which works really well can be found in this paper. (Warning super technical)
http://www.inf.usi.ch/hormann/papers/Ho ... 04.AQR.pdf
My original quad code based upon this paper, basically worked (as a proof of concept) but had a lot of corner cases that would result in NaNs and other errors. And I also had a serious issue with AMD cards where interpolation qualifiers didn't work with geometry shaders. Looked like this
This bug caused me to abandon the project entirely. If I couldn't get it to work on my AMD card, what's the point? Anyway, 1 year later AMD got back to me and that bug has been fixed. Just not on my AMD card because it's older and doesn't get driver updates anymore .. lol, oh well.
Anyway with this bug fixed, motivated me enough to finish this project. And these are the results.
Just like the arcade now!
Although interpolation of vertex attribs now looked correct, these errors still existed.
The reason is because fundamentally we are still rendering the quad as 2 triangles. And the depth values are being written as triangles. Anyway in GLSL you can write to gl_FragDepth and write your own custom values. Normally you don't need to bother with this because it's done automatically. You don't even need to write anything. Triangles are always planar, but quads, well they don't have to be planar. In fact you they can be twisted and contorted. You can render some extremely complex shapes with just a single quad polygon. Anyway interpolating the depth between 4 points gives us these results.
No more depth testing errors, everything works as expected!
As far as I know this is the only general purpose quad renderer (in opengl) in existence. You can switch between the triangle and quad shaders with the command line -quad-renderer. Personally I wouldn't have bothered with the normal triangle renderer at all, but there are enough people out there with potatoes for pcs that will complain if I make it the default renderer lol.
This project has actually changed my mind about quads. I don't see them making a come back, but they aren't so evil after all.
