I am using clipping planes via standard OpenGL glClipPlane commands to clip my geometry on GeForce3 and experiencing these scenarios. Without clipping my geometry, display is 75.0 frames/sec but with clipping enabled, the frame rate dropped to 15.0 frames/sec. This is the same regardless of the size of the window I use, so I guess fill-rate is not the bottleneck here.
I reckon that the cost of computation of clipping the geometry is now the bottleneck.
I wonder if my deductions are correct because
running the same program on a FireGL4 card, I see a performance improvement when geometry is clipped.
Could anyone shed light on this ?
Well this is not necessarily the case. NVIDIA implements clip planes using texture units.
Your performance improvement on the FireGL may be because the card is fill limited and the clipping is a geometry operation and saves on pixel fill.
On the GeForce3 clipping is a fragment operation (at least that’s how it is implemented, conceptually it is not). And the fragments are not eliminated but rather bust be textured for clipping to be performed, so additional work is done, including geometry setup for texgen style operations and extra fragment texture operations to actually implement the clip.
P.S. I dunno if there’s a software geometry engine fallback when you oversubscribe texture units on the GF3 with clip planes, that may also be an issue.
I’ve been wondering for a while… I can see that it’s easy to implement a clip plane with a texture unit (hell, you can do it yourself with an alpha texture and texgen in 5 minutes). Now, I’m no hardware guru, but maybe it would be worth a consideration to do it differently optionally and let the developer choose which way to clip.
Instead of wasting a texture unit and all the fillrate (rasterization of the clipped fragments, which is still needed when implementing clipping with a texture), it may be worth it in non-T&L-limited cases, if the driver, say, had the hardware transform the geometry once for the clip plane (to get it into clip space for an arbitrary plane), do geometry clipping with the plane, and then push the clipped geometry through the regular pipeline. That would be a performance benefit in all fillrate limited cases, right?
I mean, considering perspective correct texture mapping, this should work just as well, at the caveat of inserting more vertices (which the clipping stage has to do anyway, so no real changes here) and having to transform more.
Am I right or am I not seeing something here?
It requires enough precision in the texture evaluation. Clipping is a real bugbear for geometry pipelines because of the spontaneous creation of polygons, and with a clipplane there’s no guard band cheating. This is probably why NVIDIA went with the texture solution.
I m aware that nvidia implements the clipping planes using texture units.
One texture unit is burnt for doing 4 clipping planes. I have implemented the following 2 ways.
use standard clip plane functions but specifying explicitly GL_TEXTURE2_ARB when enabling GL_CLIPPLANE0 to GL_CLIPPLANE3 and GL_TEXTURE3_ARB for GL_CLIPPLANE4-GL_CLIPPLANE5. Both textures have shader operations set to GL_CULL_FRAGMENT_NV.
Result : clipping improves volume rendering and but not for geometry surfaces. Is this result normal or have I done something wrongly?
specify clipping planes equations in texture matrices following the example “cull_fragment” in the nvidia SDK ,setting GL_CULL_FRAGMENT_NV and turning on texgen GL_OBJECT_LINEAR and GL_OBJECT_PLANE etc.
I use 2 texture units GL_TEXTURE2_ARB and GL_TEXTURE3_ARB.
Result: now both volume rendering and geometry are slow. Again … what might I have done wrongly?
***** Other questions ******
1)If I were to use a vertex program to do the clipping and texgen stuff in it, would it be better than what is achieved in (2) ?
2)If i implement clipping using an alpha texture , would it be better?
- Or would it be advisable to do my own clipping of geometry b4 sending to the pipeline ?
Do your own clipping, if you need the texture unit. It’s straight forward enough - transform the plane into object space, check it against the bounding volume of your object, if it intersects the bounding volume then and away you go and clip the triangles against the object space plane…of course, this will be a big problem if you’re using VAR etc., as you’ll probably have to keep a copy of the verts in system memory, then copy the clipped verts over to agp every frame.
Your performance shouldn’t suffer in the general case, but if you get lots of geometries astride a plane then you will suffer.