What Realy Gets Drawn in OpenGL

Whan you set up a clipping volume does all the geometery get drawn (even that outside the clipping volume)? It would seem to me that it much, but I’m not sure. Also it would make sence to me that the clipping would be performed then texturing so only objects in the clipping volume. Is this correct?

Thanks for the answers, I’m finally trying to figure out how to start making my programs more efficent.

Come on someone must know this.

Only what’s inside the clipping volume is drawn. If an object is partially outside it the part that is outside will be clipped.

Then what is the purpose of portal and BSP trees which are supposed to increase rendering time by reducing the amount that has to be rendered. I guess these things could help a little bit, but overall these sort of things wouldn’t be useful if what you just said is true. Can anyone elaborate futher?

You use BSP trees to determine which polygons are visible from any cameraposition.
Imagine you are standing in a room. You can see the four walls in the room. You can see a wall in the corridor (the one facing you) outside the room, but not the wall not facing you (the other side of the corridor). This wall is indeed inside the clipping volume, but is not visible, nor is all other polygons builing up your world. From a point in the tree, you can determine what polygons are visible, and only render them.
Not too deeply explained, but at least something…

ribblem:
Clipping is different from hidden surface removal. You can use the Zbuffer of OpenGL to do HSR, but you still render every single primitive in the view. The Zbuffer is then checked to see what is rendered into the frame buffer.

A BSP tree renders a subset of the primitive set. You still need a zbuffer, because of overdraw which can reach up to 200%.

A portal HSR system, only draws primitives that are visible so it eliminates overdraw and thus the need for zbuffer. (though some use the zbuffer for rendering objects not part of the world).

Because a portal engine requires that all cells be convex, a BSP-portal hybrid will probably result in a faster HSR.

/skw|d

If the BSP tree stores the visible faces in a node, you can tesselate the world forehand and sort it far->near. That should avoid the zbuffer test. And if the world is sorted somewhat concave or something else, you could draw the given node, and then the objects inside, because they probably won’t intersect.
Anyway, PVS’s will probably not be able to do that, or you sort the visible polys by nodes, which will reduce some speed.

Hey Michael how’s it goin?

Wouldn’t you want to tessellate on the fly based on camera angle and such? I like to do that because curved surfaces don’t need much detail when the camera is perpendicular to the surface. I can then allow much higher detail in my worlds for the same framerate. But maybe this just optimizes for my specific rendering requirements.