groverburger / g3d

Simple and easy 3D engine for LÖVE.
MIT License
567 stars 35 forks source link

z-order issues? #11

Closed 4aiman closed 3 years ago

4aiman commented 3 years ago

I doubt I can explain better than this little test project of mine.

4aiman commented 3 years ago

Also, the normals in the demo are flipped. Plus, due to the issue, the background is being drawn above everything else (even if I go outside the BG sphere) image image

groverburger commented 3 years ago

This is an interesting problem - your g3d_test.zip project seems to work fine for me. The near cubes appear to overlap far cubes as they should.

1611180670

This backwards depth-sorting issue appears to be a graphics card problem as it only occurs on some computers. What GPU are you running this on? A quick fix for making g3d work for you would probably be changing the depth mode from the default love.graphics.setDepthMode("lequal", true) to love.graphics.setDepthMode("gequal", true), changing the depth comparison in the depth mode.

In order to work around this problem in the long run, some depth testing tricks may have to be pulled on g3d's initialization to determine which depth mode would be correct.

As for the normals in the built-in demo, the models were flipped to account for their backwards UV coordinates. I just pushed a change to correct this on the model itself instead of flipping the model at runtime, although the normals of the models shouldn't matter as they aren't used in any shader.

4aiman commented 3 years ago

Running GTX1660 Super with the Studio Driver v 460.89. The same issue was present on an older game-ready driver (450-ish).

The love.graphics.setDepthMode("gequal", true) did nothing, the picture is the same in any of the two modes. Tried both mine and demo projects.

Also, not that it matters now (as I can see the difference on your screenshot), the idea behind the test project is to be inside the "cubes".

I think I've found the source of the issue.

print( love.graphics.getRendererInfo( )) yields OpenGL 3.3.0 NVIDIA 460.89 NVIDIA Corporation GeForce GTX 1660 SUPER/PCIe/SSE2 which is weird, since the GPU is capable of OGL 4.6.

Love2d v 0.10.2 returns this OpenGL 4.6.0 NVIDIA 460.89 NVIDIA Corporation GeForce GTX 1660 SUPER/PCIe/SSE2 which is perfectly fine.

And when I try Angle with 11.3, I'm getting this OpenGL ES OpenGL ES 3.0.0 (ANGLE 2.1.14699 git hash: 60015ff672d9) Google Inc. ANGLE (NVIDIA GeForce GTX 1660 SUPER Direct3D11 vs_5_0 ps_5_0) and the issue persists.

I've tried x86 and x64 versions of love2d, to no avail. Since love2d v 0.10.2 gets it right, it's probably something introduced in love 11. And it goes back to 11.0.

Guess, this can be closed then. Sorry for any inconvenience. I'll re-post this on love2d forums.

Thanks! 🥇

groverburger commented 3 years ago

Yeah, inside the cube everything looked normal - I just saw the inside of the cube :P| Looks like I might want to do some investigation on that. Maybe g3d should just always use a canvas to be safe. Thanks for your detailed analysis!

WestonHanners commented 3 years ago

I know this is closed, but I wanted to add I see the same issue on OpenGL 3.3.0 NVIDIA 460.89 NVIDIA Corporation GeForce GTX 1080/PCIe/SSE2 Using the latest release of g3d Did we ever discover why this may be happening?

4aiman commented 3 years ago

@WestonHanners I think it's a love2d 11.0 thing, than g3d's. I may be wrong ofc.