Open RedDevilus opened 4 years ago
NASCAR Heat 2002 is notorious for those too. Happens only in Hardware regardless of scaling, enabling mipmapping doesn't fix it.
There a few instances in Gran Turismo 4, are present in Software and Hardware renderers, and don't seem affected by settings or manual gamefixes Apricot Hill: Shadow under bridge in last turn Opera Paris yellow road marking Opera Paris building shadow on paved road segment Opera Paris shadow on road crossing
There's also a billboard very near the start of Opera Paris which has the issue but I hesitate to include it as it does exhibit a similar but much less severe variant of the issue on real hardware.
Midnight Club 3 Dub Edition Remix - Lights on rooftops, and road that is far from car, HW mode look worse. Persona 4 - many places like school rooftop, doors in Marukyu Striptease, main street in Inaba, almost not existing in SW mode. F1'04 - https://github.com/PCSX2/pcsx2/issues/2323 GUN - that one is interesting because it happen only in SW mode. link
Is worth to mention that MC3 throw warning about using old clip flag value in few places in COP2 code. video samples for mc3/p4: mc3_p4.zip
Also occurs with Tony Hawk's Pro Skater 3 in hardware modes. Does not seem to occur in sw mode though. Here is a quick video example of the game in hw mode (PCSX2 1.7):
Need For Speed - Most Wanted also has this issue on Hardware Modes when the camera moves into the main menu after the memory card screen.
In Guitar Hero on hardware renderers it is noticeable on distant geometry (especially on guitars, drums and to a lesser degree on world geometry) and also on the score counter.
Kuon (yang phase, happens in SW and HW), Flickering foot.
Aggressive Inline Skating (Demo from PSmagazine24 so probably affects full game)
Where I marked with blue circle if you jump just before in HW mode it turns black for a second (could probably be a different issue) Where I marked it red is one of the many z-fighting occurrences also only in HW mode.
Billboard and crowd seating area flickering in Toca Race Driver demo in PSmagazine24.
Is this the same issue that's being described here?
Not if framebuffer conversion fixes it, no
Ape escape 3 has some Zfighting on a billboard in the Wild West level It's present in both HW and SW though less intense in SW I cannot upload the GS dump directly on Github as the smallest I've managed to capture that illustrates the issue is still too large. Ape Escape 3 - Wild West Zfigthing.7z
Snoopy vs. the Red Baron exhibits z-fighting as described in https://github.com/PCSX2/pcsx2/issues/5240
Potentially Rayman 3 as well in #6101
Shadow of the Colossus does it in every Hardware Mode at any resolution. Observable when looking at a structure or a landscape at a distance. Experimented with mipmaps and other texture-related settings, but no cigar.
EDIT: Provided a better example.
Beat Down: Fists of Vengeance has quite a bit of z-fighting on a number of distant objects, including character models.
Legend of Kay has significant z-fighting even on nearby objects.
Certain areas in Castlevania: Lament of Innocence have z-fighting.
Shin Megami Tensei: Digital Devil Saga 1 and 2 both have what I'm pretty sure are z-fighting issues - various shadows begin to flicker, although whether it occurs seems to depend on where you're standing relative to the shadows. Only happens in HW mode, tested with all renderers. It's visible in the very first room of DDS2.
Broken shadow:
Move to the side, suddenly that shadow has no issues.
Bug only occurs in hardware renderers at higher-than-native resolution. Disabling depth emulation fixes the issue but causes the overlapping shadow glitch mentioned on the wiki page. Strangely, 3x, 5x, and 7x resolutions do not appear to experience the problem.
Hope this gets fixed soon, appreciated
Since my issue is a duplicate would you please add link to the meta description? Now, it's just simple text, while my #8858 report is much more complete.
Hope this issue will be resolved soon , Onimusha 3 got some crazy z fighting but dmc1 and others as well
@refractionpcsx2 So from your last comment in #3811 will you essentially need 64-bit precision on GPU's before this can be fixed? That would be a shame because this the biggest problem i've come across in quite a few games.
One obvious example:
https://github.com/PCSX2/pcsx2/assets/50634894/6b8a2eb9-779d-4c7d-afe1-72260536ad91
Yes, or we can use integer depth via rov. Neither is fast.
Same in Shadow Tower Abyss.
Will using "integer depth via rov" will really be so slow that we won't be able to emulate games at decent speed? I mean some time has passed from when this project was started and computers got faster.
ROV will not work on NVIDIA older than 1xxx cards, and on AMD it may not work at all.
ROV will not work on NVIDIA older than 1xxx cards, and on AMD it may not work at all.
ROV works on RDNA 2 and up perfectly fine but let's not crowd up these comments please.
Red, can you add Sonic Unleashed? I tested it a while ago and saw z-fighting issues, and testing it again today, they're definitely there. For example, if you go to the shrine and look at the Sun door, it starts z-fighting.
Z-fighting is also prevalent in Powerpuff Girls: Relish Rampage. There's very visible z-fighting on buildings and on the windows of vehicles.
Likely to be hundreds more with z-fighting. It probably looks better in the software renderer because of accuracy of mantissa.
Probably Vampire Night also have this issue.
Suikoden V and Dark Chronicle have it too,
Suikoden V is visible on dock columns in Sol Falena and during the Lelcar town attack https://youtu.be/rwLb7IpMOWA?t=637 Dark Chronicle has it on train windows when you go towards it on Forest dungeon Dark Chronicle_SCES-51190_20240115133513_2.zip
I've come up with two fixes (or hacks) for two different games that I've tested, not sure how well they generalize to other games:
For Quake III Revolution:
The depth values are very large but the actual range used doesn't seem to be more than 24-bit, so we can chop the top 8 MSBs from the depth values in the vertex shader and more or less fix the shadows.
This has almost no performance cost and can be done in all HW renderers.
For GTA III LCS:
The depth test are greater or equal, and the floating point fraction is too accurate, chopping the interpolated depth to integer fixes the decals for the most part.
This requires assigning to gl_FragDepth (for OpenGL and Vulkan) or whatever is equivalent in D3D11 and D3D12. The performance drop is around 33% to 40% in GPU since there's no longer early z test. (Conservative depth may help but from my test it doesn't seem to do much)
Example shader:
(For Vulkan: resources\shaders\vulkan
)
tfx.glsl.zip
Some side notes:
While ROV allows 32-bit integer to be used for depth, there's also the problem of interpolating 32-bit depth values between vertexes on the GPU. No idea how to do that..
The simple way of using two floats and stitching the result together:
// vertex shader
vsOut.z_hi = float(z / (1 << 24));
vsOut.z_lo = float(z % (1 << 24));
// fragment shader
uint z = uint(roundEven(vsIn.z_lo)) + uint(vsIn.z_hi * float(1 << 24));
Pretty sure there's still fractional error when done this way. And lacking real games to test the result would be just placebo.
Let's say we solve the problem of 32-bit interpolation however, we could abuse the representation of float and cram ~29 bits of information between 0.0f and 1.0f (using uintBitsToFloat
), With VK_EXT_depth_range_unrestricted
on Vulkan we have ~30 bits to work with. (between 0.0f and FLT_MAX from my test is possible: abs(minDepth - maxDepth) can't be more than FLT_MAX it seemed). May not matter but it's better than the 24-bit we have currently. (In case there's no ROV/FSI support)
the problem with late depth tests is because we do software blending in the shader, a late z test is too late, then the pixel is wrong, even though the Z is now right.
It's a serious chicken + egg problem which we've run in to before :(
but yeah being able to extend the range of the depth is the only real way to fix it, since we only have 23 bits of precision now, 30 would be a huge improvement.
The 30-bit I mentioned is only for storage in depth buffer unfortunately (where only greater or equal matters, not the actual values for perspective). For early z-test and perspective there's only the regular floats apparently.
ROV would have the same restriction it seems.
(It's possible to work around it with one assumption: the depth of each polygon doesn't span a range of more than 24-bit of storage, then we can subtract the depth from a common base for each polygon, say the last vertex in each triangle, still need late z test but help with precision of interpolated depth values) actually may not work I've not checked my math lmao
Edit:
the problem with late depth tests is because we do software blending in the shader, a late z test is too late, then the pixel is wrong, even though the Z is now right.
It's a serious chicken + egg problem which we've run in to before :(
I'm not quite understanding this, depth test is still enabled with late z test anyway so shouldn't there either be the right color or be discarded?
Tellow has proposed an alternative approach previously; (if I remember correctly) take the minimum Z of the primitive, subtract it from the Z which is interpolated, and then re-add it before writing SV_Depth
. This would also solve the interpolation precision problem, but would also require splitting the batch if the Z range across triangles is too large.
It's not something I've addressed in the current iteration of the ROV PR, but yes, long-term we'll probably have to support full integer depth. Note that even software isn't 100% precise in this manner; it uses doubles for interpolating, I'm not sure how the PS2 hardware itself interpolates.
As for hacks, another option is to just scale the depth down to a more restricted range. Sorta like what we do when clip control isn't supported, but instead of clamping to 2^24-1, scale it instead.
@anffss
I took a look at your bug report linked in the OP and could not reproduce it with the latest pcsx2 even without the shader change. Perhaps there have been changes in pcsx2 in the last two years that fixed the bug on the cloth already?
For the hair and whatever you mean by kit model, are you placing the shader in the directory indicated and using the Vulkan renderer? (The shader is for Vulkan only)
Correct me if I'm wrong: the VUs on PS2 used for vertex transform has 24-bit precision as well since they use floats. So how do 32-bits depth even come about? When the VUs convert floating vertexes to integer for the GS, assuming they don't do too many weird post-processing, we don't actually have to worry about splitting triangles into batches, because all the primitive in the same scene would fall into the same 24-bit range.
I don't know if any game does this but it's possible to have different depth base offset in order to render different 3D scenes on top of each other. Otherwise the shader change above would work generally for most games I think.
This also means that we can most likely get away with no rov since it's unlikely a game will have all 8 bits of remaining depth precision to have hundreds of 3D scenes at once.
(Also I realized that late depth isn't needed for the GTA III LCS case above: assuming that the game doesn't use the full 24-bit depth precision, which seems to be the case for some reason, just set the 24th bit always in vertex shader, then the interpolated floating point will have precision exactly to the equivalent integer part without fractional part: tfx.glsl.zip )
There's still some artifact but it can't be helped for now: (ideally this shouldn't have the strips across the decal)
@xzn, of course I'm using one of the latest versions of pcsx2 and vulkan renderer. Shader file copied is in the correct folder (resources/shaders/vulkan). I've tried both the one you posted above and the one a few posts earlier. However, z-fighting persists. That's why I asked if there might be any other options to improve the depth accuracy.
Keep in mind that "depth accuracy" is not only dependent on the emulation, but also on the near/far plane that the game internally uses. Check on your console, it may be that they are only using a small portion of the 32-bit range, and the fighting was just never noticed due to the lower resolution. In which case, there's nothing we can really do about it, as that precision is already lost by the time it hits the GS.
The hair fighting only happens on hardware renderers, not software renderer. Later on Ps2 i will check a dump i took that clearly shows the issue to see if the native resolution hides the fighting. I think this is a case of hardware renderers having less depth accuracy than software renderer.
In my tests all of the zfighting issues disappear with software renderer. In some cases zfighting is there even on Ps2, like on that GTA III dump i took months ago. In that case software renderer is very accurate to how it shows on Ps2 hardware, but on Pcsx2 hardware renderers it really is a lot more noticeable.
Seems same in Van Helsing.
Rule of Rose is another affected game:
https://github.com/PCSX2/pcsx2/assets/60817163/7a98478f-9581-4a4f-833c-cb218a2ed770
@xzn I've tried your shader on King's Field: The Ancient City and it's a definite improvement. I still see some z-fighting rarely but it's also present in software mode.
Castlevania Curse of Darkness as well, as reported here: #11436
I have the same problem in Buffy the Vampire Slayer: Chaos Bleeds. I remember that in past versions there wasn't this problem
https://github.com/PCSX2/pcsx2/assets/80860708/9ffe7c47-214b-467f-a2c4-8c291214fbaa
I opened up a bug report that got closed yesterday but I think I should have just chimed in here instead now that I'm more familiar with pcsc2 issues.
There now appears to be z-fighting issues using the HW renderer with tony hawks underground (THUG) I'm using the newest nightly version.
THUG 2 also has z-fighting issues with the HW renderer as well. It's apparent in the first level (warehouse) by the water by the ramps and the big half pipe.
@xzn Your shader file did reduce the flickering a bit. But it doesn't work in the new version of pcsx2, could you please update it?
Games that have problems with textures flickering over a model. (Due to not knowing what's on top for depth) Avoids making duplicate issues.