Inno3D Home Page Inno3D Home Page

FAQ News Search Archive Forum Articles Tweaks Technology Files Prices SETI
Visit NVIDIA's home page.
Favorite Pics
Click to Enlarge
OCZ Tech Titan 3
1.0GHz Pentium III
eVGA MX Shootout
nForce Preview
VisionTek GeForce3
2001 Spring Lineup
GeForce3 Preview
eVGA TwinView Plus
VisionTek GF2 Ultra
OCZ GeForce2 Pro
Winfast GeForce2 MX
GeForce2 vs Quake3
Linksys Cable Router
GF2 FSAA Shootout
GeForce2 MX Preview
Benchmarking Guide
Quake 3 Tune-Up
Power DVD Review
Live! Experiences
Memory from

FastCounter by bCentral

 Visitors Are Online
Powered by
3D Chipset
Gamers Ammo
Reactor Critical
GeForce FAQ
Dayton's Misc.
G-Force X Sweden
Maximum Reboot
Media Xplosion
nV Italia
Riva Station
nV News Home Page

Pentium 3 1GHz Review
By: Mike Chambers - March 23, 2001


It wasn't too long ago, September of last year to be exact, that I purchased a barebones system from GamePC. I went with an Intel Coppermine processor after reading about the successful overclocking stories of the 700MHz model. After successfully reaching 840MHz, which was still a far cry from the 933MHz others has achieved, I ran into problems when I installed an early GeForce3 reference card earlier this year. With the GeForce3, the system refused to run with any setting faster than a 105MHz front side bus (FSB) speed which knocked down the CPU to 735MHz.

With the arrival of the Pentium 4, it's no secret the Intel will be phasing out the Coppermine. Unless you insist on being part of the bleeding edge of technology, the end of a product life-cycle can turn into a great time to upgrade. Prices are dirt cheap and in my case, a CPU swap was all I needed as the Asus CUSL2 gladly accepted the GHz processor. Next to changing the CPU multiplier in the BIOS, the hardest part of the upgrade was putting the Thermaltake Golden Orb back on. Within 15 minutes, I was up and running.

Double Eagle Tanker - Piping Model

During the course of rendering these objects, a determination can be made if an object, or part of an object, is obstructed from view by other objects. Without such a determination, a pixel ends up being rendered multiple times per frame resulting in excess reads from and writes to the color and depth buffers. The number of times a pixel is rendered per frame determines the scenes depth complexity. As depth complexity increases, so do processing time and memory usage.

While the GeForce3 utilizes a Z-occlusion culling technology, there are a couple of other visibility detection techniques:

  • View Frustum Culling - removes objects that are outside the camera viewport.

  • Backface Culling - removes objects that are facing away from the camera viewport.

The idea behind occlusion culling using the Z-buffer is to test whether on object is located closer to the camera (player viewport) than the current depth buffer value. If the test fails, the current object is not visible. Otherwise, the depth buffer value is updated, and the object is drawn into the frame buffer.

Using the object database as an example, in order to determine if an object is occluded by other objects in a scene, the database could be sorted and rendered from front to back. In addition, the database can be sorted hierarchically in an order that the outer objects are rendered first and the inner objects are rendered last. This type of occlusion detection algorithm relies on the techniques found in Binary Space Partitioning.

As previously discussed, traditional graphics architectures render every pixel of every triangle as it receives them, accessing the frame buffer with each pixel to determine the appropriate values for the color and z (or depth) for each of those pixels. This method produces correct results, but requires all of the pixels to be rendered, regardless of their visibility or not.

For example, a rendered image of a wall has a depth complexity of one. An image of a person standing in front of a wall has a depth complexity of two. An image of a dog behind the person but in front of the wall has a depth complexity of three, and so on.

The Test

In an interesting turn of events, I happened to run across a variety of 3D models of the Double Eagle Tanker at The Walkthru Project. The massive double hulled tankers were designed and manufactured where I currently work as an IT Analyst. However due to excessive cost overruns only five of the ships were delivered before the project was adandoned.

Double Eagle Tanker

Double Eagle Tanker - Whole Model

Some of the Double Eagle models used by the project consist of as many as 82 million triangles. It is highly tessellated, and contains many artifacts from its original CSG representaton. Its size taxes the limits of our current computing resources in terms of memory, CPU, disk I/O, and grahpics hardware.

  • Memory bandwidth efficiencies - same memory clock speed as the GeForce2 Ultra

  • High quality antialiasing - Quincunx antialiasing versus supersampling

  • Embrace DirectX 8 features - Programmable graphics processing unit

In the following pages, you will see each of these accomplishments backed up with benchmarks and screenshots. This preview will be updated with additional tests during the next few weeks. While I concentrated on the areas where the GeForce3 excels, there are cases where it's not faster than the GeForce2 Ultra. Early reviews have already point that out such as AnandTech's.

One final note which may be cause for concern to overclockers. I could only run the GeForce3 at a 105MHz front side bus speed on the Intel 815E chipset based Asus CUSL2 motherboard. With the GeForce2 Ultra, I've been running at 120MHz. However, this is more than likely due to the very early revision of the reference GeForce3 board that NVIDIA provided us with.

Note that all benchmark results that appear in this preview are based on both the GeForce2 Ulta and GeForce3 cards running on a 105MHz front side bus. Here's a rundown of the system that was used in testing. - Black Book

Quake 3 Arena

Version 1.17 of Quake 3 Arena and Demo001 are used to begin the performance tests. The initial results are based on the standard high quality settings which include 32-bit color and 32-bit textures. The remaining settings are as follows:

  • Medium Geometry Detail
  • Default Texture Setting
  • Texture Compression Disabled
  • Trilinear Texture Filtering

Each set of benchmark result is based on enabling a graphics feature in Quake 3 that improves image quality. This allows us to determine the affect the particular setting has on the performance of each card.

Demo001 - High Quality Settings with no Sound

Texture Compression

Our first graphics tweak deals with texture compression. The Detonator drivers support S3TC texture compression which decreases the amount of texture data being sent across the graphics sub-system and results in increased performance. By encoding texture data and using a lookup table, texture compression can represent a texture map with fewer bytes of data.

However, there are some drawbacks with texture compression and image quality in Quake 3. There are instances when the compression scheme doesn't translate optimally as can be seen with the following screenshots from the sky in Quake 3. With texture compression enabled, the effects of color banding are apparent as the transition between colors isn't as smooth as the screenshot with compression disabled.

Texture Compression Enabled Texture Compression Disabled
Texture Compression Enabled - Click to Enlarge Texture Compression Disabled - Click to Enlarge

Earlier versions of Quake 3, enabled texture compression by default. The console variable to manipulate texture compression is r_ext_compress_textures. A value of 1 enables texture compression while 0 disables texture compression.

Demo001 - Texture Compression Disabled

High Quality Textures

The next settings we look at are maximum texture detail and high geometry. Increasing the texture detail provides immediate benefits to the graphics quality in Quake 3 as objects become visibly clearer.

Default Texture Detail Maximum Texture Detail
Default Texture Detail - Click to Enlarge Maximum Texture Detail - Click to Enlarge

Using high resolution textures causes a significant increase in the use of graphics memory. As a result graphics cards outfitted with 64MB of memory will perform much better than those with 32MB of memory when using a 32-bit maximum texture detail setting.

Demo001 - Maximum Texture Detail and High Geometry

Anisotropic Filtering

Note that I had planned on including results based on anisotropic filtering but I could not get it to work on the GeForce3. This section will be kept here and updated when a solution is found.

A setting that cannot be enabled directly via Quake 3, but provides the best texture filtering method is anisotropic filtering. Enabling anisotropic filtering, GL_EXT_texture_filter_anisotropic, is done under the OpenGL settings in the Detonator drivers.

Trilinear Filtering Anisotropic Filtering
Trilinear Filtering - Click to Enlarge Anisotropic Filtering - Click to Enlarge

In a very rudimentary explanation, anisotropic filtering is a mipmap filtering mode that compensates for anisotropic distortion. Anisotropy is the distortion visible in the texels of a polygon whose surface is oriented at an angle with respect to the screen plane. Unlike bilinear or trilinear filtering, anisotropic filtering measures the anisotropy and takes it into account.

When comparing the above images, you see that anisotropic filtering offers much better image quality than trilinear filtering. The textures on the walkway following the second step are much more refined and the clarity extends well past the large shadow.

Maximum Geometry

Our final enhancement is increasing the smoothness of curved surfaces via the r_subdivisions variable. Decreasing the value from the default of 4 to -1, results in the use of a greater number of polygons to render curves.

High Geometry Maximum Geometry
High Geometry - Click to Enlarge Maximum Geometry - Click to Enlarge

In addition, the r_lodbias setting was changed from 0 to -2, which produces more rounded images in character models and objects. The r_lodcurveerror variable was also changed from 250 to 10000, which determines the distance at which curves will appear smooth. Taking a look at the above images reveals that the edges of the yellow armor and the arc above the armor are much smoother.

Demo001 - Maximum Geometry

Next Page: Antialiasing Under OpenGL

Skip To:

Last Updated on April 24, 2001

All trademarks used are properties of their respective owners.