How should I handling clipping vertices that are closer to the eye than the near clip plane?

Question

I'm rolling my own 3D engine, in JavaScript, and using only canvas drawing, no WebGL. This is another Minecraft clone; I love boxes, don't judge me.

So far, everything works wonderfully, except for one thing: in 3D, when some vertices go behind the near clipping plane, their projection on the screen comes out weird (assuming other vertices used to trace a plane are in front).

I tried clipping these points but then I can see trough the surfaces that use these vertices. In WebGL/OpenGL the graphics card takes care of these points and the plane is rendered correctly, but I don't have access to hardware so I must code this myself.

I'm not quite sure what to make of it, currently the last thing that came to mind is to reverse the projection of points behind the player's near clipping plane, which seems logical since I must project a point to a screen which is in front of the vertex.

Here are my thoughts:

Here are some images to illustrate what happens:

From distance the blue box renders perfectly well.

When some of the vertices go behind the player's near clipping plane I do reverse projection, but it doesn't look right:

focalLength *= -1;
2d.x = x*focalLength/z;
2d.y = y*focalLength/z;

Note that the gray box behind is completely removed since all the vertices used to draw its faces are behind the player.

This is what happens when look up or down.

I don't know what to make of the math behind this, I'm hoping somebody has encountered the same problem already and can help me.

Answer 1

The purpose of the near clipping plane is that it is a clipping plane. Triangles that are outside of a clipping plane are clipped: cut into pieces so that each piece that is left is within the clipping region.

You can attempt to ignore the near clip if you wish. Indeed OpenGL and D3D have ways of turning off near plane clipping altogether (though the depth buffer still has a minimum near value). The problem is not the near clip.

The problem is with vertices that are behind the camera.

You cannot render triangles that are behind the camera. Not with a perspective projection. Such triangles do not make sense under the math behind perspective projections. Furthermore, they are also outside of the frustum.

Turning off near clipping turns a frustum into a pyramid. The reason the pyramid stops at the point is because points above the pyramid are behind all four of the sides of the pyramid. So any point behind the camera (the tip of the pyramid) is above, below, to the left, and to the right of the visible region of the screen. All at the same time.

As I said: vertices under a perspective projection that are behind the camera don't make sense.

You must implement clipping. You must detect when any vertex of a triangle, in clip-space (before the perspective divide) is behind the camera. If it is, then you must clip that triangle, generating only triangles that are in front of the camera.

This is not a simple process. It will involve math that only makes sense if you have a full understanding of homogenous coordinate systems. Alternatively, you could just straight-up cull any triangle if any vertex of it is behind the camera.

Answer 2

I know this is probably a bit late, but I have a solution to this.

The transformation from world coordinates to points on a screen involves multiple parts, which involve subtracting the camera's coordinates, rotating around the camera, and then dividing by the axis perpendicular to the camera. (generally the Z axis.)

The problem with the clipping happens with the divide, because division by negative z indexes and coordinates close to 0 result in huge values, so the clipping algorithm is done just before that, but after the coordinates have been rotated and transformed.

Having the points of the face you want to clip in an array helps for organization. The algorithm goes through each point, sees if it's clipped or not, and then creates new points based off of that.

I apologize if I wasn't completely clear. Here's my code:

//loop through all points
for (var y=0;y<tempPoints.length;y++) {
    //if the selected point will be clipped, run the algorithm
    if (tempPoints[y][2] < render_clipDistance) {
        //freefriends is the number of adjacent non-clipped points
        var freeFriends = (tempPoints[(y+(tempPoints.length-1))%tempPoints.length][2] >= render_clipDistance) + (tempPoints[(y+1)%tempPoints.length][2] >= render_clipDistance);

        if (freeFriends == 0) {
            //if there are no free friends, there's no point in attempting, so just move on
            tempPoints.splice(y, 1);
            y -= 1;
        } else {
            //move towards friends
            var friendCoords = tempPoints[(y+(tempPoints.length-1))%tempPoints.length];
            var moveAmount = getPercentage(friendCoords[2], tempPoints[y][2], render_clipDistance)
            var newPointCoords = [linterp(friendCoords[0], tempPoints[y][0], moveAmount), linterp(friendCoords[1], tempPoints[y][1], moveAmount), render_clipDistance + 0.05];

            tempPoints.splice(y, 0, newPointCoords);

            y += 1;

            friendCoords = tempPoints[(y+1)%tempPoints.length];
            moveAmount = getPercentage(friendCoords[2], tempPoints[y][2], render_clipDistance)
            newPointCoords = [linterp(friendCoords[0], tempPoints[y][0], moveAmount), linterp(friendCoords[1], tempPoints[y][1], moveAmount), render_clipDistance + 0.05];
            tempPoints.splice(y, 1);
            tempPoints.splice(y, 0, newPointCoords);
        }
    }
}

Answer 3

If part of the triangle in behind the near plane could you then do a per-pixel check to see if the pixel position is behind the clipping plane?

You might treat the near plane like any other clipping plane. For example clipping planes are used for things like water planes (for reflections and refractions). I would think that this clipping plane would work just like the near clipping plane, and clip on a per-pixel basis.

I know how to handle clipping planes in HLSL with DirectX, but their implementation could be proprietary. If you could get a hold of the info for that it might be helpful.

Additionally here is a link that might help you: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter42.html