Sega rally desert stage bug

[Garagefreek]

The beginning of the race there’s a vertical line at the centre of the screen then disappears when you start driving?

[Garagefreek]

As far as i know this happens on a 1920x1080 display only?

[jaoxford]

Duplicate to this issue: #199

[toxieainc]

Which build did you use for testing?

[Garagefreek]

Git revision 161f1e3 (2024-09-30) built for 64-bit Windows.

[jaoxford]

Try changing resolutions, see if it happens at one in particular.

Does this bug happen on only the latest Supermodel build, or have you tried an older build?

[Garagefreek]

It's happening on the latest build and the previous one on a 1920x1080 display only, it's working fine on every other display settings..

[gm-matthew]

As a temporary fix you could try setting the resolution to 1920x1079, that should get rid of the vertical line

[Garagefreek]

Will do, thank you.

[toxieainc]

Seems like this issue has been around for quite some time at least

[gm-matthew]

I've discovered that this bug only occurs when using the quad renderer; with the triangle renderer it looks fine.

The vertical line is a gap in the skybox model which shouldn't be there as there are no gaps between polygons. There must be some quirk of the quad renderer that is drawing the polygons a tiny bit smaller than they are supposed to be.

[toxieainc]

Thanks, that helps. I'm currently looking at the code again and already saw some spots where things could be simplified, hopefully improving precision.

[dukeeeey]

The line at the top I'm sure is a precision issue with the quad renderer. The attribute interpolation on the edge is bad. I had problems like this with my original code and my fix was to use double precision maths to calculate the area of the poly. Of course this doesn't play well with older hw.

[toxieainc]

Maybe i can tweak it once more, maybe also helping the old Harley problem, too.

[toxieainc]

@dukeeeey Can you please point me to games/scenes where the

if (lambdaSignCount != 4) {
	if(!gl_HelperInvocation) {
		discard;
	}
}

can be seen in action? Cause i struggle at the moment to find anything where simply commenting out that discard does change anything.

[dukeeeey]

It kicks in if the polys are non planar, by culling the edges. If you rotate a non planar quad you'll see what it does. I mean it might not be totally accurate to how quad drawing works on the actual model 3. Games definitely render non planar quads. VF3, scud etc

[toxieainc]

Okay, thanks! btw: In triangle mode, the road also features that line (if in the intial cam/view mode).

[toxieainc]

Is the method based on this one? https://www.inf.usi.ch/hormann/papers/Hormann.2004.AQR.pdf

[dukeeeey]

Yep that's it

[toxieainc]

I just resurrected the original double based GS-code, but there the line also appears. :/

[dukeeeey]

Hmm that sucks. I'll give it a debug at some point. Unfortunately fragment shaders are quite hard to debug. I normally look for NaN or any values which are out of expected range. Can normally pin point the problems that way but it's a little tedious.

[toxieainc]

Yup, i also tracked down one issue: Seems like there is cancelation by 2 (or more) large t[] values leading to flaky signs, leading to the discard. So a hack (that works pretty well though if one outputs the effect itself for various games) is to skip the discard if at least one abs(t[]) was 'large enough'.

This fixes things on my NVIDIA gpu, the Intel gpu though still has the upper part of the line, and that one seems to be due to another reason. :/

[toxieainc]

oh, and btw: Harley also shows this issue if in first person view (only the lower part of the problem though, so there the hack above also works).

[toxieainc]

Okay, thanks! btw: In triangle mode, the road also features that line (if in the intial cam/view mode).

..which is only true on my NV board, Intel doesn't feature it :/

[toxieainc]

@dukeeeey Do you know which quadrilateral cases Real3D did support?

EDIT, NOT TRUE, SORRY: Cause if i disable the +-+- cases (so where 2 of the quad vertices are 'flipped' leading to this bow tie like geometry) then this also works. It would also improve the harley sky issue.

Seems like the issue is rather thin/long geometry where the precision issue flips the signs of two edge tests.

EDIT: Note that bow ties also were not handled correctly before by the code, as the ---- case was not checked. Was this done intentionally (cause the accompanying comment claims that this should be checked, too).

[dukeeeey]

Honestly we don't really know exactly how the quad rendering worked on the model 3. But given the age of the hardware, I would assume it's similar to how the nintendo DS renders quads. In the paper you referenced look up "two-fold linear interpolation". I'm pretty sure that is how it would work. But I don't know how it handles the edge cases, ie twisted etc. There are quite a few non planar quads being rendered, but not so many twisted. Maybe the only ones I can remember from testing were on the cars in sega rally 2. It has some crazy quads.

[dukeeeey]

Some extra info here that might be interesting: https://melonds.kuribo64.net/comments.php?id=56
One design idea I floated sometime ago was a hybrid software/hardware design. Where instead of drawing polys you. You just create edge lists in software, then use hardware to draw horizontal spans using GL_LINES (or maybe thin triangles). That would work but I am not sure how fast GL_LINES are because modern hardware really wants to draw minimum 2x2 pixel blocks. But I am sure it would work.

But the current quad renderer has been fine except in the most extreme of edge cases. Removing the edge culling doesn't really fix the issue for me either because the texture coordinates are wrong at the top part. Probably throwing some more precision at the problem would fix it. I never really cared that quad rendering was expensive on lower end hardware because it needed at a minimum gl 4.5 h/w to work anyway.

[toxieainc]

I will not give up yet. ;)

Cause its not just older HW/GPUs, that would of course be okay, if fp64 is slow there. But its also the case for recent integrated Intel GPUs, maybe integrated AMD GPUs, too (still have to verify).
Plus, that may also include all the 'lower end' HW like consoles, Raspberry Pi, etc. Fp64 is simply never a focus there to spend die space for it, so its all emulated.

In addition, i did not even find a working solution so far if going full fp64 for that 'top part' issue (which is also only there on my Intel setup).

But so you think its okay to ignore bow ties? As said, before these were also broken.

I would then continue to hunt for the other issue where that comes from.

[dukeeeey]

Yeah double is extra slow on older hardware because it lacks double support entirely, so it's emulated with extra instructions.

But so you think its okay to ignore bow ties? As said, before these were also broken.

I mean it's not a deal breaker certainly. I don't think it would negatively effect the emulation. Part of my own motivation is I wanted to make a quad renderer work in all cases, even if it wasn't entirely arcade accurate. Certain things in supermodel work better than the original h/w, and that for me is fine as long as everything works as expected. If you read the paper you'll see with some quads if you rotate them, actually you get a different result with two folder linear interpolation method, which actually is less than ideal. Polys shouldn't distort when you rotate them. So the method in supermodel is way better.

This is where mame makes sense, writing this sort of rasteriser in software is way easier, and could be done fast. Mapping proper quads to triangles with fixed function hardware is not a trivial task. An alternative approach would be to write the whole renderer with a compute shader, but that a complicated project that is probably beyond me.

[toxieainc]

I'm also all-in to improve the quality vs the original HW if possible. So the improved interpolation and handling of special cases more robustly is definetly awesome!

But the problem even with a software/scanline rasterizer would still be to determine how the original HW did it, as the special case quads could either be handled like the DS did (=some form of broken), not at all/ignored, like if e.g. the flip was not there (so reordering the vertices), or even just correct (although the latter is unlikely).
I will spend some more time to investigate the submitted bow tie quads, if these are just an artifact of the artists work, or tool bug, or engine bug (=not intended), or if they just actually fit the surrounding geometry.

Cause it could also well be that these are just results of screw ups/bugs and the HW may have ignored them or rendered differently, so that would also lead to a 'cleaner' image then in Supermodel.

I will do more experiments and try to explore more of this bugs original issue and hopefully also about the quad special cases.

[dukeeeey]

I tested an older build of supermodel before the reverse Z was added, and well it doesn't have this issue.

Also the issue roughly is the the interpolated area is coming out as zero on the edge pixels at that particularly camera location. And some further down where the interpolation is also bad, I guess it's coming out very close to zero.

I wonder if doing the 1/w in the fragment shader instead of the geometry shader would fix this

[toxieainc]

Hmmm.. You mean there is no crack whatsoever, or the most upper and the road issue is not appearing there?
Cause the 'middle part' is definetly caused by the precision issue, so it should be independent from the depth buffer.
Or is it a sideeffect of the other changes that happened in that commit?
Is it exactly the reverse z commit?

[toxieainc]

5fa402f did change the behavior

[dukeeeey]

I am not sure if any of these commits actually 'fix' the issue. If you make the viewport 1 pixel smaller the issue goes away. It's probably some corner case with the maths. I'd like to see if I can extract the bad poly and debug the render pipeline in software, to see if the situation can be improved. I suspect it probably can happen in other places.

But your commit using floating point viewport values is interesting. Obviously opengl doesn't support fractional viewport values. Some games the viewport height comes out to 383 instead of 384. I am not sure whether these should be rounded or not. Kinda hard to tell on original hardware. But daytona has some issues with some of the smaller viewports leaving a gap at certain resolutions. I wonder if this would fix these. I suspect it might.

[toxieainc]

True, but note that predating the changing commit in question this was also the same (so without the widescreen check), could for example be spotted when starting the race but not accelerating.
And its more general unfortunately, if you look at the letters when selecting championship in SRally for example (without my tweaks).

So in some sense my commits do not really fix all things, but at least they should help improve/stabilize things further. Plus it fixes things for a super common use case (FullHD, but no widescreen).

Most of my comments above (except for the bow tie one, this did not hold up in my experiments) also are still true. So the edge test/discard is still prone to precision error in general. This one i'm still experimenting with, but wanted to get the rest out of the door, also for easier comparisons later-on.

[dukeeeey]

Test program I wrote sometime ago to test quads.
quad test.zip

Keys are

Press 'R' to reload shaders
Press 'P' to pause
Press 'M' to change mode
Press 'T' to load texture
Press '+' (numpad) change split
Press '-' (numpad) change split

Press:
Insert/Home/PageUP decrement x/y/z
Delete/End/PageDown increment x/y/z

Maybe you'll find it useful. I have the full source code somewhere if i can find it lol

[toxieainc]

Nice, thanks! Source would be nice, but if one can reload shaders that should be good enough for experiments!

[dukeeeey]

I might have lost it lol. I'll see if i can find, but yes it should support hot reloading of shaders, Just press R to reload.

[toxieainc]

JSYK: I just copypasted the modified code from the PR to see if all still works also in your small tool with the special cases, and yup, all good there, too.

[toxieainc]

@dukeeeey How to progress here then? I think my 2 PRs are okay as-is, as at least they should improve things/precision in general (but also while not fixing it once and for all :/).

[dukeeeey]

You've got some great changes in there. I will get around to adding them but just unfortunately v busy with real life stuff atm, but will get to them.

[Garagefreek]

Is the line fixed?

[jaoxford]

Is the line fixed?

Having read this thread I'm gonna say no.

[toxieainc]

The issue in here is fixed (with the outstanding PR(s)), but a general solution is outstanding.
BUT its also questionable if that general solution even exists, as it may also be just the 3D data that is flawed and not made to be viewed at high resolutions.

[toxieainc]

@dukeeeey Did you find some time to look at the 2 PRs by now?

[dukeeeey]

yes a little time. I will definitely pull in some of the changes, bear with me :)

[toxieainc]

no problem! i just want to get this resolved before i forget most of the details again ;)

[trzy]

I will review this on Wednesday for sure!

…

On Nov 4, 2024, at 5:55 AM, toxie ***@***.***> wrote: no problem! i just want to get this resolved before i forget most of the details again ;) — Reply to this email directly, view it on GitHub <#201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJZ3RLLEWPX3YVRU2ULFTDZ654GTAVCNFSM6AAAAABPGU3PMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJUG44DCMZVGM>. You are receiving this because you are subscribed to this thread.

[Garagefreek]

Any luck with the line?