Discreet 3D Studio MAX was the first shipping Heidi application. As such, there is industry-wide interest for writing Heidi drivers to accelerate 3D Studio MAX. This appendix is an article originally written in 1998 by Don Brittain of the Yost Group. It is still relevant and provides an overview of important issues when implementing Heidi drivers for 3D Studio MAX and 3D Studio VIZ.

Don Brittain

Yost Group

The information in this article pertains to 3D Studio MAX release 3.1 and 3D Studio VIZ through release 3.0. Both use Heidi 6.0.

High Level Interface Description
From a broad point of view, MAX mainly uses Heidi as a rasterization and bit-blit engine. All lighting, World-to-device coordinate transformations, and clipping is done within MAX (that is, outside Heidi). MAX also takes care of generating viewport text and drawing markers. Heidi is used to rasterize points, lines, and filled (solid, Gouraud-shaded, and textured) triangles into an image and a Z buffer. Heidi is also used to display raster background images, clear the viewports, blit images, and read-back images and the Z buffer.

In a little more detail, the "graphics pipeline" inside MAX consists of several C++ classes. In many ways these build on traditional 3D display methods:
 
• There is an explicit notion of an image buffer and a Z buffer.
• The lighting model and material descriptions are quite traditional.
• Rasterization and texturing use standard techniques.


But there are several ways in which the MAX approach differs from the traditional text-book pipeline. In fact, in the MAX context "graphics pipeline" is a misnomer, because there is really a lot of two-way communication, rather than a bunch of data flowing one direction down a display pipe. In the MAX graphics model:

 
• Lighting and clipping are done with a lazy-evaluation algorithm.
• Object rendering is done on an as-needed basis only. In fact, it is rare for an entire scene to be re-rendered during normal end user scene editing.
• MAX makes extensive use of image and Z buffer "read back" and blitting (that is, caching the image buffer and Z buffer from the Heidi driver and then handing the cached buffers back to the driver for use at a later time).

From just this high-level description, some aspects of how to optimize a Heidi driver for MAX should already be apparent:
 
• Rasterization speed is important, as with all 3D APIs.
• Optimizing individual primitives and triangle strips is imprint.  MAX does not make use of fans or polygons with more than 3 sides.
• Full screen double-buffering in the traditional sense (where the whole screen display is swapped from one physical display buffer to another during vertical refresh) is never used by MAX. MAX uses a blitting "double buffer" model exclusively.
• The speed of image and Z-buffer readback can have a big impact on MAX performance.

More Details
In addition to the above high-level design considerations, there are several other aspects to the way MAX uses Heidi that can affect overall system performance.

Display Buffers

First, with regard to resource allocation, MAX is a pig. Not only does each viewport need a front and back image buffer, and a Z buffer, but (with dual-planes turned on) MAX also needs an extra image buffer and an extra Z buffer to cache the viewport display.

MAX uses these cache buffers to avoid having to re-render an entire scene when only a subset of the objects in the scene change. In almost all real life situations, this results in substantial gains in interactivity for the user, and thus this plays a central role in the MAX display architecture.

But because buffer readback (reading the real image or Z buffer into one of the cache buffers) always requires the transfer of the entire buffer (that is, not a rectangular subset), this operation can be a real bottleneck on some systems. In particular, if the cache buffers do not fit within the memory space of the graphics display card, then the readback operation is limited by the system bus bandwidth.

MAX usually doesn't try to interpret the readback caches in any way. Rather, the caches are simply "blitted" back to the real image/Z buffers at some later time. (Actually, usually only a rectangular subset of the caches are blitted. And the same subset is used for both the image and Z buffers.)

This means that readback data does not usually have to be converted into any standard color formats - whatever is quickest for accomplishing the readback and blit operations within the driver itself is what is best for MAX.  Under these circumstances, MAX will request image data from the driver by way of the HT_Image_Format::any descriptor.

Note: In those cases where MAX does need to be able to interpret the image data, as when creating an AVI or QuickTime file, MAX will request a specific color format from the driver.

As a small consolation for using so much display memory, MAX does not allow the user to overlap the viewports in the main MAX window. And if nothing in the display is depth-buffered, then the Z buffer is not readback or blitted.

 
Heidi primitives
MAX only calls a small subset of the available Heidi calls. No 3D_, 2D_, or font engine calls are made by MAX. All rasterization primitives use the DC_ calls.

The size of textures handed down to Heidi are user selectable as either 64, 128, 256, or 512 pixels square.

Also, even when rendering a depth-buffered scene, MAX often turns the Z buffer on and off. This is because the coordinate system axis display and the viewport labels are never Z buffered. Thus, it is important to optimize the toggling of this state.

On the subject of depth-buffering: MAX never asks Heidi to rasterize non-depth-buffered filled primitives. So, there is no need to even implement those primitives – just kick them back up to the higher level Heidi routines because they won’t be called by MAX anyway.

Multi-threading
MAX is highly multi-threaded. To synchronize input, each viewport has a transparent window above it owned by the main MAX thread. So no input comes to the Heidi window.

Also, each Heidi window has one thread to execute (possibly asynchronous) window procedure calls, and another thread to execute Heidi rasterization calls. Almost all driver calls are executed asynchronously from their request in the higher-level MAX code through a queuing mechanism inside MAX. This can make debugging a Heidi driver a bit of a challenge. So, it is possible to build a non-client/server version of MAX to aid in this regard. As long as all driver calls are fully re-entrant, a driver that is completely debugged in "single processing" mode should continue to work reliably in "multi-processing" mode.

Finally, MAX uses an algorithm to limit the amount of any viewport that is invalidated and blitted during each display update. This means that MAX may not correctly update a viewport display if the user slides the MAX window off the screen and then slides it back on screen. Although this is not optimal, we decided that the speed benefits we obtain from the limited redraws during normal MAX operation far outweighed the loss during this uncommon move, and so we simply require that the user force a display redraw at that time.