flipCode - Tech File - Jeroen Bouwens [an error occurred while processing this directive]
 Jeroen Bouwens Click the name for some bio info E-Mail: flipcode@jeroen.ws

 05/04/1999, 3D Clipping

Allright, here's an update on Manic Motion. I've spent the last couple of days implementing a 3D-clipping system. Like I said before, that's when one of the real advantages of homogeneous coordinates come into play. After a homogeneous perspective transform (ie. a transformation to the perspective space I talked about last time), the W-coordinate contains the clipping boundary for X, Y and Z. Yes, one clipping value for all.

Basically, the clipper as it is now is based on the standard Sutherland-Hodgeman clipping algortithm. The only thing that's different is the calculation of the distance to the clipping plane. Here's a piece of code:

 ``` SCount = 0; for (i=0;iCoords[k].W)) {//Edge goes from in to out. Write intersection point to second table if ((Coords[i].W!=Coords[k].W)||(Coords[i].X!=Coords[k].X)) Fraction = (Coords[i].X-Coords[i].W)/(Coords[k].W-Coords[i].W-Coords[k].X+Coords[i].X); TmpCoords[SCount].X = Coords[i].X + (Coords[k].X-Coords[i].X)*Fraction; TmpCoords[SCount].Y = Coords[i].Y + (Coords[k].Y-Coords[i].Y)*Fraction; TmpCoords[SCount].Z = Coords[i].Z + (Coords[k].Z-Coords[i].Z)*Fraction; TmpCoords[SCount].W = Coords[i].W + (Coords[k].W-Coords[i].W)*Fraction; SCount++; } if ((Coords[i].X>Coords[i].W)&&(Coords[k].X

This particulair piece clips a polygon against the right plane of the viewing-frustum. Note the if-statements, where each X-coordinate is checked against the W-coordinate of that same vertex. For the left plane, each coordinate is checked against -W. This is clearly faster than finding the distance to a plane using classic 3D coordinates.

The only disadvantage I've come across so far is that it is not yet possible to define an arbitrary clipping plane. Now I don't think Manic Motion will be a portal-based engine, but there are other uses for this as well. However, I think it will be possible by tweaking the perspective matrix. Maybe more on that later.

There's also an updated test-application. The most obvious change is the group of CPU-usage bars. These only give meaningful values when displaying 1000 objects, because of the resolution of the timer (1/18.2 second intervals). One interesting thing is that the actual drawing of the faces takes up about half the CPU-time. That's way too much in my opinion, so lot can be optimized there. Try switching off the 3D-clipping. You can see the complete rejection of entire objects at work on the left and right sides. Oh, and don't try gouraud-shading with 3D-clipping on (you're going to anyway, aren't you? :).

Well, that's it for the moment. I'm working on the C-Buffer implementation now. For flat-shaded non-textured polygons it doesn't seem to be faster than just drawing the faces back to front with a normal poly-filler, but that's no surprise really :). Finding an efficient way to manage the segments is a bit of a challenge really.

Enjoy life,

Jeroen

• 04/01/2002 - Thoughts On Software Development
• 09/10/2000 - Observe Your Objects
• 01/31/2000 - Factories
• 09/14/1999 - Polymorphism and Inheritance
• 08/14/1999 - Object Design
• 06/04/1999 - OpenGL Mania
• 05/04/1999 - 3D Clipping
• 04/29/1999 - Introduction

• This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.