View Full Version : slow clip planes

04-30-2002, 12:10 AM
Hi !
Does anyone know why user clip planes are sooooo slow ? With the latest Detonator driver for my Geforce3, the rendering speed drops from ~70fps downto 7fps, using only a single additional clip plane. I'm using the clip planes for mirrors and textured spot lights.
I already asked at Nvidia, if this is normal, but did not get an answer yet.
Does anyone have the same experience ?

04-30-2002, 12:15 AM
Clipplanes use texture units (you get 2 clipplanes per unit if I'm right)
If you already use all the available texture units it will fallback to software clipping.

04-30-2002, 12:48 AM
Yes, that would make sense. But the performance drop from 70 to 7 fps is with only using one (from two) texture units.
Maybe clip planes are now always in software. I had some strange effects with some older driver's: the side of which objects were clipped changed according to whether the second texture unit was used or not. I was really spending nights while searching a bug in my program and I was almost getting mad to understand this strange dependence. Now with the newer drivers, atleast this problem disappeared but having such a big drawback in speed is not acceptable.
Also to mention is, that using a clip plane changes the depth values slightly, even if the polygon to clip lies completely on the visible side. This did not occur with older drivers and now causes problems with multipass rendering( first pass without clip plane and following passes with a plane).
So it seems, that I can only hope that nvidia will improve their drivers.

Originally posted by Pentagram:
Clipplanes use texture units (you get 2 clipplanes per unit if I'm right)
If you already use all the available texture units it will fallback to software clipping.

04-30-2002, 08:56 AM
You can easily implement clip planes yourself using a 2x1 texture that's opaque in one pixel, and transparent in the other, and use the appropriate texgen to map fragments to the right pixel.

Then enable alpha testing, and you're set. This way, you're in full control, and you don't need to rely on unknown driver implementations.

04-30-2002, 09:16 AM
Yes, to jwatte you listen http://www.opengl.org/discussion_boards/ubb/smile.gif.

I've always used a 2x1 texture for eliminating backprojection from spot lights. The invariance issues introduced by using clipping planes is what can be expected, so that alone is a good reason to use a texture.

About the performance problems you're having - are you using VAR ? I've previouly had performance problems due to hitting a software path in the driver while using VAR ( for example, using a projective texture matrix on GeForce1 ).

05-01-2002, 11:51 PM
Thanks to all contributors !
For the textured spotlights, it would be necessary to use a 3D texture, I guess, (one layer with the spotlight and alpha set to one and the other layer with all alpha set to zero for all texels). Then the alpha test would discard the fragments, that are behind the light. But the drawback of this method is that the alpha component can not be used for alpha blending anymore.

Another way would be the "CULL_FRAGMENT_NV" texture shader extension, which allows 4 clipping planes per texture unit, but with the drawback, that normal texturing can not be done with the TU anymore (and I only have 2 TUs).

Does VAR mean Vertex Array, PH ?? I do not use them, only display lists.

05-02-2002, 05:25 AM
VAR is short for NVIDIA's extension NV_vertex_array_range. It allows you to use AGP and videomem for you vertex attributes. If the driver forced to switch to a software path, then the driver has to read from this memory ( which will result is drastically reduced performance ).