MULTIGEN-PARADIGM'S OPENFLIGHT API RELEASE EXPANDS HORIZONS FOR REALTIME 3D GAME DEVELOPERS
A technical white paper written by
By Wayne Cappas
MultiGen-Paradigm Technical Support

February 1998

Introduction

Realtime 3D technology is now as integral a part of entertainment as it is of visual simulation. With game developers embracing realtime 3D as their own, they are coming up against technical issues that have plagued the visual simulation community for years: hardware and software limitations and capabilities, polygon and memory budgets, rendering techniques, and so on.

Over the last decade, MultiGen-Paradigm Inc. has led the realtime 3D industry in solving customer problems with database production tools that enable efficient, interactive, WYSIWYG modeling and development of realtime 3D objects and environments. Major entertainment industry players already use MultiGen-Paradigm's software and expertise to develop groundbreaking realtime 3D games. MultiGen-Paradigm delivers the tools the gaming community needs to reach realtime 3D goals, and makes those goals even more accessible with the release of the latest suite of Application Programming Interfaces (APIs) for OpenFlight® scene description databases, in conjunction with MultiGen-Paradigm Creator(tm) for Windows NT(tm).

• Nintendo®
• Atari Games
• Rare Ltd.
• Trilobyte
• Microprose
• Paradigm Entertainment
• Origin

and more...

OpenFlight

MultiGen-Paradigm built its reputation on OpenFlight, a revolutionary open standard realtime 3D file format now in public domain and the de facto standard format in the visual simulation industry. Realtime 3D visual simulation systems have always been unique, so maximum flexibility is built in to OpenFlight. OpenFlight scene description databases are complete, cross-platform hierarchical structures, unaffected by individual differences in database hierarchy, attributes, or properties.

The OpenFlight database format supports both simple and relatively sophisticated realtime software applications. The full implementation of OpenFlight supports multiple levels of detail, degrees of freedom, sound, instancing (both within a file and to external files), replication, animation sequences, bounding volumes fore realtime culling, scene lighting features, light points and light point strings, transparency, texture mapping, material properties, and other features.

A simple application that interprets an OpenFlight database can implement a subset of the database specification, and use databases that contain that subset. Such an application scans for the color palette, faces, and vertices, and ignores groups, objects, and other more sophisticated features.

The OpenFlight database hierarchy organizes the visual database into logical groupings, and facilitates realtime functions such as field-of-view culling, level of detail (LOD) switching, and instancing. OpenFlight databases are organized in tree structures with visual nodes. OpenFlight is based on a parent, child, and sibling relationship, hierarchically structured as groups, objects, polygons, subfaces, and vertices. Each node type has data attributes specific to its function in the database. (For a description of principal node types, please see page 5.)

Figure 1:

Graphics and Hierarchy of a Box

However, developers - whether game or visual simulation - have always had unique needs that go beyond the core similarities encompassed by MultiGen-Paradigm. Technological advances in graphics hardware have fueled an explosion in realtime 3D platforms that demand customized attributes. Such attributes and structures, once controlled through a specific Data Base Logic module that the customer would either write themselves or have MultiGen-Paradigm write, can now be taken care of via the OpenFlight APIs.

Four API Levels in One

The MultiGen-Paradigm suite of OpenFlight APIs includes the following four levels:

Improved Access to OpenFlight Databases

The Read Data and Write Data APIs improve access to the OpenFlight format, simplifying the development of applications using OpenFlight. Using the Read/Write APIs, users can create stand-alone applications to read and write OpenFlight database files. Elements can be traversed, queried, and modified. These APIs come standard with all MultiGen-Paradigm products.

Read API

The Data Read API is the bridge between OpenFlight databases and platforms that use a different runtime format. The Data Read API provides basic access routines to open, query, retrieve, and document OpenFlight files. Users can easily convert OpenFlight databases to a different runtime format by using the Data Read API routines in conjunction with their own value-added code.

The Read API significantly reduces the development effort previously required to build hardware-specific loaders or data converters. It also shields users from future changes in the OpenFlight structure, protecting their substantial development investment.

Write API

The Data Write API gives developers greater flexibility to adapt OpenFlight databases to the unique requirements of target platforms. It provides a set of library functions, and gives users easy access users to:

• Modify existing OpenFlight files and related attributes
• Manipulate the hierarchy of existing OpenFlight databases
• Create new OpenFlight databases without using the MultiGen-Paradigm modeler
• Convert third party 3D formats to OpenFlight Content created with commercially available modeling tools, such as Alias(tm), 3D Studio®, SoftImage(tm), VRML, or various CAD packages, can be imported and stored in OpenFlight format.

Easy Expansion of the OpenFlight Format

Extensions API

The Data Extensions API enables realtime 3D database developers to extend or customize the OpenFlight format, adding attributes and functionality not directly supported. Using the Data Extensions API from within the MultiGen-Paradigm software development environment, users can add fields to existing OpenFlight records, as well as define new custom record types. Just as with standard OpenFlight structures, extension data elements can be integrated with the MultiGen-Paradigm Creator modeling environment, as well as by stand-alone applications via the Read/Write

APIs.

The Data Extensions API can be used to meet data requirements that are specific to a target platform, but not native to OpenFlight. Just a few examples include:

• Creating fields that calculate and store face normals
• Creating fields that allow for multiple numbers of textures per polygon
• Customizing Level of Detail (LOD implementation
• Adding user and game-specific data to support specific state engines
• Creating fields to trigger callbacks for enemies, landing gears, etc.
• Creating pick lists for object types

Because an OpenFlight file can have multiple extensions, developers can program for multiple platforms at the same time. The extensions for each target platform are displayed on OpenFlight attribute pages within the MultiGen-Paradigm modeler. While the user is modeling, MultiGen-Paradigm behaves as though the extensions are native to OpenFlight. Extensions are automatically written to and read from disk, and can be searched and modified.

The Data Dictionary contains all defining information about data extensions, such as the extension name, data type, associated OpenFlight

node, and conversion callbacks. For record extensions, the Data Dictionary also includes information about record length, content, and attachment rules. MultiGen-Paradigm automatically consults the Data Dictionary during modeling sessions. If the extension requires extra processing - for example, a face normal calculation - the code to perform the function can be included. The Data Dictionary can be shared among MultiGen-Paradigm users, or it can be withheld to protect proprietary information.

Specialized Plug-In Tools for MultiGen-Paradigm

Tools API

The Tools API, the most notable new feature, leverages the power of the Read/Write and Extensions APIs by providing access to them from within the MultiGen-Paradigm Creator modeling environment. In addition, the Tools API offers an array of features to make plug-in development a snap. For example, it provides a portable GUI development environment, model-time event notification, undo support, and access to MultiGen-Paradigm Creator model-time constructs, such as the select list, tracking plane, and much more.

Using the Tools API, game developers can create different classes of plug-in tools that seamlessly integrate into MultiGen-Paradigm Creator. These classes are:

Database Importer: Reads database files from unsupported file formats, such as 3D Studio Max, into a MultiGen-Paradigm Creator database window. The modeler can then interactively optimize the model for superior realtime performance.

Database Exporter: Writes a database or portions of a database from a MultiGen-Paradigm Creator database window to disk file formats not directly supported by MultiGen-Paradigm Creator. If the realtime file format is not OpenFlight, it is easy to read data back into alternative runtime file formats if necessary.

Image Importer: Reads texture files from unsupported file formats into the MultiGen-Paradigm Creator texture palette, enabling interactive tuning of pixel or texel-based images.

Editor: Creates, modifies, or deletes elements of a database in a MultiGen-Paradigm Creator database window. The programmer can create unique tools to meet specific needs.

Viewer: Creates dynamic user-defined views of a database or portions of a database. Users can interpret OpenFlight data in any way they want --

a view might be anything from a statistics display to a custom database renderer.

The Tools API provides a complete set of services and utilities so that a plug-in tool can truly integrate into and interact with MultiGen-Paradigm Creator. Some of them are highlighted here:

GUI: Plug-ins can create Graphical User Interfaces, such as dialogs or windows, controls, and pixmaps, and interact with those interfaces via a portable abstraction layer.

Event Notification: Plug-ins can subscribe to event notifiers that report significant model-time events or actions to plug-ins, such as select list change, database close, and so forth.

Undo: Plug-ins can integrate Editor tool actions into the MultiGen-Paradigm Creator undo menu.

Model-time Services: Plug-ins can access model-time constructs in Creator, such as the select list, status log, palette items (color, material, texture, etc.), tracking plane, eyepoint, modeling mode and parent, and much more.

Plug-in Defined Preferences: Plug-ins can define text based data stores to maintain user preferences or other plug-in specific values between modeling sessions.

Everything necessary to enhance productivity

With the Tools API, game developers can readily expand MultiGen-Paradigm's powerful, universal realtime 3D modeling toolset with their own specialized tools to meet unique requirements. The Tools API gives users access to MultiGen-Paradigm kernel subsystems, such as the Tool Manager, Undo Manager, and Message Handler, enabling them to customize the user interface, to manipulate the database hierarchy. With this access, MultiGen-Paradigm users can build their own interactive plug-in modules within the MultiGen-Paradigm software development environment. In addition, tools developed using the Data Read/Write or Data Extensions APIs can easily be converted into interactive tools by adding the features of a graphical user interface, such as tool dialogs and undo procedures.

The most common Tools API applications are expected to be data and image format importers and exporters, data editors, and data viewers. However, the possibilities for applications are limited only by the requirements and ingenuity of the user. The OpenFlight API, with the addition of the Tools API component, gives MultiGen-Paradigm Creator tremendous extensibility. MultiGen-Paradigm has already taken advantage of this extensibility by creating several plug-ins for MultiGen-Paradigm Creator 2.0. In the future, we plan to develop more and more plug-ins for MultiGen-Paradigm Creator, and look forward to the new and creative ways our customers will use the API to create innovative plug-ins of their own.

For more information

MultiGen-Paradigm OpenFlight APIs are available for both UNIX and Windows NT development environments. OpenFlight files created in one environment can freely migrate to the other with no developer intervention. The OpenFlight APIs are packaged in the OpenFlight API Software Developers Kit, or SDK. The SDK comes complete with header and library files, users guide and reference manual, as well as source code for a wide variety of sample plug-in tools, data extensions and stand-alone applications to get developers started quickly.

The OpenFlight APIs demonstrate MultiGen-Paradigm's continuing commitment to raising customer productivity to the highest level. To learn more about OpenFlight APIs or MultiGen-Paradigm software tools, please contact Paul Barkin at: (Tel) 408-367 2655, (Email) pbarkin@multigen-paradigm.com, Fax 408-261-4101, or visit our Web site

at www.multigen-paradigm.com.

OpenFlight Principal Node Types

Header: Nodes are database items that appear as labeled boxes in the hierarchy view. The header node is the root or topmost file in the database hierarchy. One is created automatically with each new file, and is labeled db in the hierarchy view.

Group: A group node distinguishes a logical subset of the database. Applying a matrix to a group node enables it to be translated, scaled, rotated, etc. The matrix is inherited by children and sibling nodes. Groups can have child nodes and sibling nodes of any type, except a database header node.

Object: An object node contains a logical collection of geometry. It is a low-level group node that offers distinct attributes.

Face: A face node represents geometry. Its children are limited to vertices that describe a polygon, line, point, or subface. For a polygon, the front side of the face is viewed from an in-order traversal of the vertices. Face attributes include color, texture, material, and transparency.

Subface: A subface node is a face node that is coplanar to, and drawn on top of, another face - in this case referred to as a superface. Subfaces can themselves be superfaces. This structure resolves the display of coplanar faces.

Vertex: A vertex node represents a list of one or more double precision 3D coordinates. For each coordinate, the node references a vertex attribute record that is stored in the vertex palette record. Vertex attributes store x, y, z coordinates and optionally include color, normal, and texture uv mapping information. Vertex nodes are not displayed in the database hierarchy view.

Level of Detail: LODs are sets of models that represent the same object in the database using different numbers of polygons, and are critical to optimizing a realtime 3D database for drawing. LODs automatically concentrate the greatest detail in the area closest to the eyepoint. An LOD node toggles the display based on distance from the eyepoint, according to the user-defined switch-in, switch-out distance and center location.

Morph vertex: Morphing is the gradual transition between one LOD and another. In morphing, an extra set of vertices is added to the higher LOD to allow the two LODs to switch smoothly back and forth. The morph vertex defines the startpoint and the endpoint of the path between which the actual vertex may be interpolated. One endpoint represents the minimum (non morphed) weighting and the other represents the maximum (fully morphed) weighting.

Switch: A switch node contains masks that control the display of its children. Switch masks are attributes of each switch node, and zero or more children can be selected by invoking a selector mask. Any combination of children can be selected per mask, and the number of definable masks is unlimited. Switch nodes are often used for damage states, weapon changes, and trigger events.

External reference: An external reference node references another entire database file. The contents of the child database can be included in the parent database without pasting in the geometry, saving disk space and streamlining the assembly of complex databases. The referenced node or database cannot be edited in the parent database.

Degree of freedom: A degree of freedom (DOF) node can be inserted into a database to add movement to the geometry below it. A DOF establishes a local coordinate system, and the geometry it controls moves around the axes of the coordinate system. The specified range of motion and the transformations it contains are applied to all descendants of the DOF node, ensuring that the effects of multiple DOFs accumulate naturally in the database hierarchy.

Light source: Light source nodes function as group nodes in the hierarchy. The user can vary the position or direction of the light source, and restrict effects to specific parts of the hierarchy. They are exported to the realtime system as part of the database.

Sound: Sound nodes function as group nodes in the database hierarchy. Sound nodes can have new sound files assigned to them at any time. The sound node position is the coordinate location from which the sound is emitted. Attributes include ID, wave index, name, and position, as well as additional attributes used by the realtime software.

Clip region: A clip node defines a set of clipping planes. Moving the clipping planes can increase the viewing performance. Any geometry belonging to the clip node's children that falls outside the specified clipping planes is not displayed.

Text: A text node draws text in a string with a specified font, without injecting the actual geometry into the database as face nodes.

Light points: A light point node represents a collection of light point vertices or a replicated string of a single light point vertex. A light point is visible as one or more self-illuminated small points that do not illuminate surrounding objects.

Other features include:

Binary Separating Planes: Available as an Option to MultiGen-Paradigm Creator. BSP drawing order uses planes that are modeled into the database to determine drawing priority. MultiGen-Paradigm can calculate and insert a nested series of BSPs that produce efficient rendering. Nodes that are not separated by planes are automatically drawn using Fixed Listing, prioritized by their positions in the database.

Bounding volumes: Simple, user-defined shapes that surround the surfaces of models and enable the realtime system to perform collision detection. Bounding volumes are also critical to the realtime culling operation, which reduces the polygon count by drawing only what is in the field of view and culling (ignoring) the rest. The realtime examines groups’ bounding volumes to determine if they intersect the volume of the viewable area. If they do, they are passed down the graphics pipeline for rendering; if not, they are culled.

# # #

MultiGen-Paradigm Inc.

http://www.multigen-paradigm.com

MultiGen-Paradigm and OpenFlight are registered trademarks and MultiGen-Paradigm Creator is a trademark of MultiGen-Paradigm Inc. All other trademarks are the property of their respective owners and are hereby acknowledged. Information in this paper is correct at time of printing, and is subject to change without notice.

© 1998 MultiGen-Paradigm Inc.