Suppose that I have some world-space volume (which we may assume is a convex polyhedron with a small number of vertices), and I want to render its intersection with the view frustum, such that every relevant pixel gets rendered exactly once. My use-case is rendering light influence volumes for a deferred renderer, but I guess there may be other uses for this.
Everything is fine as long as the volume is completely behind the near clipping plane (i.e. isn't clipped by the near z-plane): rendering with back-face culling does the job, thanks to convexity of the volume. If, on the other hand, the volume intersects the near z-plane a bit, the intersection area gets clipped, but there are still parts of the volume behind this area that didn't get rendered. We could switch to front-face culling, but that breaks if the volume intersects the far z-plane. The volume could theoretically intersect both z-planes, so this problem cannot be solved simply by adjusting the culling mode. The volume could as well completely embody the view frustum, in which case nothing will be draw at all (all triangles outside the frustum), while in reality I'd like it to be rendered as if I'm rendering a fullscreen quad (since the intersection of the volume and the frustum equals the frustum).
Right now my solution is to check if any of the volume's vertices are in front of the near z-plane (i.e. are clipped by the near z-plane) and resort to a fullscreen quad in this case. It works fine, but I'm curious whether there is a better solution.
One solution that I don't particularly like is actually computing the mesh of the intersection of volume and the view frustum (both are convex polyhedrons, which should simplify the job a bit). It has the following disadvantages:
- I have to either find a good enough library for mesh intersection, which means adding another dependency for the engine, or write the intersection code myself
- More importantly, even if the intersection is computed with maximal possible precision, it still goes through the vertex shader, gets multiplied by the view-projection matrix, with numerical errors inevitably introduced. Then, a vertex at z=near may appear at z=near+/-error, and it might still be erroneously clipped.