How expensive are clipping planes?

Hi

It seems to me that the use of clipping planes is rather expensive. Right now I’m doing a program using projected textures as shadows. The problem with this technique is back projection. In a paper by Cass Everitt he mentions that the problem can be solved by using a 1D texture and then testing for negative q coordinates. Since I have no idea how to implement that codewise, I thought of using a clipping plane instead, thus clipping everything behind the light source away when rendering shadow recievers. This seems to work reasonably well, but it also seems very slow. Can this be true, or is it me who is doing something wrong?

Also if anyone knows of a code example or has written one themselves using the 1D texture to eliminate the back projection problem I would be very interested in seeing it, since that would be my preferable method of solving the problem. Cass own projective texture demo doesn’t seem to account for the problem.

Regards Anders

The Per-pixel spotlights demo on my site uses a 1d texture for this.

One thing to keep in mind here is that non-positive q values can produce unpredictable results. The GL spec explicitly allows things to go off the rails in this case, so you need to be aware this code is not portable. I can’t say it is a problem in practice, but you still need to be mindful of it.

-Evan

Also, when the the q coord approaches zero you might get precision problems. I noticed that while coding that particular demo. I would get a grey flickering area around -0.008 < q < 0.008 (or something like that) on my old Radeon 8500. Had to finetune it to get good results such that it cuts at q = 0.008 instead of q = 0. This have the negative effect that when a polygon get close enough to the light it’ll darken.

Or you draw only the triangels that your projector can “see”. There is really no need to draw the ones that “backproject”.
At least this works in all cases for me.

fritzlang

[This message has been edited by fritzlang (edited 12-09-2002).]

In answer to the clipping plane part of the original question, yes user-defined clipping planes are slow in general.

The DX9 specification requires that cards support 6 user defined clipping planes.

Note that with 2D textures and alpha testing, you can get 2 clipping planes for the cost of a texture unit on plain old hardware. With shader-y things, you can get four clip planes out of texgen (each dotproduct can be compared to > or < 0).

Hi all

First of all, thanks for your answers. From what I can see, I am faced with three possibilities to fix my back projection problem:

1: Use a 1D texture. Since I am still not completely sure how this works and how it should be set up, implementing it will be a problem. Humus, thanks for the link, but the source you provided, does not seem to include spotlight.h and texture.h. Would it be possible to see those, or are they intentionally left out of the source package? If so, could you please post a code snippet, where you create and set up the 1D texture, with a little explanation?

2: Use a user defined clipping plane. This seems to work O.K., but it also seems computationally expensive and thus gives an undesireable frame rate hit.

3: Draw only the triangles recieving the shadow. This seems like a good solution, but it will require more CPU computations, but in the end less triangles will be sent to the GPU. I am not experienced enough to judge if this will be more or less effecient than using the 1D texture, but perhaps some of you can help. Besides this would also free up a texture unit.
I would do it in the following way:
First go through all object faces (consisting of triangles) and check wether they are in front of or at least partially in front of the light source.
If so, then test each individual triangle in the face against the lights field of view and store all triangles intersecting the lights view frustum in a list.
Finally send all those triangles to the GPU. Does this sound like a reasonable way of doing it?

Regards Anders

And what about stencil buffer ?