PDA

View Full Version : Working in screen space

DaMangz
10-26-2002, 09:12 PM
Is there a reason to find out if a triangle is front or back facing in screen space coordinates? It seems peculiar to me why you would want to do this, but I am wondering if there is a reason you would want to do this and why?

Thanks

zed
10-27-2002, 10:23 AM
before hardware t+l cards u used to do this to see if a triangle would show up on screen or not, if not then u wouldnt send it (resulting in a performance boost quake1-3 use this i assume) but nowadays its (usually) quicker to send all the triangles to the card + let the card deal with backface culling

scriptlord
10-27-2002, 10:29 AM
glFrontFace(GL_CW);
This tells the comp that all clockwise-wound triangles are facing front

fresh
10-28-2002, 12:22 PM
It's more difficult to determine facingness in camera space because a triangle which may be back facing in camera space, could be front facing in screen/ndc space after the perspective divide. Most implementations simply find the signed area of the triangle and use that to determine which way it's facing.

Korval
10-28-2002, 02:06 PM
Is there a reason to find out if a triangle is front or back facing in screen space coordinates? It seems peculiar to me why you would want to do this, but I am wondering if there is a reason you would want to do this and why?

Well, for several reasons.

One, it is far easier to tell what the winding order of the triangle is in camera/screen space (it doesn't matter which) than it is in model space. In screen space, it comes down to a cross product and a compare with the result. In model space, you have to get a normal (via cross product), dot that normal with the view vector (acquired from the modelview matrix), and do a compare of the result. That slower than just a cross product and compare operation.

Two, these days, the transformation from model to screen is programmable; it need not be a mere matrix transform (skinning comes to mind). In these cases, there may not even be model space coordinates; maybe you're tesselating a bezier spline in a vertex program.

Three, even before the days of hardware T&L, vertex arrays made it difficult for a software driver to pick out vertex data. For a driver to do pre-T&L backface culling, it would have to walk a vertex array and test each triangle. If a trangle was backfaced, it would then have to remove it from the tri-strip and create two (or more) strips where there was only one originally. Since even TNT hardware supported tristrips natively, this meant that the driver would have to render one strip, wait till that finishes, then render the next. This causes a stall in glDrawElements(). Nobody likes stalls, especially in rendering functions, and glDrawElements does some stalling a lot of the time anyway; no need to add more to it.

mattc
10-28-2002, 05:40 PM
plus, the less data you send to the graphics card, the less memory bandwidth you're using - if you can quickly discard stuff before sending it to the card, do it.

jwatte
10-28-2002, 06:30 PM
Chances are, you're going to be CPU limited in your app on a HT&L card; and if you're not CPU limited, you're probably fill limited.

Thus, letting the card DMA all the data and sorting it out is a net win, because typically it's using AGP bandwidth (not VRAM, needed for fill rate) and the CPU doesn't have to touch the data at all.

EDIT: clearly, you should cull out entire meshes when they're not intersecting the frustum, or when your portal/zone system tells you they're not visible, or whatever. Just don't touch any data within each mesh, if possible.

[This message has been edited by jwatte (edited 10-28-2002).]