ei05tbe

11-17-2010, 12:07 PM

I know it can be enabled in openGL and I don't have to do it bye my self. How are open GL implementing it? Where can I found information about this.

View Full Version : Is backface culling implemented in hardware

ei05tbe

11-17-2010, 12:07 PM

I know it can be enabled in openGL and I don't have to do it bye my self. How are open GL implementing it? Where can I found information about this.

ZbuffeR

11-17-2010, 12:28 PM

It is pretty simple actually.

It is just done by looking at the sign of the cross product betwen 2 edges of a triangle, after 2D projection. That is why face winding (clockwise or counter clock wise) must be consistent.

Some more details on the first slides here :

http://www.cs.binghamton.edu/~reckert/460/lect20_2010_Culling_Bezier_Patches_3D-OpenGL.pdf

It is just done by looking at the sign of the cross product betwen 2 edges of a triangle, after 2D projection. That is why face winding (clockwise or counter clock wise) must be consistent.

Some more details on the first slides here :

http://www.cs.binghamton.edu/~reckert/460/lect20_2010_Culling_Bezier_Patches_3D-OpenGL.pdf

overlay

11-17-2010, 01:30 PM

You can read the OpenGL spec.

For example, OpenGL 4.1 Core Profile Specification (updated July 25, 2010) http://www.opengl.org/registry/doc/glspec41.core.20100725.pdf

from http://www.opengl.org/registry/

section 3.6.1 Basic Polygon Rasterization, page 168.

"The first step of polygon rasterization is to determine if the polygon is back-facing or front-facing. This determination is made based on the sign of the (clipped or unclipped) polygon’s area computed in window coordinates. One way to compute this area is[...]"

For example, OpenGL 4.1 Core Profile Specification (updated July 25, 2010) http://www.opengl.org/registry/doc/glspec41.core.20100725.pdf

from http://www.opengl.org/registry/

section 3.6.1 Basic Polygon Rasterization, page 168.

"The first step of polygon rasterization is to determine if the polygon is back-facing or front-facing. This determination is made based on the sign of the (clipped or unclipped) polygon’s area computed in window coordinates. One way to compute this area is[...]"

david_f_knight

11-17-2010, 02:17 PM

Actually, what ZbuffeR wrote is correct. The way the OpenGL spec shows to compute the area is actually... the cross product divided by two. But the division by two factor doesn't affect the sign, so it's just as ZbuffeR wrote. (The spec talks about polygons, but that means triangles (and only triangles) because those are the only polygons current hardware can rasterize. If it DID include quadrilaterals or other polygons, then it would be WRONG because those polygons need not be planar and could have parts that are front facing and other parts that are back facing.)

Alfonse Reinheart

11-17-2010, 06:17 PM

If it DID include quadrilaterals or other polygons, then it would be WRONG because those polygons need not be planar and could have parts that are front facing and other parts that are back facing.

The compatibility spec is quite clear on this point: if a quadrilateral or polygon is not properly co-planar and convex, then the results of rendering them is undefined. So they do need to be planar in order to have reasonable results.

The compatibility spec is quite clear on this point: if a quadrilateral or polygon is not properly co-planar and convex, then the results of rendering them is undefined. So they do need to be planar in order to have reasonable results.

ei05tbe

11-17-2010, 11:39 PM

Thank you for replaying. I now understand how the it is implemented. But is it implementet in hardware?

aqnuep

11-18-2010, 12:52 AM

Obviously, as otherwise all the primitives after the 2D projection would need a transfer to CPU and then back to the GPU.

However, take this answer with caution as for very old 3D accelerators where only the rasterization was hardware accelerated this may not apply.

However, take this answer with caution as for very old 3D accelerators where only the rasterization was hardware accelerated this may not apply.

Alfonse Reinheart

11-18-2010, 01:41 AM

However, take this answer with caution as for very old 3D accelerators where only the rasterization was hardware accelerated this may not apply.

However, even for such hardware (which you probably shouldn't be coding for since they predate the GeForce 256. Not the GT 250, the very first GeForce), backface culling was a trivial calculation that was well worth the CPU cost due to the savings on the rasterization end.

In short, it doesn't matter if its hardware or not; it's worthwhile, so use it where appropriate.

However, even for such hardware (which you probably shouldn't be coding for since they predate the GeForce 256. Not the GT 250, the very first GeForce), backface culling was a trivial calculation that was well worth the CPU cost due to the savings on the rasterization end.

In short, it doesn't matter if its hardware or not; it's worthwhile, so use it where appropriate.

david_f_knight

11-18-2010, 03:33 AM

I was partly wrong, and ZbuffeR's answer was also a bit wrong.... The cross product is a vector. Vectors don't have a sign, they have a direction. What ZbuffeR needed to say was that the sign of the Z coordinate of the cross product tells you whether a triangle is back facing or front facing. That's the simplest, and fastest, way of determining whether a triangle is front facing or back facing (there's no need to calculate the X or Y coordinates of the cross product). (Incidentally, if the Z coordinate of the cross product is zero, then the triangle is viewed from the side and can be culled.)

The OpenGL specification provides one generalized method of determining how a planar polygon faces. (I'm not sure, but I think that formula works for concave polygons as well as for convex polygons.) The specification does not require any particular method be used to make that determination. If culling is performed before clipping, then the hardware will be dealing with a triangle, and can use ZbuffeR's technique. But, if triangle clipping is performed before culling, then the hardware may be dealing with a planar polygon with numerous sides. Even so, the planar polygon will be convex (no matter how you clip a planar convex polygon, the resulting polygon is planar convex). The formula the spec provides computes half the sum of the Z coordinates of all the polygon edge cross products.) That's unnecessary, however, because the polygon is known to be convex, and consequently the sign of the Z coordinate of the cross product of any two non-collinear consecutive polygon edges will reveal whether the entire polygon is back facing or front facing.

In any case, for triangles, back face culling can always be performed before clipping.

The OpenGL specification provides one generalized method of determining how a planar polygon faces. (I'm not sure, but I think that formula works for concave polygons as well as for convex polygons.) The specification does not require any particular method be used to make that determination. If culling is performed before clipping, then the hardware will be dealing with a triangle, and can use ZbuffeR's technique. But, if triangle clipping is performed before culling, then the hardware may be dealing with a planar polygon with numerous sides. Even so, the planar polygon will be convex (no matter how you clip a planar convex polygon, the resulting polygon is planar convex). The formula the spec provides computes half the sum of the Z coordinates of all the polygon edge cross products.) That's unnecessary, however, because the polygon is known to be convex, and consequently the sign of the Z coordinate of the cross product of any two non-collinear consecutive polygon edges will reveal whether the entire polygon is back facing or front facing.

In any case, for triangles, back face culling can always be performed before clipping.

Alfonse Reinheart

11-18-2010, 04:18 AM

I'm not sure, but I think that formula works for concave polygons as well as for convex polygons.

Aside: it does. The OpenGL spec requires convex polygons for other reasons. Namely, because it knows that hardware will simply turn them into triangles. Which you can do in any order with convex polys, but with concave ones, you have to use more complex algorithms. So it simply forbids it.

Aside: it does. The OpenGL spec requires convex polygons for other reasons. Namely, because it knows that hardware will simply turn them into triangles. Which you can do in any order with convex polys, but with concave ones, you have to use more complex algorithms. So it simply forbids it.

Powered by vBulletin® Version 4.2.5 Copyright © 2018 vBulletin Solutions Inc. All rights reserved.