| |
|
|
||||
![]() |
||||||
| |
|
|||||
|
Science Imitates Nature at GDC This year's Game Developers Conference will be remembered for a variety of nature-related reasons: the weather was not as good as what we have been used to in previous years and, with the rain, trees and grass growing all over the conference and the exhibition floors: every company and team was, in one form or another, doing nature stuff. The latest generation of 3D cards, coupled with new methods and algorithms, have made nature rendering feasible on consumer platforms, with sometimes strikingly good results. Oceans and water One of the first phenomena that graphics programmers tried to simulate well was realistic water. At last year's GDC some teams were already doing very interesting approaches, so this years' methods are really nothing but a refinement of those early attempts. After seeing some demos at the expo floor, water rendering can be considered a solved problem, as the degree of realism achieved with some methods is absolutely stunning. The most popular approach to handle water basically requires combining two technologies: first, you must apply cube mapping to calculate a cubic environment map of the surrounding scene, which will encode the reflection information. Then, some kind of pixel and vertex shader trickery is used to realistically add waves (via bump mapping) and apply color to the water's surface according to the cube map. As the bump map can be animated, the results look very realistic. The main noticeable advancement from last year's methods is the use of the increased GPU and CPU power to render the complete scene to cube maps, so the reflections will not only look good, but physically accurate. In comparison, last year most teams were basically using a pre-calculated reflection map which did not really have to do anything with the scene data.
In my opinion, the main advancement at this year's GDC (graphics-wise) has been grass rendering. Its density and complexity had never been really tamed by the real time graphics community. Quite probably methods still have some way to go, but we have already seen very realistic results from a variety of teams. Essentially, two approaches have been devised. First, there are teams that are handling grass via vertex and pixel shaders, doing displacement maps that are wholly computed on the GPU. This has the advantage of a very low impact on your geometry pipeline, as the grass is not really made out of geometry. Different grass types can be generated by encoding the color in an additional texture map, so you can do the classical striped pattern found in a football stadium, for example. On the other hand, modelling high-quality blades of grass (or even tall grass) with this method is tricky, as the grass is basically limited to lines. Finally, animating this kind of grass is still an open issue which must be dealt with. Still, this method yields excellent results for games such as golf or football simulators, where it can be implemented with very low impact on your pipeline and definitely increase the visual appeal. Some great demos of this technique were shown in Xbox talks, as this game console is especially well suited for shader management thanks to its Nvidia chipset.
This second method of doing grass has, again, its ups and downs. On one hand, using textures for your grass allows much better-looking results, as you can mimic different types of grass, or even add some flowers. Tall grass can be handled very well, which in the end helps integrate the terrain and the elements on top of it. In the past, a good shadow rendering method was required to ease the integration between an object and the supporting terrain. This was not always possible, as triangle counts made shadow rendering sometimes too expensive. By using tall grass, objects are seamlessly blended into their surroundings. On the other hand, this grass approach may be too expensive in computational terms for some games: the triangle counts required to render these scenes may be way too high if you need to apply additional geometry (characters, houses, etc.) on top of that. Quoting Aristotle, the middle way is usually the best. So, combining a base of shader-rendered grass with some high-quality blades sounds like a good move for the future: in the end, no grass field is made of a single type of grass anyway. Trees At this year's GDC we finally discovered that gone are the days of billboarded trees. Some very good ways of doing forests have been discovered and, judging by the results, technology is finally advancing in the right direction. Again, tree rendering can be a real problem if you consider the inherent complexity of a real tree. It is getting hard to do a realistic tree below 10,000 triangles, and you would need quite a few of those to create a forest scene. A first approach (glimpsed at last year's conference) is to use layers of animated billboards. The key idea is to get very-high quality pictures of trees, branches and leaves, and then arrange them in Z-order so that, animating them, it looks like a complete, waving tree. This method requires very low triangle counts, and the results can be absolutely stunning. The downside is, as usual with billboard approaches, that the user will see the same tree regardless of the direction he's looking from. This can somehow be reduced by using some parallax trickery, but in the end billboards tend to look pretty bad when you need walk around them or, even worse, stay in the shadow of the tree. A second interesting method was explained at one of the Xbox conferences. It basically combines alpha-blended LODs with some good old volume rendering concepts. The key idea is to have a very high quality tree model in memory (the demo used a 30,000 triangle tree) and then pre-compute slices of the tree, which are stored in texture maps. These slices resemble a CAT scan, and have to be axis-aligned. In the demo, 24 slices (8 in each axis) were computed at 256x256, 32 bit. Then a mipmapped version at 128x128 was also calculated for distant versions. Then, at rendering time the model is only used in closer trees, so an average of 2-3 real trees are drawn. The remaining trees are rendered by drawing the stacked texture images pre-computed before, so a mid resolution tree requires only 24 quads. If the LOD threshold is set properly, the transition is unnoticeable, and the results are really convincing. Still, some interesting issues arise. First, it remains to be seen how animation can be incorporated into this model. Remember the sliced maps are pre-computed, and with a high-density model you simply cannot afford to re-calculate them per frame to accommodate animation. Second, this method delivers great results at the cost of high memory footprint. Even if we forget about the 30,000-triangle tree model, some fast math yields that a single tree would take up approximately 6 Mb of uncompressed texture data. Luckily, the scans have large transparent areas, making them ideal for on-the-fly compression. The Future After long years of trying, 2002 will definitely be remembered as the year nature made it to real-time consumer graphics. Still, success came at a high price as most of the methods currently in use impose very strict restrictions to work out their magic. The future will bring us animated trees, flowing water, and self-shadowing grass fields. Clearly, nature has an incredibly high degree of complexity and detail, so there is lots of room for research and experimentation. The next couple of years are looking very promising in the consumer 3D graphics scene. |
|
|