rude wrote:hdon wrote:It is true, however, that OpenGL face culling is enabled, which is useless for a game engine which only has 2D graphics.
My understanding is that it speeds up the program significantly, as the backface of a given quad does not have to be rendered. It doesn't matter that we just use one plane in the 3D space (z=0). The quads still have a backface.
That's not quite how it works. Quads do not have a "back face." Back-face culling is an optimization
only for rendering convex three dimensional geometries.
OpenGL's rendering model is called "rasterization." Typical of this type of rendering model is wasted rendering: lots of drawing overlaps previous drawings during the same frame. For instance you might draw the walls and floor of a room, and then draw the people inside
over top of those walls and floor. If you could efficiently know ahead of time what parts of the walls and floor will be covered up by the people, you would not draw them!
Many sophisticated rendering engines built on top of OpenGL, Direct3D, or other 3D rasterization APIs do have some power to make this sort of optimization, but the situations under which they can do this are quite specific, and the
people in a room example I just gave isn't one of them. The inverse scenario, however, of determining which people are just around the corner so that a wall is drawn over top of them -- is quite a common optimization, because it's less expensive.
Imagine you are drawing a card or a coin. If its two sides are perfect mirror images of each other (and if it is perfectly flat,) then all of the coordinates for one side of your coin/card are identical to the coordinates for its other side, and you don't need to send both sides to the rendering pipeline, because both sides
are each other. It's like you can sorta see through it such that you see a mirror image from its back side. Most models are not like this, though. Most models represent
solid 3D geometries. They are not
actually solid, they are just polygons approximating the
visible parts of a solid shape. For instance a cube can be approximated by six squares sharing all their edges with each other.
If you do not have back-face culling, and you draw those six squares, three of them will always be completely overlapped! What a waste of rendering power! You can imagine, then, that if we could tell our rendering engine which direction our six squares were facing, it could decide which ones to render and which ones to skip! Luckily there is such a technique, and it comes from a polygon description convention. If the clockwise/counter-clockwise order of your polygons are consistent throughout your entire model, then the vertices of your polygons provide all the information the rasterizer needs to know the exact direction your polygon is facing. Without the explicit cw/ccw distinction, the best you could do is narrow down which direction the polygon is facing to two possibilities, both facing the exact opposite direction, which is demonstrated below by deliberately using the wrong cw/ccw choice for most of the renderings.
Back-face culling is only useful because in a cube you know only three faces are visible at a time, and the other three are hidden. It has nothing to do with 2D graphics at all. (Maybe you could use it for "2.1D" models which would be like Paper Mario models with asymmetrical characteristics which would violate perfect mirror symmetry.)
(Yes, I did oversimplify cube rendering by assuming no perspective projection!)
