Hello, I'm trying to implement a software-based rendering engine that is largely based on Direct3D's design. I want to fully understand what are the exact semantics involved when transforming and clipping vertices. Here's what I figured out thus far. for each vertex v: - compute (x, y, z, w) = v.pos * W * V * P {for world, view, projection matrices) - If clipping is enabled, compute clipping flags using the comparisons x <-w, x > w, y <-w, y > w, z < 0, z > w - If clipping flags are all clear, apply the viewport transform (Vp) and divide by w, in place, to obtain XYZRHW coordinates: w = 1 / w x = Vp._11 * x * w + Vp._41 y = Vp._22 * y * w + Vp._42 z = Vp._33 * z * w + Vp._43 Now, it is important to notice that Vp._33 can be zero, if viewport's min and max z values are equal (which is a legitimate setting), which means that this transform may not be reversible for the Z coordinate. Also, clipping is supposed to take place in XYZW space. So, one would need to reverse the XYZW -> XYZRHW transform whenever feeding a non-clipped (within frustum) vertex into the clipper, so a non-reversible transform causes problems. How is it handled in Direct3D, anyone knows? Another thing, what about user-supplied XYZRHW vertex buffers? How does the runtime distinguish between XYZRHW vertices inside the frustum and XYZW vertices outside the frustum? (it can't rely on clipping flags since it didn't do the transform). Does that mean clipping isn't supported for user-supplied XYZRHW vertices?

If the vertices were transformed by ProcessVertices, there will be an internal buffer that contains the state of the clip test for each vertex. The transformed vertices in the destination VB will be in either clip space or screen space, depending on whether or not they lie outside or inside the viewing frustum or not. This is done so that vertices that lie outside of the frustum don't have to be back-transformed from screen space to clip space in order to calculate the clip intersection with the frustum planes prior to rasterization.

So the resulting XYZRHW buffer's vertices can be frustum clipped, but they must have been processed by PV and have an internal clip state buffer. There's no way to access this clip state buffer directly, so if you are performing transforms yourself, you should be doing your own clipping (or rely on guard bands, as Richard noted).