sponsors gamedev.net search:

High Speed Brute Force Computer capacity has increased greatly over the last couple of years. 3D accelerators can process huge numbers of polygons per second. Because of this brute force has been gaining on CLOD algorithms. It cannot produce the same quality as CLOD but it has gained enough speed to present a realistic alternative to CLOD. There are still many situations in which brute force is not a real option, but in some cases brute force might actually be good to use. At the moment 3D graphics power is still advancing faster than CPU power. As long as this trend is continuing, BF is gaining on CLOD because CLOD relies more on CPU capacity than 3D hardware power. After all, CLOD was invented to bybass the problem of relatively slow 3D graphics processors. Example of the Raid3D brute force engine running at 138 fps at a resolution of 800x600x32. Wireframe render of Raid3D's brute force. Quite a lot of polygons but still fast because there's very little CPU overhead. Brute Force applications Below, i present some situations in which BF could do the trick and situations in which it really isn't a good idea. Clipping horizon: Brute force cannot handle very far clipping distances. The number of triangles it has to process increases very rapidly in comparison to CLOD. Say for example you want to extend the horizon by the size of a patch. This means drawing, for example, 8 extra patches of terrain on the screen. For brute force, with 256 triangles per patch, this would add 2048 extra triangles. For CLOD this would be only 64 extra triangles. I tried to double the horizon in my Raid3D engine from 100f to 200f (with a detail of 4f). The framerate dropped from 130 fps at 100f to about 50 fps at 200f. 50 fps is not bad at all but a major decrease from the 130 it was running at before. From this perspective, good candidates for brute force would be strategy games. Near the horizon the player units get very small so you don't need to have a really distant horizon. Flightsims on the other hand do need to have a distant horizon and are therefore ill suited for brute force. The loss in speed can be compromised by decreasing the detail of course but that would indicate significant quality loss, which you obviously don't want. Detail: The same story as above can be applied to detail. Doubling the detail is pretty much the same as doubling the clipping horizon as far as triangle counting goes. Brute force is therefore best suited to applications that do not require much detail. Generally this means applications where the camera is further away from the terrain. This makes brute force a poor candidate for outdoor first person shooters where you want lots of detail, but still suitable for strategy and god games. 3D hardware: Brute force needs a relatively fast 3D accelerator to function properly. It has to be fast enough draw the extra triangles you get with brute force in the time CLOD uses to calculate the perfect triangle set. I tested with a nVidia TNT2 32Mb. In my testing comparisons CLOD was slightly faster so TNT2 would be the absolute minimum card you could use brute force on. I haven't had the opportunaty to test with higher end cards like GeForce 4 but brute force should do better on those. Frustum culling: Finally brute force requires accurate frustum culling. With CLOD this is of less importance since the patches that get rendered near the clipping edge are usually made up of 4 or 8 triangles. With brute force this can be as much as 256. Therefor CLOD benefits the most from high speed culling, sacrificing some accuracy. Brute force really needs high accuracy to cull away as many patches as possible. In Raid3D I use a quadtree and accurate math to do this. GeoMipMaps Of course I'm not the first person to think of this. One solution I found on the internet is called GeoMipMapping, which was developed by Willem de Boer for the e-mersion project. It's much like ordinary texture mipmapping. Terrain patches are precompiled with different levels of detail. At rendering time the detail level rendered is based on the distance from the camera. It's a great idea but ill suited for my Raid3D demo. Using four GeoMipMap detail levels means precompiling the entire map four times, which uses a lot of precious memory. This is no problem with medium scale maps, but I wanted Raid3D to use huge maps. The very early beta on this site uses a 4 sq. kilometer map, which is rather small to medium sized in comparison to what I desire in the final release. Putting Brute Force to the Test

Contents   Introduction   High Speed Brute Force   Putting Brute Force to the Test   Printable version   Discuss this article