05 April 2005

Draft

Specification

for the Creation of

Static 3D Models

For the Visual Object Taxonomy (VOT)

3-D Model Library

Department of Environmental Studies

University of West Florida

11000 University Parkway

Pensacola FL 32514

I. PURPOSE

The purpose of this specification is to define a standard format for the storage of 3-dimensional model data. In the day-to-day operation of a real-time simulation database generation operation, 3D models are created to represent actual man-made and natural objects on the ground.

II. POLICY

This specification will be used for all day-to-day database generation efforts in support of all UWF visual database development projects. This document provides definitive guidelines on format, attributing, and modeling techniques to be used whenever 3-D models are needed in the real-time simulation database production effort

III. DEFINITIONS AND ACRONYMS

LOD Level of Detail

SNE Synthetic Natural Environment

IV. GENERAL

This specification has been developed to serve as guidance for the development of a 3D model library for use in simulator databases. This 3-D modeling specification is designed to provide explicit guidance for the development of detailed and realistic 3-D models for use in fly-thru and drive-thru simulation environments. This specification is not intended for use in the development of very high-resolution 3-D models to be used in walk-thru simulation environments.

V. Generalized Modeling Rules

Geometry Constraints - 3-D models built for the 3-D model library will be required to support multiple simulation subsystems with minimal follow-on conversion effort. Based on an analysis of currently available simulation subsystems, the following constraints have been identified to support the commonly available visual subsystems used throughout the real-time simulation community. The following geometric constraints will be followed as maximum allowable parameters:

1. Each model will contain a maximum of 32 Objects.

2. Each model will contain a maximum of 2000 Faces.

3. There is no limit on the number of edges that a model may contain.

4. Each model will contain a maximum of 6000 Vertices.

5. Each model will contain a maximum of 1024 Point Lights.

6. Each face must be planar (all vertices must lie on the same plane).

Model Efficiency - To insure that model polygon counts remain low, every effort should be made to use external referencing as much as possible. If a farm homestead is being modeled, then a silo, a barn, a tractor, bushes, shrubs, trees and a wide variety of other objects can be included in the farm homestead model by externally referencing each unique model. This technique is used to increase the richness of visual queues and at the same time maintain a low number of polygons in each model file. This is the facet of 3-D modeling that separates the engineer from the true 3-D modeler – efficiently constructed yet aesthetically appealing models.

Model Orientation - Figure 1 illustrates the orientation of models in model-space. The “natural” front of each model will be oriented parallel to the X-axis. In other words, when the viewpoint is oriented in such a way that an observer is looking at the front of the model, the observer will be looking along the positive "Y" axis.

Model Origin - All models in this library will be constructed in such a way the origin of the model will be a discrete an distinctly identifiable point. Except in rare cases, the center of object mass will not be used as the model origin.

Models shall be stored in a Local Space Rectangular Cartesian coordinate system. The model origin will be created in a discrete, readily identifiable, “ground” location on the model. The model origin will have a Cartesian coordinate value of x,y,z = 0,0,0. This Cartesian position will be the location of the feature point that will instance the model in simulation space.

All models will be created in such a way that the predominant portion of the model is in positive XY space. This would mean that when the viewpoint is oriented in such a way that an observer is looking at the front of the model, the model origin would normally be on the left front corner, the closest model corner in the observer's field of view.

In those situations where an object is round and there is no distinct “left front corner”, e.g. tanks, towers, etc., and then the model origin is the center of mass of the object.

The model snapshot files that accompanies each OpenFlight model file (the .icn file), provides a view of the model where the model is oriented in such a way that the location of the model origin is oriented closest to the observer.

Dimensions - All physical dimensions will be in meters. Standardized building story heights will be used for all models. For generic models, the following standard story heights will be used:

Residential - 3 meters

Commercial - 4 meters

Light Industry - 4 meters

Heavy Industry - 5 meters

Polygon Counts - Overall rectangular polygon counts for each static 3-D model should be limited to 200 or less. There are times when a rectangular polygon count will be over 200. However, every attempt should be made to keep polygon counts at a minimum. This rectangular polygon count includes all visual polygons in all LODs.

Rooflines - In the Admin group, each model will have an Object bead called "Roofline". Within this object will be a set of invisible polygons that define the roofline from the highest level of detail of the model. Further, all roof polygons in the highest level of detail will have the roofline box checked. In addition to selecting the Roofline box for each polygon roof feature, to allow more wide spread and efficient use of model geometry in CTDB databases, all roof polygons will be commented to indicate that they are in fact part of the roof of the model. The following standard comment will be entered into the comment field of each roof polygon (note that there are no spaces):

COMMENTS=#ROOFLINE

Footprints - In the Admin group, each model will have an Object bead called "Footprint". Within this object will be a set of invisible polygons that define the actual footprint of the model. This defined footprint will not be a minimum bounding rectangle that encompasses the maximum extents of the model. The footprint object contains a set of zero-elevation polygons that define the exact area covered by the model. Each of these polygons must have the "Cultural Footprint" flag activated.

Basements - In the highest LOD, all models will have either:

1. A basement object that is five (3) meters deep.

2. A basement object that is 9% of the largest XY radius, in the negative z-direction.

3. A basement object that is the larger of option 1 or option 2 above.

This basement object will be composed of polygons that create a "natural" extension below ground of each vertical polygon that makes contact with the zero-elevation level. Basement polygons will be textured with an appropriate texture. For basements of building walls, an appropriate foundation texture (block, brick, or masonry) will be applied. For most other models, the same texture that appears above ground should be applied to the basement polygons. For a three LOD model, the basement object will be present in only the highest level of detail. For a four LOD model, the basement object will usually be present in the highest two levels of detail.

Polygon Color - All visual polygons will have a color value assigned. This color value will closely correspond to the color of the actual texture pattern that will be applied to the polygon.

LOD Transition Ranges - The following general transition range rules are a starting point for LOD application to new models developed with 3 LODs:

Small Features (< 3.0 meters) - 100 m. blend, 500 m. Blend, and 1,000 m Discard

Medium Features (< 25.0 meters) - 340 m. blend, 1,340 m. Blend, and 2,400 m Discard

Large Features (> 25.0 meters) - 1,300 m. blend, 5,000 m. Blend, and 10,000 m Discard

Generalized Hierarchy Rules - When a polygon is to be placed on the surface of another polygon, it must be created as a child of the larger polygon. Making the smaller polygon a child entails using OpenFlight’s hierarchy view and attaching it to the larger polygon. This can also be done by making the larger polygon current in the “Set Parent” window, and then creating the child polygon.

Figure 2 shows the minimum top-level structure that will be present in all models. The Model Name bead is reserved for future expansion. Currently only a single group "Visual" will be used.

The Vis bead is used to store various forms of the model structures in different states of damage. Three different states are currently available for used: 1) Intact; 2) Damaged; and 3) Destroyed. As a minimum the Intact group will always be present in each model. The Damaged, and Destroyed groups are optional.

The Level of Detail (LOD) bead is used to store different resolutions of a feature to be used in the simulation display. For static models developed for fly-thru and drive-thru simulation environments, a minimum of three LOD will be used: 1) LOD-Low; 2) LOD-Med; and 3) LOD-Hi. Static models designed for walk-thru simulation environments will contain at a minimum the three LODs above plus LOD-Vhi – an LOD that will contain a very high detail rendition of the model.

The Object beads will be used to store polygons for each structural portion on the feature. Sequential, encoded, alphanumeric designations will not be used in the naming of Object beads. Easily understandable English-text names will be used to name each object bead. Basement, footprint, roof, roofline, walls, and sidewalk are examples of names that will be used. Figure 3 shows a typical hierarchical structure for a 3-D model.

Generalized Polygon Geometry - Models will not contain convex polygons. All polygons must be created as true planer surfaces. This is not of concern with 3-sided polygons. However, extreme care must be taken to insure that all 4-sided polygons maintain a true planar surface – No Potato Chip surfaces!

During the model design phase, the use of co-planar polygons must be minimized. When co-planar geometry is incorporated in a model, care should be taken to insure that in the model hierarchy, the forward most polygons will always be "child" polygons to all polygons that appear behind them.

Level of Detail (LOD) Rules - All static models will be constructed using a minimum of three (3) LODs. From one LOD to a lower LOD, polygon counts should be approximately halved. (This is not always possible but is a target value).

The lowest resolution LOD will generally be a very simplistic rendition of the model. This level of detail can be as simple as a single vertical billboard polygon with a color value that closely approximates the color of textures used in higher resolution LODs.

CompuScene Specific Comments - Many of the models in the current 3D Model Library contain comments expressly for use in the CompuScene line of image generators. Some model attribution is not directly supported by the OpenFlight standard, but is required to explicitly represent data needed for unique representation (classification, material, foliage, etc.). Some attribution is required to support visualization capabilities, such as level of detail control based on feature priority sometimes called “Range Type Select” (RTSL). In order to support all subsystems, the following attribution must be introduced in the comment field for each bead, according to the model type. Per the OpenFlight standard, the flag “LM_ ATTRIBUTES” is used to unambiguously identify the attributes that are defined by a company other than MultiGen (as other vendors could conceivably use identically named comments.)

Top Level (db) Bead

#LM_ATTRIBUTES

MODEL_SCC <Input> [SEDRIS classification code]

UNITS <M/F> [meters or feet – meters is the preferred standard]

FEATURE_WIDTH <Input> [Actual feature width in meters]

FEATURE_LENGTH <Input> [Actual feature length in meters]

FEATURE_HEIGHT <Input> [Actual feature height in meters]

SEDRIS_MATERIAL_CODE <Input> [Model surface material code]

BUILDING_FUNCTION <Input> [valid for buildings only]

TRUNK_RADIUS <Input> [valid for vegetation only]

FOLIAGE_TRANSMISSIVITY <opaque=0.0, clear=1.0, (foliage above lowest branch)> [valid for vegetation only]

FOLIAGE_RADIUS <Input> [valid for vegetation only]

FOLIAGE_HEIGHT <height from ground to lowest branch> [valid for vegetation only]

VEGETATION_TYPE <12 (coniferous), 17 (palm), 24 (deciduous), 50 (mixed)> [valid for vegetation only]

Group Beads - No Comments Required

Visual Switch Visibility (VIS) Bead

#LM_ATTRIBUTES

VISUAL_MODEL

MASK 0 PERCENT_DAMAGED 0.0

MASK 1 PERCENT_DAMAGED 0.5

MASK 2 PERCENT_DAMAGED 1.0

Visual Groups ( Healthy )

#LM_ATTRIBUTES

LOD_MODEL

RTSL <Feature Type Number for entire model; overrides default by size>

Visual LODs ( High/Mid/Low )

#LM_ATTRIBUTES

LOD_NUMBER <0-9>; [Indicates LOD number for this bead]

Visual Objects - No comments required.

Visual Polygons

#LM_ATTRIBUTE

CUTOUT [for billboard polygons only]

SEDRIS_MATERIAL_CODE <input> [same as polygon surface material]

COLOR_INDEX <0-255> [Indicates the color assigned to face]

LIGHT_INDEX <0-255> [Indicates the color assigned to light]

Model Texture - Generally, texture pattern size should be no larger than 128 x 128 texels. Under certain situations larger texture patches may be required.

Every effort should be made to insure economy in the use of texture patterns. Whenever possible, existing texture patterns should be reused with new models. However, this rule must not be over applied since this will mean the sacrifice of a variety of texture.

All standard MultiGen texture application methods are supported under this specification.

Texture pattern files will be stored in standard SGI RGB (24-bit) and Intensity (8-bit) format. The following types of texture pattern files can be employed in this modeling effort:

Intensity An 8-bit grayscale image format - 1 channel of texture information

Intensity-Alpha An 8-bit grayscale image format (2 8-bit channels) - one 8-bit channel of

texture information and one 8-bit channel of transparency (alpha).

RGB A 24-bit, color image format (3 8-bit channels)

RGB-Alpha A 4-channel, color image format - three channels of 8-bit grayscale (Red,

Green, Blue) and one 8-bit channel of transparency (alpha).

Materials - Assign appropriate material properties to each polygon based on the actual real-world material composition.

Shading - All visible polygons must have shading attributes assigned. Use the following criteria for shading all visual polygons:

Curved Surfaces - select all polygons that comprise a single curved surface and

1. Select "Lit" shading.

2. Select "Update Vertex Normals".

3. Angular Tolerance must be greater than the maximum angle between any two adjacent selected polygons, and Sampling Tolerance is Default

4. Set "Calculate Vertex Colors" to OFF

All non-curved surface polygons

1. Select "Lit" shading

2. Select "Update Vertex Normals".

3. Angular tolerance equals six (6) degrees, and Sampling Tolerance is Default.

4. Set "Calculate Vertex Colors" to OFF

Model File Naming Convention - All models created for this project will be named using the long file naming convention shown below. This naming convention has been adopted to allow the generation of models with a near-free-text descriptive file name. All long filenames will follow a 30.3 naming convention while the short filenames will follow the standard DOS 8.3 naming convention. The long filename will be created in accordance with the example on the following page. The short filename will be generated by using the first 9 characters of the long filename and then dropping the underscore. Both the long filename and the short filename will use the .flt extension.

Generic 3-D Model Naming Convention

Each Model file will be assigned a file name based on the following format:

vFFFFFFFF_DDD…D.flt

Where: FFFFFFFF is the standard VOT classification code of the object with initial place-holding zero digit.

DDD…D an ASCII text descriptive name of no more than

19 characters.

All VOT Models will begin with a lower case “v” to ensure that file names do not begin with a numeric character.

Lower case text will be used within all file names. No upper case text will be used in any model file names. Use underscore delimiting between the VOT value and the Descriptive Name value. Within the descriptive name field use hyphens between words - No Spaces. The ASCII text description should be an abbreviation of the feature name. It should be abbreviated in such a way that its meaning is readily understandable. Do not use upper case characters in the name.

As an example, Figure 4 shows a rendered example of the VOT class - “Electric Power Substation”. The VOT numeric value for this class is 010700744.

Using the naming convention outlined above, the appropriate filename for this 3-D model file would be:

v01070742_elect-power-substa.flt