OpenGL Peformance Tuning Information Page

See Also: WCS OpenGL Benchmarks
World Construction Set 5 uses OpenGL extensively for all realtime interactive views, whereas WCS V4 used simple 2D raster graphics for planimetric (Map) Views and simple 3D wireframe graphics or OpenGL solid polygons for Camera Views.

WCS 5 also allows the user to have more than just a single Camera View open, allowing any number of OpenGL-based views at a time.

This results in much heavier use of OpenGL, and may result in undesirably slow interactive performance. It's not so much that OpenGL or WCS has gotten slower in V5, it's a simple matter that WCS V5 allows you to do so much more with OpenGL at once, and this will often be slower than doing the very little OpenGL work that V4 did.

As OpenGL performance is actually increasing faster than system/CPU performance, we strongly believe that offloading realtime 3D operations to OpenGL is the right decision. For most users, a comparatively inexpensive graphics card upgrade can contribute to greatly increased performance, even in older systems. We understand that not all users will be able to upgrade their systems to increased OpenGL performance. In light of that, the following tips are offered as suggestions for trading off some of WCS V5's increased OpenGL capability and complexity for improved interaction performance. We highly recommend you perform a WCS OpenGL Benchmark Test before experimenting with OpenGL tuning. Save or print out the file of baseline results so you can refer to them as you adjust settings. As you try each suggestion, re-run the benchmark to get a quantitative measurement of how that suggestion affected real OpenGL redraw rate.

If you discover any card/driver tuning options or other performance tips you don't see here, please email them to us so we can share them with the world.

Card/Driver Tuning:

1. Check hardware or software mode:

   Check the "OpenGL Card Vendor" and "OpenGL Renderer" fields in the benchmark report. Under Windows, if the card itself is not using its own hardware acceleration, these fields will often display the name of the built-in Microsoft software OpenGL renderer:
   

   
   OpenGL Card Vendor: Microsoft Corporation
   
   OpenGL Renderer: GDI Generic
   
   

   Seeing this is a good sign that if your card has OpenGL hardware acceleration, it may not be enabled for some reason. Or, it may be a sign that your card does not have any OpenGL acceleration at all. Here are the results from some accelerated cards:
   

   
   OpenGL Card Vendor: NVIDIA Corporation
   
   OpenGL Renderer: GeForce2 GTS/AGP/3DNOW!
   
   
   
   OpenGL Card Vendor: Matrox Graphics Inc.
   
   OpenGL Renderer: Matrox G400
   
   
   
   OpenGL Card Vendor: ATI Technologies Inc.
   
   OpenGL Renderer: RAGE 128 M3 A13 AGP 2x x86/SSE
   
   

   Mac systems may display different IDs for accelerated and unaccelerated cards.

   If you believe your card has hardware acceleration, but it does not seem to be operating, check the Settings, Resolution and Display Depth below.

2. Check Card Settings:

   Refer to the documentation for your card to determine if there are any options or settings that are known to inhibit OpenGL acceleration.
   • Some multi-monitor cards are not accelerated when running both monitors.
   • Some multi-monitor cards can be accelerated when two monitors are hooked up, but only one display will benefit from the acceleration.
   • Some multi-monitor cards can accelerate both displays, but only when running at a particular display depth. (See Display Depth, below)
   • Some cards may have game-specific settings that could inhibit OpenGL acceleration.
   • Some cards may have video-playback or video-output related options that would inhibit OpenGL acceleration.
   • Some cards may have a button or checkbox to enable 3D or OpenGL acceleration. Make sure it's on, obviously.

3. Check Card Resolution:

   Almost all cards will perform differently at different display resolutions. This is why our standard benchmark procedures recommend setting your display size to 1024x768, to level the playing field. However, some cards will only have acceleration available at certain resolutions. Check your card documentation to see if there are any known limitations, and experiment with different common display resolutions to see if there are any that make a substantial difference.

   It is not uncommon for lower-end cards to only support acceleration in, say, 1024x768 resolution, with either 16 or 24 bit color, and refresh rate of 70Hz or lower. Some higher-end cards may not support acceleration in low-res display modes (below 1024x768). Strangely, a few cards actually get faster at higher resolutions and refresh rates. Resolution is often closely associated with Display Depth, below.

4. Check Display Depth:

   Many cards will perform differently at different display depths (16-bit, 24-bit, 32-bit). Often, lower bit depths will mean less data for the card to move around, and thus faster performance, but some cards will only have acceleration available at a certain display depth. Lower-end cards may only be accelerated in 16-bit or 24-bit modes, and not 32-bit. Higher-end cards may not be accelerated when running 16-bit modes, or even 24-bit modes.

5. Check Refresh Rate:

   An incorrectly set refresh rate is not likely to inhibit OpenGL acceleration, but it still can affect performance. Higher refresh rates (70Hz, 72Hz, 75Hz, 80Hz, 85Hz) can often stress or saturate the memory bus on lower-end cards, leaving little bandwidth left over to move data from the CPU to the display card, lowering OpenGL drawing performance. Experiment with lower refresh rates to see if they measurably improve drawing performance. If they do, you need to decide if the performance benefit is worth the trade-off of lower display stability and increased eyestrain.

   Occasionally a high-performance card may have memory access synchonized with RAMDAC clockspeed, and you will find that higher refresh rates may actually improve drawing performance, to a point. As always, experimentation will be the only way to determine your system's performance characteristics and best settings. If you find a trick to produce ground-shaking improvements with your card, please share it!

WCS Tuning:

Note: It is best to explore Card and Driver Tuning first. Card and Driver tuning can improve performance without noticably affecting what you can and can't see/do in WCS. The following tips suggest ways of limiting WCS in exchange for improved performance.

1. Check Maximum Polygons:

   The first and foremost way to limit the amount of work WCS requires of OpenGL is the Max Polygons control in the View Preferences window. Higher numbers will give you better terrain detail in your realtime Views, but will be more work for OpenGL and will be slower. The default setting is 6000. Fast cards and systems can go quite high, 50000, 200000, even 1000000 polygons are possible. Very slow systems might need to reduce this number. It can go as low as 1000. This setting is the replacement for the Grid Size setting in WCS V4.

   Note: This setting is the maximum number of polygons of terrain only. Cameras, Targets, Vectors, Lakes, Grids, Clouds and especially 3D Objects are not accounted for in this total, nor are they limited by this setting. Therefore all of these things can still slow down your display quite a bit, and all will be discussed below.

   Note: This setting is the maximum number of polygons per View window. If this control is set to 6000, and you have one View open, OpenGL will have to draw 6000 polygons worth of terrain each time it refreshes. However, if you have three views open, you're now working with 18000 polygons. See below for more details.

2. Check for unnecessary Views:

   World Construction Set V4 only allowed two Views open at once, one planimetric MapView (which was simple 2D raster graphics and did not use 3D OpenGL, nor did it redraw very often) and one perspective CameraView (which used either simple non-OpenGL wireframe 3D or might use solid OpenGL 3D). WCS V5 allows you to have as many Views open at once as you wish, all redraw instantly whenever necessary and all use full 3D OpenGL. Obviously it follows that WCS V5 is often doing more heavy 3D OpenGL work than V4 did, and therefore can be slower.

   It only makes sense to not ask WCS to do more work than it has to. If you don't need all of your Views open at once, close one (or more!) to speed up redraws. Fast systems with high-performance cards might be able to handle four Views open at once, but slow systems should stick to two whenever possible, and close one whenever possible if greater performance is needed. If you're worried about losing your customized Realtime Options (see below), try out the Copy Prefs to Default button in the General page of the View Preferences window to setup these options as your defaults, automatically applied when you open a new View with that type of Camera.

3. Check for unnecessary objects:

   This topic is quite far-reaching and can have a great impact on OpenGL performance on slower systems.

   Terrain and vector objects in WCS5 are made into pre-built Display Lists whenever necessary. Display Lists are a compact and efficient way of storing 3D data that does not change very often (rebuilding Display Lists takes time) and are significantly faster to redraw than drawing the same data not in a Display List. All objects other than the actual terrain surface and vectors are not display lists. Therefore, they can take more time to draw, and are good candidates for turning off to improve performance. Listed below, in order of best candidates to worst candidates, are some Realtime options you might turn off in View Preferences:

   Note: See Also, Plus Task Mode tips below.

   1. Reference Grid: Covers the same area your terrain does, just below the DEMs. Textured, and tessellated to conform to the terrain curvature. Can eat up a lot of polygons, and often is not important. This can be significant in large scenes like the supplied World.proj, even on fast systems.

   2. Lakes: Small vector-constrained lakes may not slow your display much, but large lakes or lakes with complex vector outlines can create large or complex polygons which may get slow. Non-vector-bounded lakes (aka oceans) are much like the Reference Grid (above) in that they cover the same area as your DEMs and can be heavily tessellated. Unlike the Reference Grid, Lakes are not textured, but they are drawn with OpenGL transparency (blending) which can be as slow or slower than textures on some cards. This can be significant in large scenes like the supplied World.proj, even on fast systems.

   3. Clouds: Like non-vector bounded lakes, this is a tessellated, semi-transparent object that covers the area of each cloudmap in your scene. Since many users create very large cloudmaps going all the way to the horizon, this can generate a lot of polygons to make it curve over properly. A good candidate to turn off when you're not actually working with clouds.

   4. ColorMaps: Just like Clouds, above. Can be very large, heavily tessellated and semi-transparent. Turn them off when you don't need them.

   5. 3D Objects: Complex 3D objects (set to Detail preview mode) are not simplified by WCS at all, and are not DisplayListed, so they can be very slow to draw. Where possible, turn off the Realtime 3D Objects option entirely, or choose the Box preview setting in the 3D Object Editor to display only their simple bounding box representation.

   6. Overlays: Ecosystem Map, Slope Map, Fractal Map and Relative Elevation Map Overlays use texturing, and can create a number of fairly large 2D textures which could slow down or swamp a graphics card with little or no texture memory. Use these options sparingly. By default they are off, of course.

      The Contour Overlay, Grey Elevation Gradient, Earth Elevation Gradient and Rainbow Elevation Gradient use small 1D textures, and are not as texture-memory intensive as the complex overlays listed above, but slow cards may not do texturing well at all, and switching all Overlays and Gradients off may boost performance. If you do use Overlays or Gradients, use them only in the Views where they really contribute information, and leave other Views plain.

   7. Vectors: Vectors are also currently DisplayListed (See above) for efficiency. Small numbers of vectors won't bog OpenGL very much, but large numbers of imported DLG data or contours could seriously slow down your redraws. Turn them off when practical. This can be significant in large scenes like the supplied World.proj, even on fast systems.

   8. Control Points: Control Points are really just a type of Vetor, often used for categorizing Contour Lines or Survey Points seperately. The same tips apply as those for Vectors above. If you have imported Control Points and gridded them to make DEMs, you most likely will no longer need your Control Points, so disable the category, or disable the objects themselves in the Database.

   9. Terrain Transparency: A useful feature, but some cards handle transparency very slowly. Avoid this feature (off by default) if your card performs poorly with it.

4. Try Plus Task Mode setting:

   If you wish to lean down the number of objects and items that show up in your views at any one time, try using the (often-overlooked) Plus Task Mode option, only available in the Realtime section of the Popup Menu of a View. This is a per-View-window option that automatically switches on View visibility of the various items that are appropriate to the task mode you happen to be in.

   To use this, open the View Preferences, and switch off all the Realtime items you can, leaving on only the items you wish to see all the time. Then, turn on Plus Task Mode in the Realtime Popup Menu.

   Now, when you switch into Water Task Mode, Lakes/Oceans, Stream Vectors and Wave Models will automatically appear. When you switch to a different Task Mode (say, Sky) the Lakes, Streams and Waves will disappear, and your Cloud Models (and any other Realtime Sky items you might have turned off) will appear.

   Note: A similar oft-overlooked Plus Task Mode option is available in the Render menu of a View Popup Menu, and behaves similarly, ensuring any unenabled items in the current Task Mode are enabled when you render.