ELSA GLoria II Quadro SDR

The technical applications and their associated needs are what drives this professional market segment.  Typical applications are Mechanical Computer Aided Design (MCAD) tools such as PTC’s Pro/E, Solidworks, and SDRC Ideas and visualization/simulation applications such as Maya and 3D Studio MAX.  Unlike the consumer game market where the goal is entertainment, these systems must be a productive and cost effective part of an organization’s work process.

Let’s look at the MCAD portion of this market and contrast those needs with the game market.   The goal of the MCAD process is basically expressed as “art to part”.  In an essentially paperless setting, engineers conceptualize, design, and analyze a product and all its component parts based on the data contained in the MCAD program’s database and, at the end of this iterative process, the database is used to generate the Computer Aided Manufacturing (CAM) data to drive the fabrication process.  Traditional paper 2D drawings (blueprints) are neither used nor needed.  This type of work process reduces the time to market for new products.  Some important contrasts with the game apps:

Geometric precision

This engineering data must be precise so the geometric data is usually stored in double precision (64 bit) floating point format. Game developers don’t need this degree of fidelity but they do need speed and minimum data storage, so the underlying databases that drive games are at most of the 32 bit variety. 

Simple shading

The MCAD designer doesn’t normally need complex multi texturing, lighting and other effects for working on their models.  Basic Gouraud (smooth) or flat shading and simple lighting is just fine in most cases.   In contrast, the game developer needs to have a wide variety of these effects in order to enhance the viewing experience and to approximate reality. Whereas fill rate is often the definitive performance factor in today’s 3D games, it carries much less weight in the MCAD field where basic shading is all that’s necessary.  Thus cards with higher fill rates don’t necessarily hold an incredible advantage in the MCAD arena which is why most professional cards have horrible gaming performance (low fill rates).

Game programs make almost no use of 3D line or wireframe rendering; CAD programs require an effective implementation of this feature.

Viewing fidelity

CAD programs put more emphasis on viewing fidelity.  For example, while a 16-bit Z buffer is fine for game play it is not adequate for the viewing of large complex CAD models. Unfortunately for some graphic card drivers (i.e. all NVIDIA drivers) when you select the 16 bit color mode you also get a 16 bit Z-buffer.  This fact forces the CAD user to work in the truecolor mode in order to get the Z-buffer depth that is required.  

Screen Resolution

Because of the complexity of the CAD models and the Unix heritage of most of the technical codes, a screen resolution 1280x1024 is desired.  Almost nobody runs CAD apps at less than 1024x768.  This is in contrast to most games where fill rate limitations of the current crop of 3D accelerators keep playable frame rates under the 1024 x 768 mark.  If frame rate is king in games, then image detail and quality is king in the CAD world.

Model size

The game developer controls model size (polygon count) to get acceptable performance. The CAD user has no such luxury, he is modeling a real world object or system.  MCAD models of large systems may have in excess of 500K polys and there are no workstations made that will spin one of these at say 30 fps.

Cost

The cost of a typical NT workstation ($3K - $10K) is not the dominant factor in deploying MCAD tools.  The full up cost of a skilled engineer usually exceed  $100K per year. The purchase cost of MCAD software is typically $10K-$15K per seat with a software maintenance cost of about $2K per year. In this situation, performance and user productivity are the key factors in the selection of a graphics card and not a $500 cost saving.

Optimization

MCAD and most of the other technical programs are developed to be precise full featured tools and the vendors don’t seem to optimize the code for graphics speed.  In contrast, games (and most OpenGL benchmarks) are highly optimized for speed.

The Unix factor

The technical programs are mostly cross platform (NT and Unix ) applications that for the most part were originally developed on Unix platforms.  In many cases they not especially well tuned for the Windows-Intel platform.  In contrast, game code is mainly designed for the Windows environment.

The visualization/simulation side of the technical workstation market has a different but no less demanding set of market driven technical requirements.