Re: [PATCH 4/5] wined3d: Don't use the depth range clipping hack when we have ARB_depth_clamp.
On Tuesday 19 January 2010 2:52:28 pm Henri Verbeet wrote:
ARB_depth_clamp should give pretty much the desired behaviour by clamping instead of clipping depth values outside the depth range.
I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in state_clipping if you're going to bypass the depth range hack with it. Currently it's only called if WINED3DRS_CLIPPING is off.
2010/1/20 Chris Robinson <chris.kcat(a)gmail.com>:
I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in state_clipping if you're going to bypass the depth range hack with it. Currently it's only called if WINED3DRS_CLIPPING is off.
Possibly, but it's not clear from the description of that hack that it's required. The code certainly doesn't disable user clip planes either.
On Tuesday 19 January 2010 3:37:50 pm Henri Verbeet wrote:
2010/1/20 Chris Robinson <chris.kcat(a)gmail.com>:
I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in state_clipping if you're going to bypass the depth range hack with it. Currently it's only called if WINED3DRS_CLIPPING is off.
Possibly, but it's not clear from the description of that hack that it's required. The code certainly doesn't disable user clip planes either.
The comment says that it's using MinZ/MaxZ to suppress depth clipping, which could otherwise occur with 0..-1. GL_DEPTH_CLAMP needs to be enabled if 'untransformed' is false, to suppress depth clipping as intended. Since the transformed-vertex path is there to bypass transformation and frustum clipping, it would make sense to clamp and disable user clip planes, too (but as you said, that's not current behavior, so may need to be tested; same for viewport clipping).
Am 20.01.2010 um 01:08 schrieb Chris Robinson:
The comment says that it's using MinZ/MaxZ to suppress depth clipping, which could otherwise occur with 0..-1. GL_DEPTH_CLAMP needs to be enabled if 'untransformed' is false, to suppress depth clipping as intended.
Since the transformed-vertex path is there to bypass transformation and frustum clipping, it would make sense to clamp and disable user clip planes, too (but as you said, that's not current behavior, so may need to be tested; same for viewport clipping). I am ok with the patch being committed, as in the worst case this is just a hack replaced by another hack, and it seems right to me.
That said, I was trying to write some tests about the d3d9 D3DRS_CLIPPING behavior, and it seems the near and far clip planes are still used when it is disabled. I can think of 3 other cases: * There's a different behavior in ddraw. The two games I remember that are affected by the clipping are Half Life 1 and Prince of Persia 3D. I can't think of any d3d8 and d3d9 apps. * There's some other state involved I missed in my quick and dirty testing. My only systematic testing so far was about the glDepthRange-like behavior of minZ and maxZ. Both games use RHW vertices. Currently the glOrtho minZ / maxZ hack is used for RHW vertices only. * The near and far clipping planes are supposed to be enabled even in these two games, but something else is going wrong and the games are sending wrong depth values to ddraw. HL1 uses ProcessVertices, but pop3D uses its own software vertex processing, and I don't think we can screw this up in a subtle way that breaks the depth but not X or Y.
2010/1/20 Stefan Dösinger <stefandoesinger(a)gmx.at>:
I am ok with the patch being committed, as in the worst case this is just a hack replaced by another hack, and it seems right to me.
That said, I was trying to write some tests about the d3d9 D3DRS_CLIPPING behavior, and it seems the near and far clip planes are still used when it is disabled. I can think of 3 other cases:
* There's a different behavior in ddraw. The two games I remember that are affected by the clipping are Half Life 1 and Prince of Persia 3D. I can't think of any d3d8 and d3d9 apps.
* There's some other state involved I missed in my quick and dirty testing. My only systematic testing so far was about the glDepthRange-like behavior of minZ and maxZ. Both games use RHW vertices. Currently the glOrtho minZ / maxZ hack is used for RHW vertices only.
* The near and far clipping planes are supposed to be enabled even in these two games, but something else is going wrong and the games are sending wrong depth values to ddraw. HL1 uses ProcessVertices, but pop3D uses its own software vertex processing, and I don't think we can screw this up in a subtle way that breaks the depth but not X or Y.
I'm somewhat tempted to just kill the hack and see what breaks. It would have been nice if there were tests for this, of course.
Am 20.01.2010 um 08:45 schrieb Henri Verbeet:
I'm somewhat tempted to just kill the hack and see what breaks. It would have been nice if there were tests for this, of course. Feel free to kill it - I can try to get it back in place once I can reproduce the POP3D behavior in tests, or we just tell people to get a driver with either ARB_depth_clamp or NV_depth_clamp(read: lobby Mesa to support this extension)
2010/1/20 Stefan Dösinger <stefandoesinger(a)gmx.at>:
Feel free to kill it - I can try to get it back in place once I can reproduce the POP3D behavior in tests, or we just tell people to get a driver with either ARB_depth_clamp or NV_depth_clamp(read: lobby Mesa to support this extension)
IIRC at least the Intel drivers support ARB_depth_clamp, not sure about others.
On Tuesday 19 January 2010 11:38:18 pm Stefan Dösinger wrote:
Am 20.01.2010 um 01:08 schrieb Chris Robinson:
The comment says that it's using MinZ/MaxZ to suppress depth clipping, which could otherwise occur with 0..-1. GL_DEPTH_CLAMP needs to be enabled if 'untransformed' is false, to suppress depth clipping as intended.
Since the transformed-vertex path is there to bypass transformation and frustum clipping, it would make sense to clamp and disable user clip planes, too (but as you said, that's not current behavior, so may need to be tested; same for viewport clipping).
I am ok with the patch being committed, as in the worst case this is just a hack replaced by another hack, and it seems right to me.
From what I understand, the idea of the patch (map z to 0..-1 with depth- clamp) is correct. It may even fix the issues with HL1 as it will write the correct (unmodified) depth values, and avoid clipping the weapon on the near plane. The problem I see with the patch is, depth-clamping is left to the D3DRS_CLIPPING state which is supposed to be bypassed for transformed vertices.
Essentially, if D3DRS_CLIPPING is on and ARB_DEPTH_CLAMP isn't supported, it would use the hack on transformed vertices to attempt to suppress clipping on the near/far planes. If D3DRS_CLIPPING is on and ARB_DEPTH_CLAMP /is/ supported, then it would avoid the hack even though the exact same GL clipping rules are in effect.
Am 20.01.2010 um 09:17 schrieb Chris Robinson:
From what I understand, the idea of the patch (map z to 0..-1 with depth- clamp) is correct. Fwiw, I attached my minZ and maxZ patches here. They are patches 6 and 7, the other 5 patches are some patches close to hack quality(esp 0002) to shut up some d3d9 test failures on geforce 8 cards. The minZ/maxZ tests should be split up in two parts: One non-rendering test that tests the output value of SetViewport by calling GetViewport, and one rendering test that does the actual test for different(non-equal) Z values.
Wrt clipping, what I tried was setting D3DRS_CLIPPING to TRUE and FALSE in various places of the z_range_test, but I did not see any effect. z_range_test also tests rhw vertices, so if using rhw disabled the near and far clipping planes it would show up there. I guess the next step would be to port the z_range_test to the d3d8 and ddraw testsuite and see if the behavior differs.
participants (3)
-
Chris Robinson -
Henri Verbeet -
Stefan Dösinger