On Fri Mar 8 15:33:07 2024 +0000, Jeffrey Smith wrote:
Yes, depth-clipped. If I'm understanding your last statement properly, it doesn't seem right. Two triangles could share one or two vertices and still be clipped independently. Further, several of the quads in this test have all vertices outside of [0,1] depth range, yet the portions passing through that depth range do result in successful picks.
What I mean with the last statement is that clipping is not done by the actual drawing step, but by the preceding "process vertices" step. It looks like D3DPROCESSVERTICES_TRANSFORM performs clipping and presumably D3DPROCESSVERTICES_TRANSFORMLIGHT does as well, whereas D3DPROCESSVERTICES_COPY just blindly copies, as the name implies. If you then draw the blindly copied triangles they result in picks.
In d3dexecutebuffer we can't look at the vertex processing output. IDirect3DVertexBuffer7::ProcessVertices does allow you to look at the intermediary output, and I remember trying to make sense of its clipping operation as one of my first acts of Wine development back in 2005 and couldn't figure it out. I'm not asking you to try, I was merely commenting that clipping being part of vertex processing, not drawing, makes sense :-) .
A clipped vertex still ended up in the destination vertex buffer, and it has to, because otherwise the draw parameters wouldn't match up (you process 10 triangles / 30 vertices, draw 10 triangles, but 5 of those triangles got clipped? What now?). Otoh math dictates that a clipped triangle might end up as a quad, e.g.:
-------------------- | | | 1.........A.........3 | . | .... | . ..B.. | . .... | | 2... | | | | | --------------------
If that little ASCII art makes any sense. The triangle 1-2-3 turns into a quad 1-2-B-A. So somehow this needs to be handled, and I have no clue how. The ProcessVertices docs talk about an "internal buffer" storing "clipping codes". I don't think we really care unless we find an application that cares.
Half Life 1 uses ProcessVertices in its d3d renderer (which has been removed long ago from the Steam version of the game), and it requests clipping, but it is just happy if we don't clip in ProcessVertices and let GL figure it out during drawing.
I assume the reason why you get pick results outside the x/y limits of the framebuffer is the guard band: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/guard-ban... . Long story short, actual geometry clipping is annoying, so GPUs pretend the framebuffer is much larger, don't modify geometry if possible and discard fragments outside the framebuffer later.