Indy3D V3.0 Graphics Evaluation Tool Documentation

Revision History

V3.0 6/29/98
- Added MCAD150 test with 150,000 polygon engine database
- Changed MCAD engine models to be single-sided polygons instead of both-sided
- Changed MCAD motion path to decrease the average size of polygons
- Removed LODs from MCAD engine database
- Changed Animation test to use immediate mode instead of display list mode
- Added new method of comparing reference images
- Fixed convergence method for polygons larger than 25 pixels
- Added documentation regarding SGI Anti-Aliasing
- Added demo mode

V2.2 1/20/98
- Added examples of image problems
- Added Unix related information
- Modified description of HD page/faults
- Modified description of OpenGL PFD
- Fixed description of Fixed, Fill and Polygon rate methodology
- Modified description of texture filtering modes

V2.0 12/9/97 original document released

Overview

The Indy3D benchmark evaluation tool is focused on three segments of the 3D graphics market, MCAD, Animation, and Simulation. We built this benchmark because we live in this market space and none of the existing benchmark tools provide the information we like to know. We hope typical users in each of the three areas can easily use these benchmark results to gauge their needs and find a board or system that fulfills them. The Indy3D graphics evaluation tool was constructed to aid end-users in evaluating OpenGL 3D performance issues using application-focused metrics (MCAD, animation and simulation markets), image quality stress tests and 3D primitive metrics. Indy3D was constructed out of the desire to have a single tool that provided simple comparative measurements while allowing the user to explore various rendering options and perform their own ad hoc tests. Indy3D produces four official results; two for the MCAD tests (MCAD40, MCAD150) and one each for the animation and simulation tests. Sense8 maintains a web site that allows users to compare their results with other platforms that have been verified by Sense8. By providing this verified information, we hope users will easily understand the value other 3D accelerator solutions provide for typical application problems.

Unique features of Indy3D:

• Designed for users with limited real-time 3D rendering background
• Single test result for each application test (MCAD, simulation, animation) generated within minutes
• Image Quality test reveals image details that are often overlooked or never understood
• Official measurements made on a single reference system to remove system dependencies
• Combination of multiple application and primitive measurements in a single benchmark
• Automatic generation of test images from test run to compare with reference images
• Results generated as HTML, includes reference AVIs/images

Other important features

• Results output to tab/comma delimited file for import into Excel or other analysis tools
• Export any test’s scene graph as VRML1 file
• Includes reference measurements from 5 vendors for quick comparison
• Sense8 application source code distributed on web site
• SGI, Sun, HP, DEC NT and Intel versions available
• Authenticates "official" benchmark geometry to avoid unofficial variations
• Batch execution of tests

Indy3D is not intended to replace existing benchmarks, instead, it fills a missing gap in the existing suite of OpenGL benchmarks. Sense8 is working with various standards organizations to turn Indy3D over to a standards body for future support and enhancement.

 Reference System

Sense8 recommends the use of a single reference system to measure results. By using a single reference platform (for PCs only) to gather results, it's possible to provide a clearer view of board performance by reducing system-level dependencies. The results posted on the offical Indy3D web page are collected on a single reference system or on a comparable system. The official Indy3D Benchmark Evaluation Tool reference system configuration is :

Compaq AP400
Pentium II, 400Mhz, 512k cache, 100Mhz front-side bus
WinNT 4.0, Service Pack 3
128Mb 100Mhz ECC, SDRAM

How to Use Indy3D

The method of using Indy3D depends on the goals you have in analyzing performance. If you are performing a casual review of your performance, then simply installing Indy3D and running it will give you a result. However, if you are trying to carefully measure your performance so that it can be best compared to other measurements, you need to establish a more controlled environment to perform your tests.

Setting up the environment

Before running Indy3D, you should do the following to prepare your system.

• Check to see if you have the latest version of Indy3D by going to http://www.sense8.com/indy3d/
• PC systems: To get the best 3D performance, you should make sure you are using the default hardware cursor and not one of the "fancy" software cursors. This can significantly impact performance when the cursor is over the rendering window leading to unexpected results.
• Make sure no other applications are running at the same time as Indy3D (specially a browser).
• Turn off any screen-saver programs or other "idle-controlled" applications (important if you are using batch mode since screen savers would typically trigger because of the lack of user input thereby corrupting the results).
• Make sure that you have enough system RAM to run Indy3D (about 128 Mb of RAM is typically required).
• You may want to remove your system from any network to ensure other users or processes don't access your system while you are running the benchmark (note: be careful doing this, if you simply disconnect the physical connection without turning off networking, you can cause low-level system routines to consume performance by constanting trying to connect and then resolving the error).
• Make sure you have about 10Mb free on your HD as Indy3D stores images from your test run for later comparison.
• Turn off "sync to video retrace" or similar feature in your video driver. This ensures that you get the fastest result possible with your hardware. If you don't do this, then results will be limited by quantitization and the maximum video refresh (60, 62, 75, etc.) of your hardware.
• We highly recommend downloading the latest video drivers from the board manufacturer as we have encountered various issues with shipping video drivers that may either produce incorrect results, degraded performance or have significant rendering problems.
• If you are not using a system that is equivalent with the reference system, you should be aware that system performance is very much a factor in these benchmarks and your results may not be comparable with the measurements posted on the Sense8 web page.
• You should set your screen resolution to greater than 1024x768 (1280x1024 recommended) and to 24-bit color mode. If your hardware does not support this, you will not get "official" Indy3D scores (though the tests will still run).

Running Indy3D

1. After preparing your system, running Indy3D is fairly straightforward. You have the choice of running Indy3D with either a 4Mb, 8Mb or 16Mb texture database. The official results are generated using the 4Mb database. If you are interested in exploring the consequence of larger texture databases, then Indy3D provides these for your use.
2. Starting up the official Indy3D graphics evaluation tool, you are presented with a rendering window and a dialog. Choose the "Test" menu and select from one of the test choices. You can pick any test and run them in any order.
   
   Note: Indy3D ships with both a GUI and a batch mode version. To run the batch mode version, select the appropriate shortcut or run the file "Indy3D_batch.bat". The batch file reads the "Officialbat.txt" file that contains the commands to execute.
   
3. Wait for the test to load, once loaded, you simply select the "Run Test" button on the dialog. Because the default is to use the official "Indy3D Settings" (note the checkmark besides the "Run Test" button), any changes you may have made to the rendering settings will be ignored and the official settings will be used. If you want to perform your own ad hoc measurements, simply remove the "Indy3D Settings" checkmark.
4. Once the test begins, in general the following occurs:
   1. The entire scene is converted to an optimized OpenGL display list using WorldToolKit's "prebuild" function. This converts the geometry to triangle strips, sorts state and generally produces the fastest possible rendering of the polygons. The process of conversion can be timely and depends on the number of polygons in the scene. A splash screen is displayed while this process is occurring. This process only occurs for the MCAD and Simulation tests, the Animation test remains in immediate mode.
   2. Sometimes the simulation is executed for several or more frames to ensure that the simulation is stable and not measuring initialization effects.
   3. The measurement process begins (as shown in the small progress bar in the upper right of the rendered window). The progress bar changes from green to yellow to red as the measurement proceeds.
   4. The measurement completes, various values are stored in data structures, and a JPG image is captured of the rendered scene and stored for later reference. Note: the final results are not output to a file until the Indy3D application exits.
5. To view the immediate results, use the "View, Results" menu command.
6. To view a reference image to compare what you are seeing versus the expected rendering, use the "View, Reference Image" menu command. You will see your captured image and your cursor now positions a small rectangle that can display small portions of the reference image to easily compare your image against the reference image.
7. Perform your various measurements, then exit Indy3D.
8. Look in the directory where you installed Indy3D and you will see a new directory has been created with a name like "Indy3d1209_1121" (Indy3d[date]_[time]). This directory contains the following:

• "results.htm", HTML output of results and general documentation
• JPG of each user test you ran
• possibly a "config.txt" (Unix platforms) that contains detailed hardware configuration information
• "results.txt", ASCII comma-delimited file to load results into Excel

If you have problems

• Read the "README.TXT" file for the latest issues with various board drivers and hardware or go to the Sense8 web page to download the latest information.
• Download the latest FAQ from the Sense8 web page.

Repeatability of results

Experiments at Sense8 have shown Indy3D to be better than 1% repeatable on a wide range of hardware platforms and with running the tests in various orders of execution. However, you may discover some sequence of tests that causes problems with your particular hardware/driver configuration. Please send email to support@indy3d.com if this occurs.

Official Indy3D results

The following table shows the settings that Indy3D considers "official" for all the user tests. These are also the settings used for the "Official" Indy3D results table at http://www.sense8.com/indy3d/. Unless these settings are used, you will not be measuring what we consider the official values and your results many not correlate to the published values. The default behavior is for Indy3D to measure these official values, unless you turn off the "Indy3D Settings" checkmark.

Notes:

1. System resolution needs to be set at greater than 1024x768 or the rendered window will be slightly clipped.
2. Systems that support "32-bit" color really have 24-bit RGB values and an 8-bit Alpha channel. This is equivalent to a 24-bit RGB setting.
3. The value of the Z-buffer will be determined by the hardware, sometimes this is 32 instead of 24. 32 has higher precision than 24. Indy3D does not force a particular Z-buffer size, it will use whatever the hardware provides, even if it is only 16 bits.
4. In OpenGL, we have no ability to determiine if the hardware is rendering a pixel (ICD drivers) or if the driver is using software emulation (MCD drivers). Because of this, we have no ability to force the hardware to render a scene with just hardware rendering. It is up to the graphics board manufacturers OpenGL driver to determine what to do when an unsupported request is made. The best way to uncover this is to run the Image Quality test and look at the performance relative to a software-only result. f there is little difference, then it is likely your graphics accelerator isn't doing much work and your CPU is doing all the work.

Unofficial Indy3D results

The unofficial results are those tests in which you customize the benchmark evaluation tool to match the requirements of a project or a system you wish to evaluate. This is a really useful capability for 3D graphics professionals who work on systems that depart from the reference system or want to better understand the impact of specific features on graphics performance. Sense8 also maintains an unofficial table of results that has some of these deviations from the official settings, also viewed at http://www.sense8.com/indy3d/.

 The Indy3D dialog menu is where you select the rendering attributes you want. As you select each attribute, you should see an immediate result in the rendered scene. Using the mouse, you can navigate each scene to explore the environment more closely. Make sure you deselect the "Indy3D Settings" check box or your settings will be ignored when you select "Run Test".

Note: the frame rates reported by the interactive frame rate indicator may be significantly smaller than measurements reported by the "run test" results because the "run test" process first creates an optimized display list for best rendering performance. After the "run test" process completes, the geometry will remain optimized until you change a rendering option. This will delete the display list and performance will no longer be optimized.

Interpreting the reports

The output of Indy3D presents important information about the state of the system when the test was run. This is critical to understanding why a measurement may not have been properly measured or to compare with other measurements. We have tried to include sufficient information that can make intelligent decisions about the validity of your results. Here are the definitions of everything reported.

System Information

This is reported once only at the beginning of each report.

Official Indy3D Test Information

This is reported for each official Indy3D test result (MCAD, animation and simulation).

Primitive Test Information

This is reported for each Indy3D primitive test result (fill, fixed rate and triangle rate).

Dialog settings

The Indy3D dialog allows you to set various parameters. This is a description of each of those parameters.

Methodology in general

All the user methodology tests represent an informed opinion about how the chosen markets use real-time 3D techniques for typical uses. Sense8 relied not only on its own experience in these markets but also derived this from long discussions with experts and 3D analysts who represent these markets. While Indy3D attempts to measure a broad "typical" use in order to keep the measurements fast, simple and understandable, you should also realize that no one tool will represent all uses.

MCAD benchmark

The MCAD benchmark test consists of two different tests (MCAD40 and MCAD150) designed to simulate the rendering of typical models of medium to high complexity (40,000 or 150,000 polygons). The MCAD150 test has enough polygons that it tends to give results highly dependent on the CPU or geometry transformation hardware and little else. The entire engine database is converted to an OpenGL display list prior to testing. Note: PTC and Microstation don't use display lists, but CDRS and SDRC do. This means there are some CAD applications that do not take advantage of display lists and therefore Indy3D may not be applicable in these cases. There is no way to test the engine database in immediate mode. You should also know that display lists vs immediate mode makes the greatest difference when the hardware has a display-list cache of significant size (like SGI IR or HP Fx series).

The MCAD visual database is an engine model supplied by Engineering Animation Incorporated (EAI). The engine was created with SDRC's IDEAS Master Series and was converted into a VRML 1.0 file using EAI’s VisMockup application.

MCAD40 Database notes:

• Contains 42,267 polygons, all polygons are single-sided
• Contains an assembly of lower level components (149 geometries)
• Average pixel size of rendered polygons is 30 pixels
• Average depth complexity of the entire scene is 0.52 pixel overwrites per frame
• Average polygons drawn per frame (non-culled polygons) is 42,120
• Database is converted to an OpenGL display list comprised of over 12,035 triangle strip sets (average size of 3 triangles)

MCAD150 Database notes:

• Contains 150,248 polygons, all polygons are single-sided
• Contains an assembly of lower level components (149 geometries)
• Average pixel size of rendered polygons is 9 pixels
• Average depth complexity of the entire scene is 0.52 pixel overwrites per frame
• Average polygons drawn per frame (non-culled polygons) is 149,786
• Database is converted to an OpenGL display list comprised of over 48,257 triangle strip sets (average size of 3 triangles)

Rendering settings:

Methodology

The MCAD benchmark test is run twice in succession. There is a five-frame stabilization segment at initiation of the test application followed by 125 frames of anti-aliased wireframe, which is immediately followed, by another 125 frames of the engine in smooth shaded polygon mode. The official result for MCAD is a weighted average of the frame rate of the two test runs. The anti-aliased wireframe test accounts for one third while the smooth shaded test accounts for two thirds of the result.

Animation

The Animation model is a human figure supplied by the Westwood Studios. We feel this type of character-based modeling is typical of the game and video animation markets. The cityscape around the figure was created by Sense8 to put the figure in a typical setting. The file supplied by Westwood Studios was in 3D Max format and was then processed by Sense8 to eliminate redundant polygons and stored in a compact Sense8 format. The animation database is not converted to an OpenGL display list, it remains in immediate mode which is the norm for all Animation tools.

Database notes:

• Contains 133,004 polygons for the entire scene (all 133K polygons are never rendered at once, a switch node selects about 24,000 polygons for consideration during any single frame)
• The human figure contains about 22,000 single-sided polygons as a single mesh
• The cityscape contains 2,381 single-sided polygons divided into 41 geometries
• There are no level-of-detail nodes
• There is a switch node, which cycles through the six geometries of the character (about 22,000 polygons each) to create movement.
• Texture database size is 2.72Mb comprised of a mix of resolution sizes
• Average pixel size of rendered polygons is 140 pixels
• Average depth complexity of the scene is 1.35 pixel overwrites per frame
• Average polygons drawn per frame (non-culled polygons) is 22,865 polygons

Rendering settings:

Methodology

The Animation benchmark test is 345 frames long. The first 100 frames are used for stabilization, the next 245 are used for taking measurements. The scene including the character averages 23,000 polygons. A single light illuminates the scene. The scene and character are heavily textured using bilinear texture filtering. A fog effect is used in the scene.

Simulation

We have selected a realistic sailing simulation built by Sense8. The sailboat is driven forwards by wind forces acting on the boat and by resistance of the boat to the water. The physics involved in this simulation are fairly simple and we have verified that on the reference system, the impact of running the physics simulation is not noticeable with any of the graphics boards we tested at the official settings. However, it is possible that for smaller windows or boards with extremely large texture fill capabilities (anything that can deliver 25-35 fps for the simulation), the impact of the physics model will be felt if the CPU can't keep up with the rendering and becomes the bottleneck. The justification for this is that in the simulation market, there is almost always some CPU utilization for running code other than 3D transformations/lightings.

In addition to the physics simulation, we are creating "waves" by moving the vertices of a mesh of polygons near the boat. We have verified that this makes a negligible contribution to performance under most expected environments.

Database notes:

• Contains 7,710 polygons in a mix of single and both-sided polygons
• Contains 61 geometries in a mix of single and both-sided polygons
• There are no level-of-detail nodes
• Texture database size is 3.64Mb comprised of a mix of resolution sizes
• Average pixel size of rendered polygons is 574 pixels
• Average depth complexity of the scene is 2.15 pixel overwrites per frame
• Average polygons drawn per frame (non-culled polygons) is 7257 polygons per frame
• The non-wave portion of the database is converted to an OpenGL display list comprised of over 75 triangle strip sets

Rendering settings:

Methodology

The Simulation benchmark test is 225 frames long. Measurement occurs over the entire 225 frames after prebuilding. A single light illuminates the scene. The scene and is heavily textured using trilinear texture filtering.

Image Quality test

This test is designed to identify specific rendering issues with various OpenGL implementations. There are ten special regions in the image (see below). Each region of the image is designed to reveal particular issues related to the processing of texels (the pixels that comprise a texture map) or polygons. There is no specific "performance" measurement for this test. It is very difficult to algorithmically calculate the quality of an image, so we have left it to a subjective analysis. The intent is for you to look at the image generated by your hardware and compare it to a reference image that we believe best represents what OpenGL should have created. In addition, every time you press the "Run Test" button, your viewpoint will "bounce" into the picture and then an image will be captured and stored on your hard drive for later comparison.

Note: Unless you are viewing the reference and captured images with a 24-bit color display device, you will see all sorts of invalid artifacts due to limited color space. Make sure your browser and display support true color before interpreting the results of this test.

Region 1: Mipmapping

Trilinear mipmapping		No mipmapping

Mipmapping is essentially the process of using multiple levels of texture resolutions to eliminate high frequency texel artifacts that cause scintillation in the image. Mipmapping is most clearly seen in textured polygons distant and oblique from the viewpoint. For our evaluation, we used a single polygon that has a yellow texture as the highest resolution texture (32x32). Each successive level of mipmap is created in a different color or pattern. The next level (16x16) is a black and white checkerboard pattern, the next (8x8) is a solid blue color and the final level (4x4) is a red and green checkerboard pattern. This is most clearly visible in the "point mipmapped" setting and completely disappears in the non-mipmap settings (point, bilinear). In order to clearly demonstrate this affect, we had to go to some lengths to create a polygon with the right dimensions and position which is why it appears where it does and looks the way it does.

Region 2: Color space

24-bit color depth		16-bit color depth
16-bit color depth with dithering

This is a single triangle with different vertex colors (red, green, blue) at each point of the triangle. This creates a color gradient across the face of the polygon. On a 24-bit color system, this gradient will appear smooth, on a 16-bit color system (or less), this will have obvious banding across the face because there aren't enough colors to produce a smooth gradient. Some hardware supports hardware accelerated dithering at color depths such as 16 or 15 bits. Dithering represents the process of using pixel patterns and combinations of pixels to fool the eye into perceiving color depth where it may not exist.

Region 3: Texture color space

The same process in region 2 is repeated except that a texture (256x256) is created with the color gradient. This tests whether the texel storage and processing handles large color spaces (in OpenGL, textures can be stored in a number of formats, but 32-bit and 16-bit are by far the most common). If the hardware is processing 32-bit textures, then the texture will appear smooth. If the hardware is using 16-bit (or less) texel storage, then the texture will appear banded - even if the display color depth is set to 24-bits. These are independent (though related) issues.

Region 4: Texel processing

This region gives a close up look at how texels are processed and displayed. This is a low-resolution (8x8) texture with red/green/blue/black/white pixels in it. Because the texture is so low resolution, it means that the size of the processed texel is very large in screen space. Each one of those colored squares or fuzzy dots represents a single texel from the source texture. In point-sampled mode, the texture appears as a multi-colored checkerboard with distinct squares. Once you turn on one of the texture filtering processes (bilinear, bilinear mipmap or trilinear), you should see the edges of the texels become fuzzy as the hardware averages the surrounding texels into computing the screen pixel value. Various hardware artifacts are exposed if you look closely at the texels. In general, the smoother the gradients represented in the texel processing, the better the hardware is at processing textures. Some hardware uses dithering techniqes to create a perception of smoothness when the image is viewed from a sufficient distance.

Region 5: Translucency and depth sorting

This region can expose a couple of issues. One issue is how well the hardware processes translucent polygons. In this test case, each polygon is partially opaque and spaced closely together. The order of the polygons should be preserved by the hardware (red, green, blue, front to back as shown in the left picture). An additional aspect of this test is that it exposes the use of other than a 24-bit Z-buffer for depth sorting. The three polygons have been spaced close enough together that various 24-bit Z-buffer hardware solutions should have no trouble correctly ordering the polygons. However, any system without a 24-bit Z-buffer, or that has other hardware issues would show obvious ordering problems or a fragmenting of the surface of the front-most polygon (as shown in the right picture). The hither/yon values are set to 1 and 8,000 units based on the size of the 3D model.

Region 6: Anti-aliasing and polygon edges

This region consists of many independent black and white triangles (two per square) arranged in a checkerboard pattern. By contrasting the black and white edges, we provide a worst-case aliased image. If the rendering hardware supports anti-aliasing, it should be very clear as these edges will appear sharp and well defined rather than showing a "staircase" or "jaggies" effect. Most hardware does not support accelerated anti-aliasing at this point in time. Indy3D automatically detects whether or not anti-aliasing is supported by the hardware. In addition to anti-aliasing, we are looking for any precision issues with how the edges of polygons are drawn. If there is a problem, it would show up as "seaming" between the black and white edges of the polygons. Some of the pink background would show through.

Region 7: Depth sorting

This region provides an additional test of depth sorting like region 5. In this case, the polygons are not translucent and they are laid flat instead of standing up. Sometimes this helps reveal problems when the other test does not. Again, this is designed so that hardware with proper 24-bit Z-buffers do not show any problems (left picture), while 16-bit Z-buffers will show a problem (right picture).

Region 8: Perspective distortion and texture filtering

Perspective correct texturing		Incorrect perspective distortion

This region exposes many potential issues. A 512x512 texture of closely spaced lines recedes off into the distance (picture on left). This will immediately expose any non-linearity's in the processing of a texture for proper perspective distortion. All the lines in the texture should recede into the distance without and curves or waves. The picture on the right shows what happens when the texture is not properly processed for perspective distortion, the lines no longer project into the distance.

Additionaly, as the texture recedes into the distance, the spacing of the lines becomes closer and closer. This causes all sorts of image artifacts due to the high-frequency nature of the texture (closely spaced black and white lines). This problem appears worst case with point-sampling mode and gets progressively better as the different texture modes are changed. This problem is most apparent when the "Test Run" button is pressed and movement occurs in the image.

Region 9: Translucent texture

In the simulation business, it is very common to use alpha-channel textures for objects like natural looking trees, bushes, and windows. In this case, the alpha-channel contains information about the amount of transparency or translucency each pixel in the image should have. In this case, the trees alpha channel values are either one or zero. If the hardware weren't working properly, either the pink background wouldn't show through (as is the case in the right image) or there would be various fringing artifacts around the edges of the tree texture.

Region 10: Text and texture filtering

This test is really to help communicate what will happen to text when it is filtered in the various modes. A 256x256 texture with some text on it is placed at various distances from the viewpoint. As various filtering modes are applied, you can determine the impact on the legibility of the text. Text without texture filtering (point-sampling) has sharper edges than filtered images. This may or may not be a desired effect for the texture in question.

Region 11: Pixel vs vertex fog

Where is region 11? No, this isn't an oversight. It is just difficult to show this region on the image. The image test is also designed to show the impact of pixel-level fog versus vertex-level fog. Some hardware implements fog support by changes that only occur at polygon vertex points instead of the more computationally intensive process modifying each screen pixel. We have tried to reveal this by having the left side of the scene be composed of as few polygons as possible (few vertex points) and the right side being composed of many vertex points. This imbalance between the left side and the right side should cause obvious non-linearity's in the computation of fog values if vertex processing is used (right picture). If pixel processing is used, then smooth gradients should be apparent (left picture).

Primitive Tests

The purpose of the three primitive tests is to help you understand lower-level issues related to real-time 3D rendering. In general, most real-time 3D systems are either limited by the rate at which they can push pixels to the screen (fill rate) or they are limited by the rate at which the system (board/CPU) can transform/light the polygons (triangle rate). These two primary issues interrelate making the picture fairly complex. These tests help you gain insight into these fundamental issues and may explain why your system is achieving a particular score for the user tests.

Hardware manufacturers like to publish primitive measurements gathered with various tools that are optimized for achieving the highest number. In general, this kind of benchmarking rarely represents typical use. Our primitive tests are geared more towards "application" polygons so don't expect the manufacturers numbers to necessarily agree with our results.

Fill Rate

The fill rate test measures the speed or bandwidth of the graphics hardware to draw pixels. This is measured in millions of pixels per second. To achieve high frame-rates when rendering high-resolution images requires significant bandwidth. Rendering a single polygon that fills a 1024 x 768 window at 10 Hz requires 7.8 Mpixels per second bandwidth. Typical databases require two to four times this amount. This test measures the pixel fill rate by introducing a stack of polygons (with vertex normals and vertex colors) drawn back to front (the most difficult condition) that are viewed orthographically. This test automatically introduces additional polygons until the frame rate drops below 10 hz. Once the frame-rate is below 10, the test measures 30 frames and calculates the current fill rate. Along with the various rendering options, you can measure a wide range of fill values.

Fixed Rate

The fixed rate test is targeted for the simulation community and measures the number of polygons rendered at 20 Hz. This is an important measurement as it drives the acceptable size and design of the visual database used for a simulation. This is measured by introducing sets of triangles (vertex normals, but no vertex colors) until the desired frame rate of 20 +/- 0.5 Hz is achieved. Once this frame rate is achieved, it must be sustained for 5 seconds. The view is drawn orthographically. Additional sets of polygons are added by stacking them on top of each other (rendering performed in back to front order), but offset by 10 units (to avoid coplanar polygons).

NOTE: Indy3D Version2.0 rendered polygons front-to-back instead of back-to-front. This was changed in Indy3D Version2.2. Some hardware is optimized to take advantage of the rendering order and this may cause results to change with Indy V2.2.

Polygon Rate

The polygon rate test measures triangles per second and stresses the underlying transform, lighting, and setup calculations of the system and graphics board. For databases composed of tens of thousands of polygons, this typically becomes the limiting factor in achieving better performance. In addition to graphics board issues, the underlying CPU and system performance significantly influences this measurement. The measurement occurs by introducing sets of triangles (vertex normals, but no vertex colors) until the frame rate drops below 10 Hz. Once this frame rate is achieved, the measurement is performed over 30 frames. The view is be drawn orthographically. Additional sets of polygons are added by stacking them on top of each other (rendering performed in back to front order), but offset by 10 units (to avoid coplanar polygons).

NOTE: Indy3D Version2.0 rendered polygons front-to-back instead of back-to-front. This was changed in Indy3D Version2.2. Some hardware is optimized to take advantage of the rendering order and this may cause results to change with Indy V2.2.