«»
Visibility
One of the least intuitive problems in 3D rendering is hidden-face removal, and drawing objects correctly so you don’t end up with bizarre effects where parts of an object that are facing away from the viewer or hidden behind other parts are rendered. Hidden-face removal seems simple at first, but becomes trickier and needs more sophisticated algorithms as scenes get more complex.
At the basic level, if a scene being rendered involves convex shapes – ones with no inward depressions or parts that face each other – the object can be drawn correctly just by looking at the angle of the faces with respect to the viewer. If a face is more than 90 degrees away from the viewer, it’s facing away and isn’t visible, so there’s simply no need to render it: the object will come out with visible faces rendered and invisible ones not, as it should be. That approach doesn’t work when you have convex objects or objects in front of each other, though. If one object is in front of another relative to the viewer, some of the faces of the object farthest away will be obscured and shouldn’t be shown, even though they’re facing towards the viewer. By the same token, if part of a concave object is in front of another part, it isn’t possible to tell which parts are visible with the simple calculation.
Z-ordering and z-buffers
One way to solve the problem of convex objects and objects in front of each other is to use z-ordering and the painter’s algorithm. 3D mesh objects are defined in space using Cartesian co-ordinates. Each point in space is defined by an x, y, and z co-ordinate. The x co-ordinate is the horizontal, y is vertical and z is the depth. So we can solve the problem of the visibility of convex objects by pre-sorting the faces of a scene, then rendering them by starting with the farthest away. This is the painter’s algorithm. By rendering moving forward toward the viewer, faces at the front are painted over those behind and the problem of visibility is solved. But things become more complex still: if two polygons intersect, it can be impossible to decide the order in which they should be painted.
For complex scenes involving more than one model, the answer is to use a z-buffer. Z-buffering takes place on a per-pixel basis; as the image is being rendered, the system maintains a special frame buffer at the same resolution as the image size. But the frame contains only the z co-ordinate value of any pixel that’s already been rendered to the screen at that location. As the system renders each object and rasterises it – in other words, converts it to a discrete image of individual pixels – it checks the z-buffer. If a pixel has already been written in that location with a smaller z co-ordinate, the part of the scene the render was about to draw must be obscured, so it isn’t written to the screen.
Since z-buffering is a per-pixel scheme, it gives flawless results: the drawback is that it’s memory intensive and used to be slow. But modern graphics hardware has dedicated z-buffer memory and acceleration, meaning z-buffering is now the universal way of dealing with problems of visibility.
NURBS
The trouble with an object mesh is that it has limited resolution. Model a curved edge or circle with too few points and you’ll end up with obvious straight edges. The simple answer is to use more points, but more polygons mean more cumbersome 3D models that consume more memory. Creating every object from the wheelnuts to the wing mirrors of your car model using 10,000 polygons is a quick way to bring even the most powerful PC to its knees. On top of that, often there’s no need for high polygon resolution. If the wheel nuts are only going to occupy a few dozen pixels in the final render, the extra detail is pointless: the required polygon resolution for a model or part of a model depends on the final resolution of the 2D render.
For a modelling application, one solution to the problem of having to decide in advance how many polygons to use is not to use any. Instead, you can use a mathematical representation of a shape. The difference between a mesh-based model and a mathematically represented one is similar to the difference between a bitmap image – say, a JPEG – and a vector-based art file. Zooming into a JPEG, at some level of magnification you’ll see the individual pixels; zoom into a vector drawing and the edges are always smooth.
One of the most popular ways of representing models such as this is with the use of NURBS (non-uniform rational B-splines). NURBS allow for the creation of advanced and complex surfaces with no resolution limitations. The difficulty is they can’t be used to create completely arbitrary models. To solve that, NURBS modellers resort to combining shapes in the same way standard mesh primitives such as cylinders and cubes can be combined.
Copyright © 2008 Dennis Publishing
This article appeared in the February 2008 issue of PC Authority.
«»
Thoughts on this article? Add a comment below.
Be the first to comment on this article.