dVS File Specifications - Version 2.1 VIZ, BIZ and VTX File Formats first Edition. Revision 8. December 1993 (c) Division 1995 This document is Copyright 1995 Division Ltd. All Rights Reserved. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior written consent from Division Ltd. DIVISION Limited, 19 Apex Court, Woodlands, Almondsbury, BRISTOL, BS12 4JT, U.K. Tel: +44 (0)454 615554 Fax: +44 (0)454 615532 Email: support@division.demon.co.uk DIVISION Incorporated, Suite 101, 400 Seaport Court, Redwood City, CA 94063, U.S.A. Tel: (415) 364-6067 Fax: (415) 364-4663 Email: support@division.com Contents 1. Introduction 1-1 1.1. Objects and Patches 1-1 1.2. Co-ordinate Frame 1-1 1.3. Vertex Ordering 1-2 2. VIZ File Format 2-1 2.1. VIZ File Types 2-1 2.1.1. Geometry Files 2-1 2.1.2. Material Files 2-1 2.2. Scope Definitions of constructs 2-2 2.3. Lexical Conventions 2-3 2.3.1. Strings 2-3 2.3.2. Comments 2-3 2.3.3. Names 2-3 2.3.4. International 2-4 2.3.5. File References 2-4 2.3.6. Forward and Backward compatibility 2-4 2.3.7. Keyword Format 2-4 2.3.8. Specifier List 2-4 2.3.9. Skipping unknown blocks of data 2-5 2.4. File Layout 2-5 2.5. Magic Number 2-5 2.6. Header 2-5 2.7. Texture 2-6 2.8. Ramp 2-9 2.9. Materials 2-10 2.10. Object 2-11 2.10.1. PATCH 2-12 2.10.2. Surface Variables 2-12 2.10.3. Vertex Definitions 2-15 2.10.4. LOD 2-17 2.10.5. Geometry Definitions 2-18 3. BIZ File Format 3-1 3.1. General Information 3-1 3.1.1. BIZ File Types 3-1 3.1.2. Magic Number 3-1 3.1.3. Block Field Encoding 3-1 3.1.4. Document conventions 3-2 3.2. Commenting 3-3 3.2.1. In-line Comment 3-3 3.2.2. Referenced Comment 3-3 3.3. Header Section 3-4 3.4. Trailer Section 3-4 3.5. Texture Section 3-5 3.6. Material Section 3-6 3.7. Ramp Section 3-7 3.8. Object Section 3-8 3.9. Surface Variables 3-8 3.10. Level of Detail (LOD) Section 3-9 3.11. Patch Section 3-10 3.12. Polygon Section 3-10 3.13. Tristrip Section 3-10 3.14. Polystrip Section 3-10 3.15. Pmesh Section 3-10 3.16. Sphere Section 3-11 3.17. Line Section 3-11 3.18. Text Section 3-11 3.19. Vertex List Section 3-12 4. VTX File Format 4-1 4.1. Header, Trailer and Comment Sections 4-1 4.2. Magic Number 4-1 4.3. Field Ordering 4-1 4.4. Texture Map Section 4-1 4.5. Pixel Data 4-2 5. References 5-1 6. Index 6-1 A Configuration Header Identity Words 7-1 B Header Identity Words 7-2 C Table of defaults 7-3 D VIZ BNF File Syntax 7-5 D.1 Notation Definition 7-5 D.2 File Definition 7-5 E Example VIZ File 7-9 E.1 Material File 7-9 E.2 Geometry File 7-10 List of Figures Figure 1 Geometry co-ordinate frame 1-1 Figure 2 Facet Vertex Order 1-2 Figure 2 Texture co-ordinate frame 2-7 Figure 3 Illustrated RAMP data 2-9 Figure 4 Overlapping levels of detail 2-17 Figure 5 Tristrip Illustrated 2-18 Figure 6 Polystrip Illustrated 2-19 Figure 7 Little endian 32 bit word 3-1 Figure 8 Biz header identity word 3-2 Figure 9 Vertex List command break down 3-12 List of Tables Table 1 Scoping Rules 2-2 Table 2 Vertex format for a given patch specification 2-17 1. Introduction This document describes the dVS geometry file specifications of Division's BIZ, VIZ and VTX file formats. This is a revised version of the files, referred to as Version 2, superseding the original file specifications. The geometry file specifications of VIZ and BIZ have been designed to allow efficient rendering on a multitude of hardware platforms which support triangles as the basic rendering primitive, but may also include some other special primitives. The file formats have been devised to be both forward and backward compatible allowing subsequent versions of the VIZ and BIZ file readers and writers to access the same files. This allows the file format to be enhanced to cater for new architecture's without changing the existing underlying geometry format. 1.1. Objects and Patches A PAZ file describes a single OBJECT - for example a UTAH teapot, a table lamp, a Ferrari or a stealth bomber. An object generally consists of one or more PATCHes. A PATCH is a convenient grouping primitive within the object, and will often correspond to a Bezier surface patch. Also, individual PATCHes are generally checked for trivial off-screen rejection before being rendered, so they are a useful structured rendering primitive. A PATCH consists of one or more tessellation's, valid tessellation's include the triangle primitives such as TRISTRIP and POLYSTRIP, as well as a number of higher level definitions such as SPHERE and CYLINDER. These higher level constructs allow the renderer to determine the most efficient rendering method to realise the objects on a given platform. The OBJECT may alternatively be sub-divided by one or more Level of detail (LOD) definitions, defining the same OBJECT with different geometry sets determined by the viewing distance to the OBJECT. The LODs consists of one or more PATCHes describing the object at each detail level. 1.2. Co-ordinate Frame Figure 1 Geometry co-ordinate frame The co-ordinate frame for the geometry is defined as a right-handed co-ordinate system, with the y-axis pointing upwards as shown in Figure 1. The z-axis -ve points into the viewer. 1.3. Vertex Ordering The vertex order for triangles is defined as anti-clockwise for front facing facets. Figure 2 Facet Vertex Order 2. VIZ File Format This chapter describes the object file format for VIZ files, sometimes referred to as VGI (Virtual Geometry Interchange). PAZ is the 3-D renderer used in Division's ProVision range of virtual reality computer and the dView range of rendering accelerator cards for PC and Macintosh. This file format is used on all platforms including Silicon Graphics and enables geometry to be moved between different platforms. The VIZ file format is an ASCII based file format and may be created and edited with a text editor. An equivalent binary format (BIZ) is also supported, as described in chapter 3. Tools are provided to interchange the BIZ and VIZ file formats (Ref. 2). Two types of VIZ file are specified in this chapter, material files and geometry files. A number of fields are common to both file types, namely the header format, commenting and general syntactical representation of the file. The name spaces of the files have been kept unique to allow the files to be merged in the future if required, this should be retained in all future revisions to the file specification. 2.1. VIZ File Types There are two types of VIZ file, VIZ files describing object geometry which have a file extension of .v2z and files to describe materials with an extension of .vmz. The two file types together describe a single object, describing the geometric information in terms of facets, surface materials and textures. 2.1.1. Geometry Files Geometry Files (.v2z) define the facet information used to construct the object in terms of vertices, normals and faces. Geometry files also include local material definitions to describe the surface attributes in terms of colour, transparency and texture. Material definitions also may be referenced from the material file. The VIZ geometry file format comprises a number of sections describing objects and materials as follows:- Magic No. A magic number to quickly identify the file. HEADER Annotates the file and describes the configuration of the data contained. TEXTURE Declares a single texture and it's surface application details. RAMP Declares a single colour mapping function, applied as a texture. MATERIAL Declares a single surface in terms of it's colour and lighting properties. OBJECT Defines the geometry of an object in terms of facets and facet effects. The HEADER must be the first field in a VIZ files, only one instance of the HEADER may be specified. The header has the same format as a material file. Following the header are the material definitions and/or OBJECT section, only one object section may be defined in a VIZ file, this contains all of the geometry for a single object. 2.1.2. Material Files Material Files (.vmz) define the materials used in the geometry definition files, describing the surface attributes in terms of colour, transparency and texture. Material file do not contain any geometric object information. The definitions of the surface attributes defined by the material file have a global scope, hence the names of the materials must be unique. A single material file may contain the material definitions for many geometry files, changing the material definition will change the material for all geometry files that reference that material, providing that no local material definitions have been made. The VIZ file format comprises a number of sections describing the materials as follows:- Magic No. A magic number to quickly identify the file. HEADER Annotates the file and describes the configuration of the data contained. TEXTURE Declares a single texture and it's surface application details. RAMP Declares a single colour mapping function, applied as a texture. MATERIAL Declares a single surface in terms of it's colour and lighting properties. The HEADER must be the first field in a VIZ files, only one instance of the HEADER may be specified. The remaining fields may be specified in any order, forward or back referencing each other, multiple occurrences of the fields may exist to describe the different surface properties. 2.2. Scope Definitions of constructs The scoping rules for Materials, Textures and Ramps are defined as follows on loading into a rendering system:- The concept of local and global definitions is supported, a construct defined with a local scope may only be referenced from the defining file only (e.g. same as static in æCÆ). local constructs when loaded are not accessible by external applications and therefore cannot be modified. The construct name is only valid for the duration of the file load. local constructs may utilise the same name as a global construct (of the same type), however for local definitions to override a global construct the local construct must be defined before it is referenced, otherwise the global construct is used. Where a construct is referenced that is not defined locally, then a global construct is assumed. If the referenced global construct has not previously been defined then it is created with a default set of attributes, the default attributes are displaced when a global definition from the referenced name is encountered. global materials are defined on a First-Come-First-Served basis, the first global construct that is loaded is used thereafter. If subsequent global constructs with the same name are defined then they are ignored (a warning message is generally produced). This condition is considered to be a geometry preparation error. The same definition exists for local constructs, if a file contains multiple local definitions of the same construct then only the first construct is applied, subsequent constructs are discarded. The scoping rules may be summarised in the following table:- Construct Type Construct State Effect referenced Construct does not exist. Create new global - undefined. referenced local definition exists. Use local definition. referenced global definition exists Use global definition. referenced local & global definitions exist. Use local definition. local definition. Construct does not exist. Create new local - defined. local definition. global definition exists. Create new local - defined. local definition. local definition exists. Ignore definition. local definition local & global definitions exist. Ignore definition. global definition Construct does not exist. Create new global - defined. global definition global exists but undefined. Update global with definition. global definition global definition exists. Ignore definition. global definition local definition exists. Ignore local definition process as normal global. Table 1 Scoping Rules 2.3. Lexical Conventions This section describes the lexical conventions of the VIZ file. 2.3.1. Strings A string is a sequence of characters surrounded by double quotes, as in ". . .". The string field uses the \ character as a magic character to delimit special characters. The delimited characters are defined as follows:- VIZ Definition Literal Description \" " Double quote. \n NL (LF) New line. \r CR Carriage Return \t HT Horizontal Tab \b BS Backspace. \\ \ Backslash \ooo ooo Bit pattern. o is octal digit. \0xhh hh Bit pattern. h is hex digit. \ Null Ignored. Line continuation. If the character following the backslash is not one of those specified then the backslash is ignored. Note the \ case, which allows a string to exist on multiple lines. Strings that appear next to each other, separated by white space, are coalesced into a single string e.g. "abc" "def" "ghi" "jkl" "mno" "pqr" "stu" "vwx" "yz" A string spanning multiple lines is the same as a single string definition:- "abcdefghijklmnopqrstuvwxyz" 2.3.2. Comments The /* character sequence introduces a comment which exists to the closing comment marker */. The comment enclosure may appear at any position on the line, commenting the subsequent text until the closing comment marker is reached. Comments may span multiple lines if required, but may not be nested. Single line comments may be specified with the // character sequence, the comment exists until the end of the line. A comment character sequence is not interpreted as a comment when it appears within a character string. e.g. /* This is a comment. It may span multiple lines if required. */ // This is a comment. It exists to the end of the line ONLY. "/* This is not a comment - it appears in a string. */" "// This is not a comment - it appears in a string." 2.3.3. Names Internal name references comprise an alphanumeric string. The string must start with an alphabetic character and may include a limited set of special characters. The character case is differentiated. There is no restriction on the length of a name in the VIZ file, however some rendering platforms may restrict the number of significant characters. The syntax of a name is defined as follows:- [a-zA-z][a-zA-Z0-9_-$#~.%]* 2.3.4. International The VIZ reader supports both British and American spellings of keywords, most notably the word colour (color). Provision should be made to read and write ASCII files with either type of spelling enabled. 2.3.5. File References The VIZ file format includes a number of file references within the file format, such as texture files. All file references may be specified as absolute or relative path names. Relative path names are resolved by the software containing the file reader, where a search path may be defined externally (e.g. by the use of environment variables or pre-defined search directories). File references may omit a file extension, whereby the first file found in the search path that matches the file type context is used. 2.3.6. Forward and Backward compatibility The main purpose of the VIZ file format is extendibility, providing a forward and backward file compatibility. Changes to the file format in the future will not prohibit older versions of the VIZ file parser to read the geometry file, the new sections will not be understood or converted but they will not cause the VIZ reader to fail. To provide this upward and downward compatibility two main constructs have been incorporated into the VIZ file format namely sections and a specifier_list. A section is introduced by a keyword. The contents of the section are delimited by curly brackets, the section contents are determined by the keyword and may contain either section specific data or other sections. The section may optionally be assigned attributes through a specifier_list, delimited by a pair of brackets. This is placed between the keyword and the curly braces. For extensibility, all sections are assumed to have a specifier_list, even if the section is currently defined without attributes e.g. keyword { section contents } A section definition defined with the specifier_list omitted. keyword (specifier_list) { section contents } A section definition with specifier_list. 2.3.7. Keyword Format All keywords, regardless of their nesting depth in other sections, are followed by an optional specifier_list and then a curly bracket set enclosing the data. The keyword format is defined as follows :- keyword (specifier_list) { data } The keyword identifies the type of the data, and if the keyword is not recognised then both the specifier_list and the associated data block are skipped over. 2.3.8. Specifier List The specifier list defines a group of defaults to be adopted for the current keyword enclosure. The specifier list is always preceded by a keyword and is succeeded by data enclosed within a curly brace set {...}. In constructs where the keyword is not understood the parser should look for a specifier start marker, a specifier list '(...)' followed by the data enclosure delimited by the opening brace '{'. The specifier list takes the following form of ( field ; field ; field ) where field has a fixed syntax of optionword=data. The optionword field is an alphanumeric name and delimited by the = symbol. The data associated with the optionword follows the equals character '=' up until the optionword termination character defined as a semicolon ';' or closing bracket ')'. The specifier optionwords may be ignored if not recognised by searching for the termination character, the termination character type determines if another field is defined or the specifier list is empty. A field may also be defined as the empty set. The effect of this is that ( ; ; ; ;) is a valid specifier list. The data associated with a optionword is optionword dependant. 2.3.9. Skipping unknown blocks of data In the event that the VIZ reader identifies an unidentified keyword or specifier_list item and the version numbers of the VIZ reader and file differ, the parser must attempt to recover by skipping the unidentified region of the file and restart the parsing following the offending block. Recovery is performed by finding the terminal character denoting the end of the block. The recovery process must parse the unidentified region of the file to match and count braces and brackets. Comment blocks and strings may legitimately contain terminal characters and must be parsed correctly to ensure that they are not included as part of the file syntax. 2.4. File Layout There are no restrictions on the layout of the file, the white space character set includes spaces, tabs (^I), new lines (^M), carriage returns (^R), page feeds (^L) and comments. There is no requirement for white space characters to separate lexical tokens providing that the adjacent tokens can be interpreted as a different single token. 2.5. Magic Number All VIZ files MUST include a Magic Number string at the first character position in the file. This enables the files type to be recognised by other components in the system without parsing the file. This identity tag must appear as the very first character sequence and is defined as DIV- VIZ2, no white space may preceded the character sequence. 2.6. Header The header defines general file wide information. The header, if present, must be the first in the file and may appear only once. The header may be omitted and the default parameters apply. HEADER (VERSION=02:01; /* Version No of file format */ DATE=dd:mm:yy; /* Date file was created */ TIME=hh:mm; /* Time file was created */ UNIT=INCH; /* Unit of measurement is inch */ SCALE=12.0; /* Define geometry in feet. */ PRECISION=SINGLE; /* Numbering precision. */ FILETYPE=GEOMETRY) /* File content type. */ { COMMENT {"Some kind of comment I guess\n" "Another bit of the comment I guess\n"} } The header specifier fields are defined as follows:- VERSION=MM:mm The version number of the VIZ file format. MM is the revision major number; mm is the minor revision number. DATE=dd:mm:yy The date the file was created. TIME=hh:mm The time the file was created. UNIT=unit Defines the unit of measurement of the defined geometry. The units directly supported are defined by unit as follows:- INCH Imperial units - GB inch. (Default). MM Metric units - millimetres. SCALE=float32 Defines a ratio from the specified unit to the required dimension for the model. This ratio is applied to all vertices. A model defined in meters would use a scale of 1000 and a UNIT of MM. Default scale is 1.0. Field precision is a 32 bit floating point number. PRECISION=mode Precision of floating point numbers to be used, mode is defined as :- SINGLE (32 bit). This is the default. DOUBLE (64 bit). Not supported - reserved for future use. FILETYPE=mode The typed contents of the file, mode is defined as follows:- GEOMETRY File containing geometry definitions (.v2z) MATERIAL File containing material definitions only (.vmz) GEOMETRY is the default when omitted. COMMENT {"string"} A string field to hold an ASCII comment defining the contents of the file. There are no restrictions on the length of the string. 2.7. Texture The TEXTURE section defines a texture to the rendering system. The texture section may appear in any order within the file, following the header. Forward referencing by a material is allowed, although textures are normally defined immediately after the header. The texture section may not appear within the context of any other section definition. The TEXTURE section defines the texture map to the renderer including information as to how the texture is applied. Fields within the section are specified to support the highest level platform, the renderer itself must decide if a field is valid or not. If a field option cannot be supported on the run-time platform then the closest supportable option is chosen as a replacement. The field is ignored if no sensible alternative exists. If a field is not defined then the run time platform selects appropriate default values. The co-ordinate frame of a texture is defined as follows:- Figure 3 Texture co-ordinate frame The TEXTURE section is defined as follows. The fields may appear in any order but may appear once within the section; fields that are omitted assume sensible defaults. TEXTURE (NAME=name; SCOPE=LOCAL) { MAP {"filename"} MINIFY {mode} MAGNIFY {mode} ALPHA {mode} WRAP {mode} WRAP_U {mode} WRAP_V {mode} DETAIL {type, "filename") } The texture fields are defined as follows:- NAME=name The name of the texture. This is an internal name of the texture. Material definitions reference this name to specify the texture which is independent of the actual texture file name. This field must be specified to reference the texture from a MATERIAL. MAP {"file") The name of the texture file to load. The texture file is typically an .vtx format file (the texture file types supported are defined by the supporting platform) and may include a relative or absolute path component. An absolute file name is typically denoted by a "/" at the start of the string. The filename may be specified without an extension and the first valid texture file matching the name is loaded. MINIFY {mode} The mode defines the texture reducing algorithm to use when multiple texels map to a single screen pixel and is defined as follows:- POINT_SAMPLED BILINEAR TRILINEAR MIP_MAP_POINT_SAMPLED MIP_MAP_LINEAR MIP_MAP_BILINEAR MIP_MAP_TRILINEAR MIP_MAP_QUADLINEAR MAGNIFY {mode} The mode defines the texture magnification algorithm to use when a single texel maps to multiple screen pixels. This field is defined as:- POINT_SAMPLED BILINEAR TRILINEAR BICUBIC SHARPEN ALPHA {mode} Specifies how the alpha component of the texture is mixed with the geometry. If the texture does not contain alpha values then the field is ignored. The application mode is defined as follows:- BLEND Blend texture with image. CUT Paint texture on the image, discard background information. This is the fastest application of a texture. BLEND_CUT Combination of both the blend and the cut; the renderer determines the image parts to blend or cut. WRAP {mode} Specifies how the texture is applied to the geometry in both the u and v texture co-ordinates, the application mode is defined as follows:- REPEAT Repeats the texture across the geometry. (Default) CLAMP Applies the texture once and extrudes the edge of the texture to paint the rest of the geometry. SELECT Applies the texture once and does not replicate. When WRAP is specified, WRAP_U and WRAP_V are ignored. WRAP_U {mode} Specifies how the texture is applied to the geometry in the u texture co-ordinate frame only, the application mode is defined as follows:- REPEAT See WRAP for a description of the parameters CLAMP SELECT WRAP_V {mode} Specifies how the texture is applied to the geometry in the v texture co-ordinate frame only, the application mode is defined as follows:- REPEAT See WRAP for a description of the parameters CLAMP SELECT DETAIL {type, "file"} Specifies an alternative detailed texture map to use when a texture is magnified too much. The new texture is applied to the geometry and is integrated with the existing geometry. The type field defines how the detailed texture is applied to the geometry as follows:- NONE Disable detailed texture mapping. ADD Performs a summation of the course texture and the detailed texture to form the applied texture. MODULATE Modulates between the course texture and detailed texture. The file parameter is the filename of the detailed texture map to apply. The texture file is typically an .vtx format file (the texture file types supported are defined by the supporting platform) and may include a relative or absolute path component. An absolute file name is typically denoted by a "/" at the start of the string. The filename may be specified without an extension and the first valid texture file matching the name is loaded. When the detail map is enabled and the filename is \0 then a default detail map modulation pattern is used. 2.8. Ramp A RAMP definition is used on a number of specialised rendering platforms and allows an 8-bit grey scale colour texture to be 'splined' onto an RGB colour definition using interpolation techniques. Given a texel to be rendered of value 1.0 * t * 0.0 then the colour is obtained from the ramp r,g,b definitions using the following sets of equations:- r = r1.t + r0.(1-t) g = g1.t + g0.(1-t) b = b1.t + b0.(1-t) r, g, b are the resultant colours. r0, r1 define colour spectrum for the red component, similarly for g0, g1 and b0, b1. t a 256 grey scale texel value. The RAMP may be visualised as follows:- Figure 4 Illustrated RAMP data The RAMP section is defined in any order within the file following the header section. The RAMP definition must not appear within another section enclosure, but may be forward referenced from another section. The section is ignored if the rendering sub-system cannot support the RAMP function. The RAMP data is defined as follows:- RAMP (NAME=name; SCOPE=GLOBAL) { DATA {r0,g0,b0,r1,g1,b1) } The fields are defined as follows:- NAME=name The reference name of the ramp function. This field must be defined in order to reference the RAMP data. DATA {r0,g0,b0, r1,g1,b1} The ramp minimum (rgb0) and maximum (rgb1) RGB colour values specified as floating point values in the range 0.0 to 1.0 where 0.0 is darkest. Only one DATA definition may appear within a RAMP section. 2.9. Materials The MATERIAL section defines a material to the rendering system. The Material section may appear in any order within the file, following the header. Forward referencing by a PATCH or OBJECT is permitted, although materials are normally defined after any TEXTURE or RAMP definitions. The MATERIAL section may not appear within the context of any other section. The MATERIAL section defines the colour and surface properties of the geometry, in terms of texture, surface lighting attributes and colour. MATERIALs reference the TEXTURE and RAMP sections to obtain the painted properties of the surface, additional fields within the section include colour (ambient, diffuse, specular, and emissive) and opacity; specified as RGB components. If any field is omitted then default values are used. MATERIAL (NAME=name;SCOPE=LOCAL) { TEXTURE {name} ENVIRONMENT {name} AMBIENT {red,green,blue} DIFFUSE {red,green,blue} SPECULAR {red,green,blue,power} EMISSIVE {red,green,blue} OPACITY {red,green,blue} RAMP {name} } The fields are defined as follows. The fields may appear in any order but may appear once within the section; fields that are omitted assume sensible defaults. NAME=name The name by which the material is referenced from the OBJECT and PATCH definitions. This is an alphanumeric name space string. TEXTURE {name} Defines the texture associated with the material definition, name references the texture as follows:- NONE No texture is assigned to the material. (Default). DEFAULT A dynamic texture which may be applied at runtime. texture_name The name of the texture associated with the material, this references a TEXTURE section definition. ENVIRONMENT {name} Defines Environment mapping of a texture onto a surface. Texture map values are not required for the application of an Environment map. The name field defines the texture to be applied and is defined as follows:- NONE No texture is assigned to the material. (Default). DEFAULT A dynamic texture which may be applied at runtime. texture_name The name of the texture associated with the material, this references a TEXTURE section definition. AMBIENT {r,g,b} Defines the ambient reflection coefficient of the material surface in terms of the RGB colour coefficients. The parameters are specified in the range 0.0 to 1.0; the default if omitted is 1,1,1. DIFFUSE {r,g,b} Defines the diffuse coefficient of the material surface in terms of the RGB colour coefficients. The parameters are specified in the range 0.0 to 1.0; the default is 1,1,1 if omitted. SPECULAR {r,g,b,p} Defines the specular coefficients of reflection (with respect to the eye) of the material in terms of the colour components and power. The colour parameters rgb are specified in the range 0.0 to 1.0. Power p defines the materials specular exponent in the range 1.0 to 128.0. The default when omitted is 0,0,0,1. EMISSIVE {r,g,b} Defines the emissive properties of the surface (e.g. self illuminating) in terms of the colour components. The colour parameters rgb are specified in the range 0.0 to 1.0. The default when omitted is 0,0,0. OPACITY {r,g,b} Define the opacity (transparency) of a surface. The colour parameters rgb are specified in the range 0.0 (transparent) to 1.0 (filled). Where a full rgb opacity cannot be realised then the average of the rgb components define the opacity level. The default when omitted is 1,1,1. RAMP {name} Defines a RAMP to be associated with the material. name is the name of the ramp data to use. The default, if omitted, disables the RAMP. 2.10. Object The OBJECT section appears once only in a VIZ file and describes the geometry of a model in terms of the vertices, polygons and associated material attributes. An OBJECT has a name associated with it, which is used as a handle to allow higher level software to reference the object for geometry manipulations. The NAME field may be omitted in any definition, the default being that no name is defined. The OBJECT is built from a number of LOD records where each LOD record describes the geometric representation for a particular range of viewing distances. If no LOD is specified then one LOD is assumed for the entire OBJECT. Immediately following each LOD (or OBJECT when no LODs are present) are any number of PATCH records that define the properties of the geometry. The OBJECT section is defined as follows:- The OBJECT section without LOD definitions:- OBJECT () { PATCH (...) { ... } PATCH (...) { ... } } The OBJECT section with LOD definitions:- OBJECT () { LOD (...) { PATCH (...) { ... } PATCH (...) { ... } } LOD (...) { ... } } 2.10.1. PATCH An OBJECT (or LOD) consists of one or more patch's, introduced by the keyword PATCH. A PATCH acts as a container for geometry definitions, having a surface variable parameter list to describe the attributes of the geometry. A PATCH inherits the surface variables from its parent enclosure, which is typically an OBJECT, and modifies those inherited definitions using its own local definitions. Variables assigned at the PATCH level return to their previous values at the end of the PATCH and are considered to be scoped to the calling PATCH only. PATCHes may not be nested within other PATCHes. Coplanar geometry should use the DECAL definition to separate coexisting faces. A patch definition has the following syntax:- PATCH () { /* PATCH definition */ SPHERELIST .... ... TRISTRIP.... ... } PATCH { /* Note patch has no variables - uses inherited defs. */ TRISTRIP ... TRISTRIP ... } 2.10.2. Surface Variables The surface variables define the attributes of the surface in terms of the material, texturing etc. The surface variables are referenced from an OBJECT or PATCH section header. The surface variables define the surface attributes of all of the enclosed geometry within the section unless over-ridden by other surface definitions. The surface attributes are defined as follows for an OBJECT, the same definitions apply to a PATCH header. OBJECT (NAME=helmet; F_MATERIAL=bright_steel; B_MATERIAL = brown_leather; PLANE=NORMAL; DECAL=0; DRAWMODE=FILLED; VERTEX=NORMALS, 2D_TEXTURE, LOCK=OFF) { /* Define the helmet. */ PATCH { TRISTRIP .... ... } PATCH ... /* Define the strap on the helmet. */ PATCH (NAME=strap; F_MATERIAL= black_leather; B_MATERIAL=F_MATERIAL) { TRISTRIP ... .... } PATCH (NAME=spike; B_MATERIAL=NONE) { TRISTRIP ... } } The above example defines an OBJECT called helmet, which has a number of specifiers associated with it which are used in the first set of PATCH definitions. Part of the helmet is a strap, this is defined as a separate PATCH which has it's own set of parameters, the outermost OBJECT definitions are inherited by the patch and a selected number of those parameters are overridden by the PATCH specifier list. The strap in this case has over-ridden the material colour on the front and back facing facets to be black_leather rather than bright_steel. The following PATCH, spike, uses the default object definitions, the definitions within the strap PATCH only exist for the scope of the PATCH. The surface variables define the type of vertices that should exist within a PATCH and its sub- sections. If texture is defined, then the vertices are defined with texture co-ordinates, similarly for normal's and vertex colours. e.g. Given the following PATCH definition, the TRISTRIP construct may only define vertices that match the PATCH (or OBJECT) definition. PATCH (F_MATERIAL = red_brick; VERTEX = COLOURS, 2D_TEXTURE) { TRISTRIP { {x,y,z,Nx,Ny,Nz,u,v} ... {x,y,z,Nx,Ny,Nz,u,v} } } The following tables defines the surface variables definitions and parameters. Options may be ignored, or defaulted to another option, if the hardware platform cannot support them:- NAME=name The name by which the material is referenced from the OBJECT and PATCH definitions. This is an alphanumeric name space string. F_MATERIAL=name The name of the material definition to use for the patch for all front facing facets. The name field may take the following values:- NONE No material defined on the front face. (Default). material name A reference to a material definition. DEFAULT Use a default material on the front face. B_MATERIAL=name The name of the material definition to use for the patch for all back facing facets. To obtained double sided faces then this field must be specified. The name field may take the following values:- NONE No material defined on the back face. (Default). material name A reference to a material definition. DEFAULT Use a default material on the back face. F_MATERIAL Use the front facing definition for the back faces. PLANE=mode The destination rendering plane into which the geometry is rendered defined by mode:- NORMAL The default rendering plane when omitted. UNDERLAY Drawn at back, anything existing in the NORMAL or OVERLAY is drawn in front of this plane. OVERLAY Drawn at the front, any geometry existing in the NORMAL or UNDERLAY planes appears behind this plane. FACETED=mode Allows the removal of all normal's with the replacement of a single normal per face to produce a flat shading model. The facets to be removed are defined by the mode as follows:- NONE Disable flat shading model. (Default). BACKFACE Replace the back facing facets only. FRONTFACE Replace the forward facing facets only. TWOFACED Replace both the forward and back facing facets. DECAL=distance Defines the action on coplanar polygons, enabling the polygon order to be defined by setting an artificial distance to move the polygon relative to the polygon position in the Z axis. This removes the Z-Buffer beating effect. The distance parameter is a signed 32- bit integer added to the polygon Z-axis and is defined as follows:- 0 Regular ordering. (Default). -ve Force polygons to be rendered behind polygons with the same z value. +ve Force polygons to be rendered in front of polygons with the same z value. The magnitude of the distance parameter determines the ordering of polygons with the same Z value. The distance parameter has no unit of measurement associated with it, a single value represents an epsilon (*) delta value determined by the renderer. DRAWMODE=mode,width Determines the polygon rendering mode in terms of filled or wire- framed rendering. The mode field is defined as follows:- FILLED Filled polygons. The width field is ignored. (Default). WIREFRAME Enable wire frame mode. A width field, if specified, is an integer that denotes the width of the line in pixels. DOTTED Wire framing mode using dotted lines. A width field, if specified, denotes the size of the dots in pixels. The width field is an optional field, if omitted the default is 1. The field is not specified for the FILLED mode. VERTEX=mode[,mode]* Determines the information carried by a vertex definition in terms of the normals and burnt in colour information. The mode is defined as by a logical OR of the different fields defined as follows:- NONE The vertices are defined as (x,y,z only) (Default - always applied). NORMALS The vertices are defined with Normals (Nx,Ny,Nz). LUMINANCE The vertices are defined with grey scale colour (l,a). RGB The vertices are defined with RGB colour (r,g,b,a). RGB and LUMINANCE are mutually exclusive. 2D_TEXTURE The vertices are defined with 2-dimensional colour information (u,v). 3D_TEXTURE The vertices are defined with 3-dimensional colour information (u,v,w). 2D_TEXTURE and 3D_TEXTURE are mutually exclusive. SPECIAL="String" An undefined text area where arbitrary strings may be placed to command the renderer to perform a specialised task or to propagate some specific information. This command is renderer specific, and if it is not recognised then it is ignored. The ability to specify control information down to the patch level provides great flexibility allowing the VIZ file format to be tailored to a specific application requirement. Example uses include;- identify patches to be used as texture billboard stamps, identify a patch type to be of type terrain for terrain following etc. The String parameter is treated as a byte stream and may include Null's and other non-standard characters to define the data. LOCK=state The run-time state of the material overrides. A surface may be defined as locked which prohibits a material override to be applied to a patch or object as defined by state:- OFF The default state when omitted. ON The patch or object is locked and the material properties of the patch cannot be altered. 2.10.3. Vertex Definitions Geometry is defined in terms of vertices and their connectivity, the connectivity may be explicit or implied by vertex ordering or geometry form. The vertex information defines a position in space, but may also include normal, colour and texture information. The types of vertex are defined as follows:- {x,y,z} Position only. Used for flat shaded models. {x,y,z,Nx,Ny,Nz} Position + Shared normals. This is the usual vertex definition. {x,y,z,l,a} Position + luminance (mono colour). Vertex definition used in radiosity models which have pre-calculated the colours. {x,y,z,r,g,b,a} Position + colour. Vertex definition used in radiosity models which have pre-calculated the colours. {x,y,z,Nx,Ny,Nz,l,a} Position + Shared Normals + Luminance. Not currently supported. Reduced to {x,y,z,l,a}. {x,y,z,Nx,Ny,Nz,r,g,b,a} Position + Shared Normals + Colour. Not currently supported. Reduced to {x,y,z,r,g,b,a}. {x,y,z,u,v} Position + 2D texture. Flat shaded textured models. {x,y,z,Nx,Ny,Nz,u,v} Position + Shared normals + 2D Texture. Textured, smooth shaded surface definition. {x,y,z,l,a,u,v} Position + Luminance + 2D Texture. Textured radiosity models. {x,y,z,r,g,b,a,u,v} Position + Colour + 2D Texture. Textured radiosity models. {x,y,z,Nx,Ny,Nz,l,a,u,v} Position + Shared Normals + Luminance + 2D Texture. Not currently supported. Reduced to {x,y,z,l,a,u,v} {x,y,z,Nx,Ny,Nz,r,g,b,a,u,v} Position + Shared Normals + Colour + 2D Texture. Not currently supported. Reduced to {x,y,z,r,g,b,a,u,v} {x,y,z,u,v,w} Position + 3D texture. Flat shaded textured models. {x,y,z,Nx,Ny,Nz,u,v,w} Position + Shared normals + 3D Texture. Textured, smooth shaded surface definition. {x,y,z,l,a,u,v,w} Position + Luminance + 3D Texture. Textured radiosity models. {x,y,z,r,g,b,a,u,v,w} Position + Colour + 3D Texture. Textured radiosity models. {x,y,z,Nx,Ny,Nz,l,a,u,v,w} Position + Shared Normals + Luminance + 3D Texture. Not currently supported. Reduced to {x,y,z,l,a,u,v,w} {x,y,z,Nx,Ny,Nz,r,g,b,a,u,v,w} Position + Shared Normals + Colour + 3D Texture. Not currently supported. Reduced to {x,y,z,r,g,b,a,u,v,w} The combination of flags in the VERTEX field within a PATCH or OBJECT define the format of the vertex definitions appearing in any other enclosed sub-section. The vertex definitions expected given a field value is defined in Table as follows:- VERTEX/ TEXTURE NONE NORMALS RGB LUMINANCE NONE {x,y,z} {x,y,z,Nx,Ny,Nz} {x,y,z,r,g,b,a} {x,y,z,l,a} 2D_TEXTURE {x,y,z,u,v} {x,y,z,Nx,Ny,Nz,u,v} {x,y,z,r,g,b,a,u,v} {x,y,z,l,a,u,v} 3D_TEXTURE {x,y,z,u,v,w} {x,y,z,Nx,Ny,Nz,u,v,w} {x,y,z,r,g,b,a,u,v,w} {x,y,z,l,a,u,v,w} Table 2 Vertex format for a given patch specification 2.10.4. LOD The LOD (Level of detail) section determines how this LOD will be drawn by the renderer. The ranges given must be for unity scale with a FOV of 45 degrees. If no values are given then the default values generate a LOD which is always visible. An LOD may only appear within the context of an OBJECT but there may be multiple LOD definitions defining forms of the geometry. No restriction is placed on the ordering of LODs within an OBJECT, the ordering is derived from the distances when the LODs are loaded. LOD distances may overlap with each other, the renderer determines when each LOD becomes active based on the distance to the object, and on some systems, the load on the graphics subsystem. The three LOD levels are shown in the following figure, the cross hatched regions denote LOD definitions which overlap. Within these regions the TRANSITION mode determines the operation of the geometry swapping. A BLEND operation is valid within the whole of the region, while a SNAP operation exchanges the geometry at either extremity dependant upon the direction of motion of the object. The LODs may be defined in any distance order. Figure 5 Overlapping levels of detail The LOD definition is defined as follows:- LOD (NAME = name; DISTANCE = in,out; TRANSITION = SNAP; REFERENCE = x,y,z) { PATCH (..) { } } The fields of a LOD are defined as follows:- NAME=name The name by which the LOD is referenced from the OBJECT definition. This is an alphanumeric name space string. The name is not exported to the renderer. DISTANCE=in,out Defines the viewing distances between the eye and the REFERENCE point in which the level of detail geometry is valid. in is a floating point value specifying the minimum distance; out specifies the maximum distance. TRANSITION=mode Defines the geometry transition between different levels of detail, mode is defined as follows:- SNAP Toggle between the different LOD's by straight replacement. (Default). BLEND Blend the different LOD's together to provide a smooth transition between the two. This may involve showing both LOD's simultaneously ensuring a smoother transition. The function of the BLEND is platform dependant. REFERENCE=x,y,z Defines the reference point for the LOD calculation in terms of a 3D position (x,y,z) relative to the models origin (0,0,0) and is nominally defined as the centre of the overall model dimensions. This allows the object to be split over several files, if required, while retaining a consistency in flipping the image. 2.10.5. Geometry Definitions The geometry definitions appear within PATCH's only and define geometric information to the renderer. 2.10.5.1. TRISTRIP The TRISTRIP describes a tessellation of connected triangles. TRISTRIPs may be generated naturally when tessellating bivarite parametric surfaces (e.g. Bezier surface patches), surfaces of revolution and extrusions. The vertex formation of a TRISTRIP is shown in Figure 6. Figure 6 Tristrip Illustrated A TRISTRIP requires n+2 vertices to describes n triangles. Triangle n is constructed from vertices n+2, n+1 and n. For the above example the TRISTRIP definition is defined as follows:- TRISTRIP { { x, y, z, r, g, b, a }, /* Vertex 0 */ ... { x, y, z, r, g, b, a } /* Vertex 6 */ } 2.10.5.2. POLYSTRIP The POLYSTRIP describes a tessellation of connected triangles. The formation of a POLYSTRIP is shown in Figure 7. Figure 7 Polystrip Illustrated A POLYSTRIP requires n+2 vertices to describes n triangles. Triangle n is constructed from vertices n+2, n+1 and 0. For the above example the POLYSTRIP definition is defined as follows:- POLYSTRIP { { x, y, z, r, g, b, a }, /* Vertex 0 */ ... { x, y, z, r, g, b, a } /* Vertex 6 */ } 2.10.5.3. PMESH A PMESH describes a list of vertices referenced by a connectivity list. The connectivity list describes triangles in terms of three vertices from a vertex pool. The vertex type is determined by the PATCH definition. The PMESH is defined as follows. Note that any number of CONNECTION_LIST blocks may appear in a PMESH structure, each block may specify a group of vertices that are planer, however the number of vertices in the connection list must be defined as specified in the connection list header. PMESH { VERTEX_POOL { {vertex definition} /* Vertex [0] */ {vertex definition} /* Vertex [1] */ ... {vertex definition} /* Vertex [n-1] */ } CONNECTION_LIST (PCOUNT=3){ /* list of 3 sided polygons, vertices defined by index (from 0) into vertex pool above */ {v1, v2, v3} ... {v1, v2, v3) } CONNECTION_LIST (PCOUNT=4){ /* list of 4 sided polygons, vertices defined by index (from 0) into vertex pool above */ {v1, v2, v3, v4} ... {v1, v2, v3, v4) } CONNECTION_LIST (PCOUNT=6){ /* list of 6 sided polygons, vertices defined by index (from 0) into vertex pool above */ {v1, v2, v3, v4, v5, v6} ... {v1, v2, v3, v4, v5, v6) } } PCOUNT=vertex_count vertex_count specifies the number of verticies that define planer polygons, the edges of which are defined in left to right order as follows:- (v1,v2), (v2,v3), .. (vn,v1) This is an integer value in the range 3..255. The default value when omitted is 3. 2.10.5.4. SPHERELIST A list of spheres defined as a centre position and radius. Where the renderer does not naturally support a sphere primitive, the renderer constructs a triangle based representation of the sphere using the DICE values as a hint to form the sphere. SPHERELIST (DICE_U=horiz_dice; DICE_V=vert_dice) { {x,y,z,r} /* at least one required */ {x,y,z,r} } DICE_U=horiz_dice Defines the number of vertices -1 to be formed on a hemisphere of the sphere in the horizontal axis. This is an integer value in the range 3..65565. A value of 0 denotes that the renderer should determine a suitable number of points. DICE_V=vert_dice As DICE_U for the vertical axis. {x,y,z,r} Defines the sphere in terms of a centre position xyz and a radius r. 2.10.5.5. LINE The LINE section enables lines to be specified as a series of connected vertices. The line thickness may be specified or a default of one pixel will be used. LINE (THICKNESS=pixels) { {x0,y0,z0} /* Minimum of 2 vertices. */ {x1,y1.z1} } THICKNESS=pixels The thickness of the line in pixels. {x,y,z} A position vector or a line end point. A minimum of 2 vertices must exist in the LINE vector list to construct a line. Where n vertices are specified n-1 lines result, the end point of one line becomes the start of the next line. 2.10.5.6. TEXT The TEXT section enables text to be realised. A text attribute contains a list of ASCII characters, a font definition (or a default), and positioning instructions. Standard ASCII codes such as \n are used to construct multiple lines, alignment of new lines appears under the start of the previous line. The TEXT section is defined as follows:- TEXT (FONT=font; SCALE=sx,sy,sz; ORIENTATION=ox,oy,oz) { STRING {x,y,z,"string"} STRING {x,y,z,"string"} } The fields are defined as follows:- FONT=font Defines the graphic font to use. The font types are defined by font as follows:- QUICK The quickest font available on the hardware platform. This is a fixed size and is not rotatable. This is the default when omitted. BITMAP A simple bitmap font; the font may be rotated, scaling is limited. VECTOR A line vector font; the font may be rotated. POLYGONAL_2D A polygonal 2D representation of the font which may be scaled and rotated. POLYGONAL_3D A polygonal 3D font which is fully manoeuvrable. TEXTURE A Texture as a font SCALE=sx,sy,sz Defines the scale of the text. Each axes may be scaled independently using a floating point value for each axes. When omitted the default is 1.0. ORIENTATION=ox,oy,oz The orientation of the font. The orientation is specified in degrees and is applied in an z, y, x order. The default is 0,0,0. {x,y,z,"string"} The string of text to be displayed at position xyz. The string may only consist of printable characters. The use of unprintable characters will have undefined results. 2.10.5.7. POLYGON The POLYGON section describes an N sided convex planar polygon. The polygon is defined as a closed connected list of vertices whose edges define the boundaries of the polygon. A minimum of 3 vertices must be supplied, requiring n vertices to describe an n faced polygon; the last vertex is assumed to connect to the first to close the polygon. The syntax of the command is defined as follows:- POLYGON { { vertex definitions } } 3. BIZ File Format The BIZ file format is the binary equivalent of the ASCII VIZ file format. The syntax of the BIZ file format is discussed in this chapter. 3.1. General Information The BIZ file format is based on a little endian memory model. All integer and floating point values are stored as little endian. The little endian memory model stores the high order bits in the highest addressed byte as follows:- Figure 8 Little endian 32 bit word 3.1.1. BIZ File Types There are two types of BIZ file, these being the binary equivalents of the ASCII VIZ file. The binary geometry files are defined with a file extension of .b2z, material files with an extension of .bmz. The same segmentation of fields is applied to the BIZ file. 3.1.2. Magic Number The first 8 bytes of any BIZ file are the magic number of the file. This is a character string and is defined in ASCII as "DIV-BIZ2". 3.1.3. Block Field Encoding There are two types of data constructs within a BIZ file format, a section block and a configuration block. The blocks comprise of an identity tag, a length field followed by the data and is structured as follows:- The identity tag identifies the enclosed data. The block length is the length in bytes of the enclosed data and enables unidentified fields to be skipped by the BIZ reader if they are not recognised. The block data is the data described by the identity tag. The block data may be comprised of configuration blocks, which must appear immediately after a block header (a block header is defined as the identity tag and the block length) if they are present or other section blocks or raw data whose format is determined by the identity tag of the block. The format of the block header field is defined as follows, there are 3 sizes of header which may be used depending on the size of the section being described. Typically the smallest block header size that will fit may be used, although a full block header may be used anywhere:- Block Header Word Size Maximum Block Size Block Header Words Format 6 Bytes 4 GBytes Identity Tag [bit15 = 1; bit14 = 0; bits13-12 = 0; bits11-0= block type dependant] Block Length [0..31] 4 Bytes 64 KBytes Identity Tag [bit15 = 0; bit14 = 1; bits13-12 = 0; bits11-0= block type dependant] Block Length [0..15] 3 Byte 256 Bytes Identity Tag [bit15 =0 ; bit14 = 0; bits13-12 = 0; bits11-0= block type dependant] Block Length [0..7] 3.1.3.1. Section Header. A block section header is defined by bit13 set as 0. The configuration bit modifies the header to become a block configuration header. The same sizing definitions apply. Figure 9 Biz header identity word 3.1.4. Document conventions The BIZ file is defined in terms of the identity tag field encoding, describing the identity of the command and the data associated with it. The file format is described using tables, a single entry existing for each command. The format of the tables is defined as follows:- 1 2 3 4 xx00 0x003 length HEADER. Start of the header section. 0x2002 0x02 0xmm 0xnn VERSION. Version Number. mm=major. nn = minor. Default = BIZ reader version. The table has four columns, depending upon the information contained the first two columns may be joined together. The column definitions are defined as follows:- 1 The upper nibble of the 16 bit identity tag field, specified in binary. xx denotes that the bit assignment is unknown - dependent upon the length of the field. 2 The lower 3 nibbles of the 16 bit identity tag field, specified in hexadecimal notation. 1 and 2 combined. The 16 bit identity tag field specified in hexadecimal notation. A combined field is used when the field length can be determined - this is used when the associated data length is not variable. 3 The syntax of the data described by the identity tag of fields 1 and 2. 4 A description of the field itself. 3.2. Commenting A comment file is supported by the BIZ file format. This feature has been added to allow debugging of BIZ file converters. This feature enables the BIZ file to be annotated during converter development, and may be used mark up sections of the BIZ file that are development enabling regions of the BIZ file to be identified. The BIZ reading routines will not translate the contents of a comment. The contents of the comment are undefined and are treated as a stream of bytes. The comments may appear anywhere in the BIZ file stream provided that they lie on the appropriate header boundaries. Two classes of comment exist; section comments that may appear where sections are defined and configuration comments which are used within a configuration grouping. All comments are NULL terminated. Two types of comment exist, an in-line comment and a referenced comment, these are defined as follows:- 3.2.1. In-line Comment An in-line comment is a comment block that encompasses both the comment marker, denoting the position in the file and the text associated with the comment. The comment fields are defined as follows:- 0x0000 0xnn comment 0x4000 0xnnnn comment 0x8000 0xnnnnnnnn comment. 256 byte header class comment. 64K byte header class comment. 4G byte header class comment. 0x2000 0xnn comment 0x6000 0xnnnn comment 0xa000 0xnnnnnnnn comment 256 byte configuration class comment. 64K byte configuration class comment. 4G byte configuration class comment. 3.2.2. Referenced Comment A referenced comment is a comment block that retains the position of the comment in the file but does not include the comment text, the comment text is held within a dictionary field and the comment makes reference to that text by way of an integer offset into the dictionary. Referenced comments are used in preference to In-line comments as the comments do not have to be parsed and read by the BIZ reader, although they are more difficult to process because of forward referencing. The dictionary is generally placed after the trailer, denoting the end of the valid data for the file. The referenced comments have the following format:- 0x0001 0x04 offset Referenced COMMENT. offset is an unsigned 32-bit offset into the comment dictionary. The offset starts from zero, and is an integer offset xx00 0x002 length comments Comment Dictionary. A packed character array of comments. Each comment is a NULL terminated byte string. The offset from the start of the comments data is used in the referenced COMMENT field to locate the start of the string. length is the length of the whole of the dictionary in bytes. The following shows an example of a referenced comment for two comment strings "Hello World" and "Some kind of comment I guess", the first character of each string is highlighted in bold, the count for the sections are under-lined:- 0x00 01 04 00 00 00 00 0x00 01 04 0f 00 00 00 ... 0x00 02 2a 48 65 6c 6c 6f 20 57 6f 72 6c 64 00 53 0x6f 6d 65 20 6b 69 6e 64 20 6f 66 20 63 6f 6d 6d 0x65 6e 74 20 49 20 67 75 65 73 73 2e 00 ** ** ** Note little endian offset. ..-Hello World.S ome kind of comm ent I guess..*** 3.3. Header Section The header section is the first section to appear in a BIZ file following the Magic number. xx00 0x003 length HEADER. Start of the header section. 0x2002 0x02 0xmm 0xnn VERSION. Version Number. mm=major. nn=minor. Default=BIZ reader version. 0x2003 0x03 0xdd 0xmm 0xyy DATE. Date file written. dd=day[0..31], mm=month[0..11], yy=year[0..99] Default = current date. 0x2004 0x02 0xhh 0xmm TIME. Time file written. hh=hour[0..23], mm=minute[0..59]. Default = current time. 0x2005 0x04 float32 SCALE. Scale of geometry, a ratio to the GB inch. Floating point value. Default = 1.0; 0x2006 0x01 0xpp PRECISION. Floating point precision of BIZ file. The precision field pp is defined as:- 0x00 single precision. Float is 32 bits. 0x01 double precision. Float is 64 bits. 0x2007 0x01 0xpp FILETYPE. File contents type. The file type field pp is defined as:- 0x00 GEOMETRY (Default). 0x01 MATERIAL 0x02 TEXTURE 0x2009 0x01 0xpp UNIT. Base unit of measurement. The unit field pp is defined as:- 0x00 INCH (Default). 0x01 MM xx00 0x004 length String COMMENT. Propagated BIZ file comment. The comment string String is a NULL terminated byte stream. The length field is the length of the string including the NULL terminator. The size of the length field is determined by the control byte. 3.4. Trailer Section The trailer section is an artificial end of file marking the end of the geometry information, informing the BIZ reader that no more geometric information can be extracted from the file. Data structures such as the Comment Dictionary should follow the trailer section as it contains no geometric information. This allows the file readers to minimise the data transfer at run-time, whilst still retaining comment information and alike. File converters always read to the EOF marker to extract all of the information in the file. The trailer marker is defined as follows:- 0x0005 0x00 TRAILER. Mark end of geometric data. 3.5. Texture Section The texture section may appear anywhere in the BIZ file (at the main scope) and is defined as follows:- xx00 0x010 length TEXTURE. Start of the texture section. 0x2008 0xnn String NAME. Texture Name. Null terminated ASCII string of length nn. 0x200a 0x01 0xss SCOPE. Scope of the definition. The ss field denotes the scope of the material as follows:- 0x00 Global scope [Default when omitted]. 0x01 Local scope. xx00 0x01 1 length String MAP. Texture file to map. Null terminated ASCII string defining the name of the texture file to load (.vtx file). length is the length of the string. 0x0012 0x01 Mode MINIFY. Minify Mode Number The Mode is defined as follows:- 0x00 Undefined. 0x01 Point Sampled. 0x02 Bilinear. 0x03 Trilinear. 0x04 MipMapLinear. 0x05 MipMapBilinear. 0x06 MipMapTrilinear. 0x07 MipMapQuadLinear. 0x08 MipMapPointSampled. 0x0013 0x01 Mode MAGNIFY. Magnify Mode Number. The Mode is defined as follows:- 0x00 Undefined. 0x01 Point Sampled. 0x02 Bilinear. 0x03 Trilinear. 0x04 Bicubic. 0x05 Sharpen. 0x0014 0x01 Mode ALPHA. Alpha Mode Number. The Mode is defined as follows:- 0x00 Blend. 0x01 Cut. 0x02 BlendCut. 0x0015 0x01 Mode WRAP_U. Wrap U Mode Number. The WRAP field in a VIZ file maps onto WRAP_U and WRAP_V in the BIZ file. The Mode is defined as follows:- 0x00 Repeat. 0x01 Clamp. 0x02 Select. 0x0016 0x01 Mode WRAP_V. Wrap V Mode Number. The WRAP field in a VIZ file maps onto WRAP_U and WRAP_V in the BIZ file. The Mode is defined as follows:- 0x00 Repeat. 0x01 Clamp. 0x02 Select. xx00 0x01 7 0xnn type String DETAIL. The type is defined as:- 0x00 Disabled (Default). 0x01 Add 0x02 Modulate String is a NULL terminated string of the name of the file to load. The nn denotes the length of the field, which is the length of the String + 1. 3.6. Material Section The material section may appear anywhere in the BIZ file (at the main scope) and is defined as follows:- xx00 0x020 length MATERIAL. Start of a material section. 0x2008 0xnn String NAME. Material Name. Null terminated ASCII string of length 0xnn. 0x200a 0x01 0xss SCOPE. Scope of the definition. The ss field denotes the scope of the material as follows:- 0x00 Global scope [Default when omitted]. 0x01 Local scope. 0x0021 0xnn type String TEXTURE. Texture type field. The nn field is the length of the field. The type denotes the texture type as follows:- 0x00 None. 0x01 Default. 0x02 Name of texture defined in String. The String field is a NULL terminated string with the name of the texture associated with the material. This is the renderer name of the texture as defined in the Texture Section. The string length is defined as 0xnn -1 bytes including the NULL terminator. The string field is only present if the type is the name of the texture. 0x0022 0xnn type String ENVIRONMENT. Environment type field. The nn field is the length of the field. The type denotes the texture type as follows:- 0x00 None. 0x01 Default. 0x02 Name of environment texture defined in String. The String field is a NULL terminated string with the name of the texture associated with the material. This is the renderer name of the texture as defined in the Texture Section. The string length is defined as 0xnn -1 bytes including the NULL terminator. The string field is only present if the type is the name of the environment texture. 0x0023 0xnn red green blue AMBIENT. Ambient Colour. The red, green, and blue fields are precision floats that define the ambient colour of the surface of the material. Values are in the range 0.0 to 1.0. 0x0024 0xnn red green blue DIFFUSE. Diffuse colour. The red, green and blue fields are precision floats that define the diffuse colour of the surface of the material. Values are in the range 0.0 to 1.0. 0x0025 0xnn red green blue power SPECULAR. Specular Colour. The red, green and blue fields are precision floats that define the specular colour of the surface of the material; values are in the range 0.0 to 1.0. The power field defines power. Values are in the range 1.0 to 128.0 0x0026 0xnn red green blue EMISSIVE. Emissive Colour. The red, green and blue fields are precision floats that define the emissive colour of the surface. Values are in the range 0.0 to 1.0. 0x0027 0xnn red green blue OPACITY. Transparency of object. The red, green and blue fields are precision floats that define the transparent colour of the surface. Values are in the range 0.0 to 1.0, default is 1.0, 1.0, 1.0 0x0028 0xnn String RAMP. The Ramp to use. String is a NULL terminated string of length 0xnn specifying the RAMP section to use. 3.7. Ramp Section The ramp section may appear anywhere in the BIZ file (at the main scope) and is defined as follows:- xx00 0x030 length RAMP. Start of a ramp section. 0x2008 0xnn String NAME. Ramp Name. Null terminated ASCII string of length 0xnn. 0x200a 0x01 0xss SCOPE. Scope of the definition. The ss field denotes the scope of the material as follows:- 0x00 Global scope [Default when omitted]. 0x01 Local scope. 0x0031 ll r0 g0 b0 r1 g1 b1 DATA. pair of colours associated with ramp. ll denotes the length of the block, the colours are precision size floating point values. 3.8. Object Section The object section may appear anywhere in the BIZ file and is defined as follows:- xx00 0x040 length OBJECT. Start of a object section. Fields defined in the Surface Variables section. All fields apply. 3.9. Surface Variables The surface variables define the surface characteristics of an OBJECT or a PATCH. The fields are defined as follows:- 0x2008 0xnn String NAME. Nome of the object/patch. String is a NULL terminated ASCII string of length 0xnn. 0x2030 0xnn type String F_MATERIAL. Front Material. The type field denotes the front material status as follows:- 0x00 NONE 0x01 material name. 0x02 DEFAULT The String field is the NULL terminated ASCII name of the material to be applied to the front faces. The String field is only present if the type field defines a material name. 0x2031 0xnn type String B_MATERIAL. Back Material. The type field denotes the front material status as follows:- 0x00 NONE 0x01 material name. 0x02 DEFAULT 0x03 F_MATERIAL The String field is the NULL terminated ASCII name of the material to be applied to the front faces. The String field is only present if the type field defines a material name (0x01). 0x2032 0x01 Plane PLANE. The rendering plane. The value of Plane is defined as follows:- 0x00 NORMAL 0x01 UNDERLAY 0x02 OVERLAY 0x2033 0x02 mode, width DRAWMODE. The drawing mode. The value of mode is defined as follows:- 0x00 FILLED 0x01 WIREFRAME 0x02 DOTTED The width field is only valid with wireframe and dotted modes. This is an unsigned 8-bit integer, zero denotes default width. The width field is ignored if the mode if FILLED. 0x2034 0x04 distance DECAL. Order coplanar faces. The distance parameter is a signed 32-bit integer specifying an offset to be added to the Z-buffer depth. 0x2035 0x01 Faceted FACETED. The facet mode. The value of Faceted is defined as follows:- 0x00 NONE 0x01 BACKFACE 0x02 FRONTFACE 0x03 TWOFACED 0x2036 0x01 Format VERTEX. The format of the vertices. Format is defined as a bit mask follows:- 0x00 NONE 0x01 NORMALS 0x02 RGB 0x04 LUMINANCE 0x08 2D_TEXTURE 0x10 3D_TEXTURE 0x2037 0xnn String SPECIAL. Special command to the renderer. String is interpreted as a raw stream of bytes of length 0xnn. Note that \0 may be interpreted as a valid byte in the string. 0x2039 0x01 State LOCK. Locking of material properties. State is the value of the a value of 0 (OFF) defines the lock state as inactive; a value of 1 (ON) enables the lock which prohibits run-time material changes. 3.10. Level of Detail (LOD) Section The LOD section may appear within an OBJECT and is defined as follows:- xx00 0x041 length LOD. Level of detail section. 0x2008 0xnn String NAME. Name of the LOD. String is a NULL terminated ASCII string of length 0xnn. 0x2046 0xnn in out DISTANCE. Switching distance for LOD. in and out are defined as floating point precision values, defining the near and far switching distances for the LOD. out <= 0 denotes infinity. 0x2047 0xnn x y z REFERENCE. The reference point. A standard x,y,z vector defining a point in space; defined using precision floating point values. If the reference point is omitted the centre of the geometry is assumed. 0x2048 0xn01 mode TRANSITION. The transition for the LOD. The value of mode is defined as follows:- 0x00 SNAP 0x01 BLEND 3.11. Patch Section xx00 0x042 length PATCH. Start of a patch section. Fields defined in the Surface Variables section. All fields apply. 3.12. Polygon Section Polygon sections appears within a PATCH and are defined as follows:- xx00 0x043 length POLYGON. Polygon section. Vertex List Section 0x080-0x09f {x,y,z,....}. Vertex List. Defines a 'n' faceted closed planer polygon v0,v1,v2,..,vn-1. 3.13. Tristrip Section Tristrip sections appears within a PATCH and are defined as follows:- xx00 0x044 length TRISTRIP. Start of a tristrip definition. Vertex List Section 0x080-0x09f {x,y,z,....}. Vertex List. 3.14. Polystrip Section Polystrip sections appears within a PATCH and are defined as follows:- xx00 0x045 length POLYSTRIP. Start of a polystip definition. Vertex List Section 0x080-0x09f {x,y,z,....}. Vertex List. 3.15. Pmesh Section Pmesh sections appears within a PATCH and are defined as follows:- xx00 0x046 length PMESH. Start of a pmesh definition. Vertex List Section 0x080-0x09f VERTEX_POOL {x,y,z,....}. Vertex List. xx00 0x047 length index CONNECTION_LIST. Connectivity of vertex list. index is a list of 32 bit index values into the VERTEX_POOL definition. The index value is in the range 0..NoVerticies - 1 Contains length/4 vertex points; length/(4*3) defines the number of triangle polygons. xx00 0x04d length count index CONNECTION_LIST (PCOUNT=count). Defines a connectivity of count faceted polygons all of which are planer. count defines the number of vertices (edges) of the polygon. index is a list of 32 bit index values into the VERTEX_POOL definition. The index value is in the range 0..NoVerticies - 1 Note: the 0x047 tag identity was the original CONNECTION_LIST identifier which expected triangular (3 vertex) connected edge definitions. Tag 0x04d has been introduced to allow ænÆ edged planer polygons to be defined, this corresponds to the PCOUNT field specifier of the CONNECTION_LIST in the VIZ file. Either tag type is currently supported by the BIZ format although the 0x04d tag should be used in preference when defining triangular polygons. 3.16. Sphere Section Sphere sections appears within a PATCH and are defined as follows:- xx00 0x048 length SPHERELIST. Sphere section. 0x2040 0x02 Vert_div DICE_V. Vertical division. The number of divisions to make in the sphere in the vertical axis. Vert_div is a 16 bit unsigned integer. 0x2041 0x02 Horiz_div DICE_U. Horizontal division. The number of divisions to make in the sphere in the horizontal axis. Horiz_div is a 16 bit unsigned integer. 0x0049 0xnn x y z radius {x,y,z,radius}. Define a single instance of sphere. x, y and z define the position in space of a sphere with a radius radius. These are floating point values with a length defined by the precision of the BIZ file. 3.17. Line Section Line sections appears within a PATCH and are defined as follows:- xx00 0x04a length LINE. Line section 0x2042 0x01 Thickness THICKNESS. The thickness of a line. The Thickness parameter defines the thickness of the line in pixels. This is an unsigned 8 bit integer in the range 1..255; 0 uses the default value of 1. 0x0080 0xnn x y z {x,y,z}. Vertex of line. The parameters x, y and z define a vertex point in space; the parameter lengths are defined by the precision field value. A minimum of 2 entries must exist in the statement to form a line. A line is drawn be each of the vertices specified. An object with 4 specified vertices results in 3 lines v1v2, v2v3 and v3v4. 3.18. Text Section Text sections appears within a PATCH and are defined as follows:- xx00 0x04b length TEXT. Start of a text definition. 0x2043 0x01 font FONT. The text font to use. The fonts supported are defined by font as follows:- 0x00 QUICK [default] 0x01 BITMAP 0x02 VECTOR 0x03 POLYGONAL_2D 0x04 POLYGONAL_3D 0x05 TEXTURE 0x2044 0xnn sx sy sz SCALE. The scale of the text. The scale parameters define the x (sx), y (sy) and z (sz) axes and are defined by the precision of the file. 0x2045 0xnn ox oy oz ORIENTATION. The orientation of the text. The orientation parameters define the roll (ox), yaw (oy) and pitch (oz) in radians. The field sizes are defined by the precision of the file. 0x004c 0xnn x y z string {x,y,z,"string"}. A positional text string. The position of the text string is defined by the values x, y and z; these are precision floating point values. The string parameter is a NULL terminated text string containing the text information to be displayed. \n next line and (or \t) 8 character boundary are valid in the string. 3.19. Vertex List Section The Vertex List is utilised from various sections and in defined in the following tables. The vertex list utilises the following bit allocation to specify the field types (Figure 10). The bit allocation is the same as the VERTEX field in the Surface Variables section of the VIZ format. Figure 10 Vertex List command break down The valid Vertex List field definitions are defined in the following tables; those values that are omitted are not supported. xx00 0x080 length {x,y,z} Vertex List. Contains length/(precision size * 3) vertex points. x y z The x, y and z position in space. xx00 0x081 length {x,y,z,Nx,Ny,Nz} Vertex List : normals. Contains length/(precision size * 6) vertex points. x y z Nx Ny Nz The x, y and z position in space, with associated normals Nx, Ny and Nz. All values are precision floating point numbers. xx00 0x082 length {x,y,z,r,g,b,a} Vertex List : colours. Contains length/(precision size * 7) vertex points. x y z r g b a The x, y and z position in space, with associated colour values of r (red), g (green), b (blue) and a (alpha) transparency. All values are precision floating point numbers; r,g,b,a are in the range 0.0 to 1.0. xx00 0x083 length {x,y,z,Nx,Ny,Nz,r,g,b,a} Vertex List : normals : colours. Contains length/(precision size * 10) vertex points. x y z Nx Ny Nz r g b a The x, y and z position in space, with associated normals Nx, Ny and Nz and colours rgba. All values are precision floating point numbers. xx00 0x084 length {x,y,z,l,a} Vertex List : Luminance. Contains length/(precision size * 5) vertex points. x y z l a The x, y and z position in space, with associated luminance la. All values are precision floating point numbers. xx00 0x085 length {x,y,z,Nx,Ny,Nz,l,a} Vertex List : normals : luminance. Contains length/(precision size * 8) vertex points. x y z Nx Ny Nz l a The x, y and z position in space, with associated normals Nx, Ny and Nz and luminance la. All values are precision floating point numbers. xx00 0x088 length {x,y,z,u,v} Vertex List : 2D texture. Contains length/(precision size * 5) vertex points. x y z u v The x, y and z position in space and 2D texture mappings u and v. All values are precision floating point numbers. xx00 0x089 length {x,y,z,Nx,Ny,Nz,u,v} Vertex List : 2D texture : normals. Contains length/(precision size * 8) vertex points. x y z Nx Ny Nz u v The x, y and z position in space, with associated normals Nx, Ny and Nz and 2D texture mappings u and v. All values are precision floating point numbers. xx00 0x08a length {x,y,z,r,g,b,a,u,v} Vertex List : 2D texture : colours. Contains length/(precision size * 9) vertex points. x y z r g b a u v The x, y and z position in space, with colour information rgba and 2D texture mappings u and v. All values are precision floating point numbers. xx00 0x08c length {x,y,z,l,a,u,v} Vertex List : 2D texture : luminance. Contains length/(precision size * 7) vertex points. x y z l a u v The x, y and z position in space, with luminance information la and 2D texture mappings u and v. All values are precision floating point numbers. xx00 0x090 length {x,y,z,u,v,w} Vertex List : 3D texture. Contains length/(precision size * 6) vertex points. x y z u v w The x, y and z position in space and 3D texture mappings u, v and w. All values are precision floating point numbers. xx00 0x091 length {x,y,z,Nx,Ny,Nz,u,v} Vertex List : 3D texture : normals. Contains length/(precision size * 9) vertex points. x y z Nx Ny Nz u v w The x, y and z position in space, with associated normals Nx, Ny and Nz and 3D texture mappings u, v and w. All values are precision floating point numbers. xx00 0x092 length {x,y,z,r,g,b,a,u,v,w} Vertex List : 3D texture : Colours. Contains length/(precision size * 10) vertex points. x y z r g b a u v w The x, y and z position in space, with colour information rgba and 3D texture mappings u, v and w. All values are precision floating point numbers. xx00 0x094 length {x,y,z,l,a,u,v,w} Vertex List : 3D texture : luminance. Contains length/(precision size * 8) vertex points. x y z l a u v w The x, y and z position in space, with luminance information la and 3D texture mappings u, v and w. All values are precision floating point numbers. 4. VTX File Format This chapter describes the texture file format. This is a binary only file format defined to hold texture definitions. 4.1. Header, Trailer and Comment Sections The header section is the first section to appear in a VTX file following the Magic number. The file header is the same format as a BIZ file; the FILETYPE field is defined as 0x02. The PRECISION field has no defined value within a texture file. The trailer section and all comment fields of the VTX file format are the same the BIZ file format, the context of these fields is the same. 4.2. Magic Number The magic number occupies the first 8 bytes of the texture file and is defined to be the ASCII string "DIV-VTX2". 4.3. Field Ordering The VTX file comprises the following information:- vtx_file:: Magic Number header_section texture_section { pixel_data } The file is assumed to be little endian. 4.4. Texture Map Section This section defines the texture map in terms of the individual texels that build up the map. The Texture Map section immediately follows the header block, only one texture map section may exist in a file. xx00 0x060 length 2D Texture Map. Start of the texture map section. 0x2060 0x01 type TYPE. Type of texture file. The type is denoted by the value of type as follows, this is a bit field:- 0x01 alpha present. 0x02 3 colour components (rgb). Example settings:- 0x01 luminance and alpha. 0x03 RGB colour components and alpha. (Default). 0x2061 0x01 width WIDTH. Width of the texture values. The width field width is defined as:- 0x01 8-bit texture values. (Default). 0x2062 0x08 u v SIZE. Size of the texture. Defines the size of the texture in pixels. u and v denote the dimensions as a 32 bit integer values. xx00 0x06x length texture TEXEL. Pixel description. 4.5. Pixel Data The textures are defined in terms of a colour and alpha value denoting opacity. The colour and alpha fields are valid are unsigned integer values occupying WIDTH bits. The field values are defined as follows:- Colour Values [l|rgb] 0 is black, 2WIDTH-1 white Opacity Values [e|a] 0 is transparent, 2WIDTH-1 opaque. The data contained within the block is determined by the Texture map section which defines the dimensions of the texture map. The data is read as a byte stream and is row (u) ordered. xx00 0x068 length {l} Pixel Description. Contains length/(precision size * 1) data points. l The luminance level value, no alpha. xx00 0x069 length {l,a} Pixel Description. Contains length/(precision size * 2) data points. l, a The luminance level value and associated alpha value a. xx00 0x06a length {r,g,b,a} Pixel Description. Contains length/(precision size * 3) vertex points. r, g, b Texture in terms of the colour components r (red), g (green) and b (blue) . xx00 0x06b length {r,g,b,a} Pixel Description. Contains length/(precision size * 4) vertex points. r, g, b, a Texture in terms of the colour components r (red), g (green) and b (blue) and a transparency component a (alpha). 5. References The following list are references to other related manuals and documents. 1. dVISE User Guide Division Ltd. Product No: DM0670 Version 1.3 2. VIZ Tools Technical Reference Division Ltd Product No: DM0622 Version 1.8 6. Index B BIZ, 3-1 C Capability, 2-4 Comment, 3-3 Comments, 2-3 CONNECTION_LIST, 2-19 Cylinder, 7-13, 7-14 F File Layout, 2-5 H Header, 2-5, 3-1, 3-4, 4-1, 4-2 K Keyword Format, 2-4 L Line, 2-20, 3-11 LOD, 2-17, 3-9 M magic number, 3-1 Material, 2-10, 3-6 N Names, 2-3 O Object, 1-1, 2-11, 3-8 P Patch, 2-12, 3-10 Pmesh, 2-19, 3-10 Polygon, 2-21, 3-10 Polystrip, 2-18 R Ramp, 2-9, 3-7 S section header, 3-2 Specifier List, 2-4 Sphere, 3-11 Spherelist, 2-20 Strings, 2-3 Surface Variables, 2-12 Surface Variables, 3-8 T Text, 2-20, 3-11 Texture, 2-6, 3-5 Tristrip, 2-18, 3-10 V Vertex, 2-15 Vertex List, 3-12 VERTEX_POOL, 2-19 VIZ, 2-1, 7-5 A - Configuration Header Identity Words The following table lists the configuration header identity words currently assigned. Block Identity File Type Appears in Description of block 0x000 All Any Field In-line Comment Field. 0x001 All Any Field Referenced Comment field. 0x002 All Header Version Number of BIZ file. 0x003 All Header Date BIZ file written. 0x004 All Header Time BIZ file written. 0x005 All Header Scale of the model. 0x006 All Header Floating point precision. 0x007 All Header File type. 0x008 .b2z Texture/Material/Ramp /Object/Patch Internal name assigned to structure. 0x009 .All Header Unit of measurement. 0x00a .b2z Texture/Material/Ramp Scope of the block. 0x030 .b2z Object/Patch Material assigned to the front faces. 0x031 .b2z Object/Patch Material assigned to the back faces. 0x032 .b2z Object/Patch The rendering plane. 0x033 .b2z Object/Patch Draw mode. 0x034 .b2z Object/Patch Decal 0x035 .b2z Object/Patch Faceted mode. 0x036 .b2z Object/Patch Format of the vertices. 0x037 .b2z Object/Patch Special rendering information 0x038 .b2z Object/Patch Material type 0x039 .b2z Object/Patch Material Lock 0x040 .b2z Sphere Vertical dice value. 0x041 .b2z Sphere Horizontal dice value. 0x042 .b2z Line Thickness of the line. 0x043 .b2z Text Type of Font. 0x044 .b2z Text Scale of the Font. 0x045 .b2z Text Orientation of the Font 0x046 .b2z LOD Switching distances. 0x047 .b2z LOD Geometry reference point. 0x048 .b2z LOD Switching transition. 0x060 .vtx Texture Map Type of texture. 0x061 .vtx Texture Map Width of the texel values in bits. 0x062 .vtx Texture Map Dimensions of the texture map. B - Header Identity Words The following table lists the header identity words currently assigned. Block Identity File Type Appears in Description of block 0x000 All Any Field In-line Comment field. 0x001 All Any Field Referenced Comment field. 0x002 All Main Comment Dictionary section. 0x003 All Main Header section. 0x004 All Header Propagated comment. 0x005 All Main Trailer section. 0x010 All Main Texture section. 0x011 .b2z Texture Map, Texture file to load. 0x012 .b2z Texture Minify mode number. 0x013 .b2z Texture Magnify mode number. 0x014 .b2z Texture Alpha mode number. 0x015 .b2z Texture Wrap U mode number. 0x016 .b2z Texture Wrap V mode number 0x017 .b2z Texture Detail 0x020 .b2z Main Material section. 0x021 .b2z Material Texture type. 0x022 .b2z Material Environment. 0x023 .b2z Material Ambient colour. 0x024 .b2z Material Diffuse colour. 0x025 .b2z Material Specular colour. 0x026 .b2z Material Emissive colour. 0x027 .b2z Material Opacity. 0x028 .b2z Material Ramp 0x030 .b2z Main Ramp section. 0x031 .b2z Ramp Ramp data. 0x040 .b2z Main Object section. 0x041 .b2z Object LOD section 0x042 .b2z Object/LOD Patch section. 0x043 .b2z Patch Polygon section. 0x044 .b2z Patch Tristrip section. 0x045 .b2z Patch Polystrip section. 0x046 .b2z Patch Pmesh section. 0x047 .b2z Pmesh Connection list (triangular polygons). 0x048 .b2z Patch Sphere section. 0x049 .b2z Sphere Sphere definition. 0x04a .b2z Patch Line section. 0x04b .b2z Patch Text section. 0x04c .b2z Text Text string. 0x04d .b2z Pmesh Connection list (ænÆ sided planer polygons) 0x060 .vtx Main 2D texture map section. 0x068 .vtx Texture Map Grey level texture, no alpha. 0x069 .vtx Texture Map Grey level texture with alpha. 0x06a .vtx Texture Map RGB texture, no alpha. 0x06b .vtx Texture Map RGB texture with alpha. 0x08x 0x09x .b2z Tri/Polystrip/Pmesh Vertex list (x,y,z[[,Nx,Ny,Nz][[,r,g,b,a][,l,a]]][,u,v[,w]]). C - Table of defaults The following table lists the defaults and field types assigned:- VIZ Name BIZ Tag Default Value Field Type Range / Notes HEADER 0x0003 - - One header only. VERSION 0x2002 Reader Version uint8[2] 2-9: 0-255 DATE 0x2003 Current Date uint8[3] 1-31;1-12;0-99 TIME 0x2004 Current Time uint8[2] 0:23;1-59 SCALE 0x2005 1.0 float32 No limits PRECISION 0x2006 SINGLE Preset Preset range. FILETYPE 0x2007 GEOMETRY Preset Preset range. UNIT 0x2009 INCH Preset Preset range. COMMENT 0x0004 string Null terminated string. TEXTURE 0x0010 NAME 0x2008 NULL string Null terminated string. SCOPE 0x200a 0 uint8 0-1 MAP 0x0011 NULL string Null terminated string. MINIFY 0x0012 0 Preset Preset range. MAGNIFY 0x0013 0 Preset Preset range. ALPHA 0x0014 BLEND Preset Preset range. WRAP Maps to WRAP_U/V WRAP_U 0x0015 REPEAT Preset Preset range. WRAP_V 0x0016 REPEAT Preset Preset range. DETAIL 0x0017 0, NULL Preset, string Preset range, \0 RAMP 0x0030 NAME 0x2008 NULL string Null terminated string. SCOPE 0x200a 0 uint8 0-1 DATA 0x0031 No defaults. floatp[6] 0.0 - 1.0 MATERIAL 0x0020 NAME 0x2008 NULL string Null terminated string. SCOPE 0x200a 0 uint8 0-1 TEXTURE 0x0021 NULL string Null terminated string. ENVIRONMENT 0x0022 NULL string Null terminated string. AMBIENT 0x0023 1.0,1.0,1.0 floatp[3] 0.0 - 1.0 DIFFUSE 0x0024 1.0, 1.0, 1.0 floatp[3] 0.0 - 1.0 SPECULAR 0x0025 0.0, 0.0, 0.0, 1.0 floatp[4] 0.0 - 1.0; 1.0 - 128.0 EMISSIVE 0x0026 0.0, 0.0, 0.0 floatp[3] 0.0 - 1.0 OPACITY 0x0027 1.0, 1.0, 1.0 floatp[3] 0.0 - 1.0 RAMP 0x0028 NULL string Null terminated string. OBJECT 0x0040 NAME 0x2008 NULL string Null terminated string. F_MATERIAL 0x2030 NONE Preset, string Preset range. B_MATERIAL 0x2031 NONE Preset, string Preset range. PLANE 0x2032 NORMAL Preset Preset range. DRAWMODE 0x2033 FILLED, 1 Preset, uint8 Preset range. 1-255 DECAL 0x2034 0 int32 No limit FACETED 0x2035 NONE preset Preset range. VERTEX 0x2036 NONE preset Preset range. SPECIAL 0x2037 No defaults. string length string LOCK 0x2039 OFF. uint8 0 - 1 LOD 0x0041 NAME 0x2008 NULL string Null terminated string. DISTANCE 0x2046 0.0, -1 floatp[2] 0.0 - * REFERENCE 0x2047 Centre of geometry floatp[3] No limits TRANSITION 0x2048 SNAP preset Preset range. PATCH 0x0042 No defaults. POLYGON 0x0043 No defaults. vertex[n] Min of 3 vertices defined. TRISTRIP 0x0044 No defaults. vertex[n] Min of 3 vertices defined. POLYSTRIP 0x0045 No defaults. vertex[n] Min of 3 vertices defined. PMESH 0x0046 No defaults. VERTEX_POOL No defaults. Defined as vertex list. CONNECTION_ LIST 0x0047 No defaults. int32[3][n] 0..NoVerticies-1 CONNECTION_ LIST 0x004d 3, No defaults. unit8, int32[m][n] 3..255, 0..NoVerticies-1 SPHERELIST 0x0048 No defaults. DICE_V 0x2040 0 uint16 0,3..65565 DICE_U 0x2041 0 uint16 0, 3..65565 xyzr 0x0049 No defaults. floatp[4][n] LINE 0x004a No defaults. THICKNESS 0x2042 1 uint8 0..255 TEXT 0x004b No defaults. FONT 0x2043 QUICK preset Preset range. SCALE 0x2044 1.0, 1.0, 1.0 floatp[3] Not 0.0 in any position. ORIENTATION 0x2045 0.0, 0.0, 0.0 floatp[3] 0.0..2* xyz string 0x004c No defaults floatp[3], char[n] Null terminated string xyz 0x0080 No defaults floatp[3][n] xyzNxNyNz 0x0081 No defaults floatp[6][n] xyzla 0x0084 No defaults floatp[5][n] xyzrgba 0x0082 No defaults floatp[7][n] xyzuv 0x0088 No defaults floatp[5][n] xyzNxNyNzuv 0x0089 No defaults floatp[8][n] xyzlauv 0x008c No defaults floatp[7][n] xyzrgbauv 0x008a No defaults floatp[9][n] xyzuvw 0x0090 No defaults floatp[6][n] xyzNxNyNzuvw 0x0091 No defaults floatp[6][n] xyzlauvw 0x0094 No defaults floatp[8][n] xyzrgbuvw 0x0092 No defaults floatp[10][n] /* Comment */ 0x0000 0x2000 In-line comment. /* Comment */ 0x0001 0x2001 Referenced comment, BIZ optimisation construct. 0x0002 Comment Dictionary, BIZ optimisation construct. 0x0005 Trailer, BIZ optimisation construct. D - VIZ BNF File Syntax This section describes the syntax of the VIZ file format using a BNF like syntax definition, detailing the structure of the VIZ file and the parsing conventions of the file. A comment BNF specification has not been included, but is assumed as defined in the VIZ file specification. D.1 Notation Definition The syntax notation used in this document uses the following convention:- italic Syntactic categories. bold Literal words and characters. [ a | b ] Alternatives e.g. Either a or b. * Zero or more occurrences. + One or more occurrences. margin text Denote default values for the fields. D.2 File Definition viz_file:: magic_number [header] filespec header:: HEADER [(header_specifier_list)] {header_command_list } filespec:: geometry_filespec material_filespec magic_number:: DIV-VIZ2 material_filespec:: material_item material_item material_filespec material_item:: TEXTURE [(texture_specifier_list)] {texture_command_list} RAMP [(ramp_specifier_list)] {ramp_command_list} MATERIAL [(material_specifier_list)] {material_command_list} geometry_item:: OBJECT [(object_specifier_list)] {object_command_list} geometry_filespec:: primary_item primary_item geometry_filespec primary_item:: geometry_item material_item header_specifier_list:: header_specifier header_specifier; header_specifier_list header_specifier:: VERSION=major_No:minor_No DATE=date:month:year TIME=hour:minute 1.0 SCALE=float32 INCH UNIT=[INCH|MM] SINGLE PRECISION=[SINGLE|DOUBLE|QUAD] GEOMETRY FILETYPE=[GEOMETRY|MATERIAL|TEXTURE] header_command_list:: [header_command] header_command header_command_list header_command:: COMMENT { "string" } texture_specifier_list:: texture_specifier texture_specifier; texture_specifier_list texture_specifier:: NAME=alphanumeric GLOBAL SCOPE=[LOCAL|GLOBAL] texture_command_list:: [texture_command] texture_command texture_command_list texture_command:: MAP { "filename" } Platform Dependant MINIFY{[POINT_SAMPLED|BILINEAR|TRILINEAR|MIP_MAP_POINT_SAMPLED| MIP_MAP_LINEAR|MIP_MAP_BILINEAR|MIP_MAP_TRILINEAR| MIP_MAP_QUADLINEAR]} Platform Dependant MAGNIFY {[POINT_SAMPLED|BILINEAR|TRILINEAR|BICUBIC|SHARPEN]} Platform Dependant ALPHA {[BLEND|CUT|BLEND_CUT]} Platform Dependant WRAP {[REPEAT|CLAMP|SELECT]} Platform Dependant WRAP_U {[REPEAT|CLAMP|SELECT]} Platform Dependant WRAP_V {[REPEAT|CLAMP|SELECT]} NONE DETAIL {[ADD|MODULATE], "filename"} material_specifier_list:: material_specifier material_specifier; material_specifier_list material_specifier:: NAME=alphanumeric GLOBAL SCOPE=[LOCAL|GLOBAL] material_command_list:: [material_command] material_command material_command_list material_command:: NONE TEXTURE {[DEFAULT|NONE|texture_name} NONE ENVIRONMENT {[DEFAULT|NONE|texture_name } 1.0, 1.0, 1.0 AMBIENT { red, green , blue } 1.0, 1.0, 1.0 DIFFUSE { red, green , blue } 0.0, 0.0, 0.0 1.0 SPECULAR { red, green , blue , power } 0.0, 0.0, 0.0, EMISSIVE { red, green , blue } 1.0, 1.0, 1.0 OPACITY { red, green , blue } RAMP { ramp_name } ramp_specifier_list:: ramp_specifier ramp_specifier; ramp_specifier_list ramp_specifier:: NAME=alphanumeric GLOBAL SCOPE=[LOCAL|GLOBAL] ramp_command_list:: [ramp_command] ramp_command ramp_command_list ramp_command:: DATA{ red, green , blue , red, green , blue } object_specifier_list:: surface_variables surface_variables; object_specifier_list vertex_type:: [NONE|NORMALS|RGB|LUMINANCE|2D_TEXTURE|3D_TEXTURE] vertex_type_list:: vertex_type vertex_type , vertex_type_list surface_variables:: NAME=alphanumeric default material F_MATERIAL= [material_name|NONE|DEFAULT] default material B_MATERIAL=[material_name|NONE|F_MATERIAL|DEFAULT] NORMAL PLANE=[NORMAL|UNDERLAY|OVERLAY] NONE FACETED=[FRONTFACE|BACKFACE|TWOFACED|NONE] 0 DECAL=int32 FILLED DRAWMODE=[FILLED|WIREFRAME[,width]|DOTTED[,width]] NONE VERTEX= NULL SPECIAL="String" OFF LOCK=[ON|OFF] object_command_list:: [object_command] object_command object_command_list object_command:: [ patch_statements | lod_statements ] lod_statements:: lod_definition lod_definition lod_statements lod_definition:: LOD [(lod_specifier_list)] { lod_command_list } lod_specifier_list:: lod_specifier lod_specifier ; lod_specifier_list lod_specifier:: 0,-1 DISTANCE=float,float SNAP TRANSITION=[BLEND|SNAP] 0,0,0 REFERENCE=float,float,float lod_command_list:: lod_command lod_command ; lod_command_list lod_command:: patch_statements patch_statements:: patch_definition patch_definition patch_statements patch_statements:: PATCH [(patch_specifier_list)] {patch_command_list} patch_specifier_list:: surface_variables surface_variables patch_specifier_list patch_command_list:: patch_command patch_command patch_command_list patch_command:: TRISTRIP [(undefined)] {vertex_list} POLYSTRIP [(undefined)] {vertex_list} PMESH [(undefined)] {pmesh_command_list} SPHERE [(sphere_specifier_list)] {sphere_command_list} LINE [(line_specifier_list)] {line_command_list} TEXT [(text_specifier_list)] {text_command_list} POLYGON [(undefined)] {polygon_command_list} vertex_list:: [ {x, y, z} | {x, y, z, l, a} | {x, y, z, r, g, b, a} | {x, y, z, Nx, Ny, Nz} | {x, y, z, Nx, Ny, Nz, u, v} | {x, y, z, Nx, Ny, Nz, u, v, w} | {x, y, z, l, a, u, v} | {x, y, z, r, g, b, a, u, v} | {x, y, z, l, a, u, v, w} | {x, y, z, r, g, b, a, u, v, w} ]+ pmesh_command_list:: VERTEX_POOL {vertex_list} connection_list+ connection_list:: CONNECTION_LIST [(connection_specifier_list)]{index*} connection_specifier_list:: 3 PCOUNT=uint8 sphere_specifier_list:: sphere_specifier spere_specifier ; sphere_specifier_list sphere_specifier:: DICE_U=int DICE_V=int sphere_command_list:: {x, y, z, radius}* line_specifier_list:: line_specifier line_specifier ; line_specifier_list line_specifier:: THICKNESS=uint8 text_specifier_list:: text_specifier text_specifier ; text_specifier_list text_specifier:: QUICK FONT=[QUICK|BITMAP|VECTOR|POLYGONAL_2D|POLYGONAL_3D|TEXTURE] 1.0, 1.0, 1.0 SCALE=sx,sy,sz 0.0, 0.0, 0.0 ORIENTATION=ox,oy,oz text_command_list:: STRING {x, y, z, "string"} polygon_command_list:: vertex_list undefined_specifier_list:: NULL NULL ; undefined_specifier_list E Example VIZ File The following examples show a pseudo VIZ file for both the material and geometry file types. All of the fields have been defined, emphasising the layout of the files. E.1 Material File DIV-VIZ2 /* Magic number appears at the top */ HEADER (VERSION=2:1; /* Version number of file format */ DATE=dd:mm:yy; /* Date file was written */ TIME=hh:mm; /* Time file was written */ SCALE=12.0; /* Scaling factor to GB feet. */ UNIT=INCH; /* Dealing in imperial measurements */ PRECISION=SINGLE; /* Numbering precision. */ FILETYPE=MATERIAL) /* File data type. */ { COMMENT {"Some kind of comment I guess"} /* A comment capability */ } TEXTURE (NAME=londonbrick) { /* The name of the texture. */ MAP {"lonbrick"} /* The name of the texture file. */ MINIFY {TRILINEAR} MAGNIFY {POINT_SAMPLED} ALPHA {BLEND} WRAP {CLAMP} DETAIL {MODULATE, "lonsurface"} } RAMP (NAME=sky) /* The name of the ramp. */ { DATA {r,g,b,r,g,b} } MATERIAL (NAME=redbrick) /* Name of the material */ { TEXTURE {londonbrick} /* Texturing mode. */ AMBIENT {r,g,b} /* Ambient colour */ DIFFUSE {r,g,b} SPECULAR {r,g,b,p} EMISSIVE {r,g,b} OPACITY {r,g,b} } MATERIAL (NAME=bluebrick) /* Name of the material */ { TEXTURE {londonbrick} /* Texturing mode. */ AMBIENT {r,g,b} /* Ambient colour */ DIFFUSE {r,g,b} SPECULAR {r,g,b,p} EMISSIVE {r,g,b} OPACITY {r,g,b} } /* End of material file */ E.2 Geometry File DIV-VIZ2 /* Magic number appears at the top */ /* * Header field */ HEADER (VERSION=2:1; /* Version number of file format */ DATE=dd:mm:yy; /* Date file was written */ TIME=hh:mm; /* Time file was written */ SCALE=12.0; /* Scaling factor to GB feet. */ UNIT=INCH; /* Working in inches */ PRECISION=SINGLE; /* Numbering precision. */ FILETYPE=GEOMETRY) /* File data type. */ { COMMENT {"Some kind of comment I guess\n" "concatenate onto next line"} /* A comment capability */ } /* * Geometry files may include their own materials */ TEXTURE (NAME=londonbrick) { /* The name of the texture. */ MAP {"lonbrick"} /* The name of the texture file. */ MINIFY {TRILINEAR} MAGNIFY {POINT_SAMPLED} ALPHA {BLEND} WRAP {CLAMP} DETAIL {MODULATE, "lonsurface"} } RAMP (NAME=sky) /* The name of the ramp. */ { DATA {r,g,b,r,g,b} } MATERIAL (NAME=redbrick) /* Name of the material */ { TEXTURE {londonbrick} /* Texturing mode. */ AMBIENT {r,g,b} /* Ambient colour */ DIFFUSE {r,g,b} SPECULAR {r,g,b,p} EMISSIVE {r,g,b} OPACITY {r,g,b} } MATERIAL (NAME=bluebrick) /* Name of the material */ { TEXTURE {londonbrick} /* Texturing mode. */ AMBIENT {r,g,b} /* Ambient colour */ DIFFUSE {r,g,b} SPECULAR {r,g,b,p} EMISSIVE {r,g,b} OPACITY {r,g,b} } /* * An object definition */ OBJECT (NAME=myname; /* Name of the object. */ F_MATERIAL=bluebrick; B_MATERIAL=redbrick; PLANE=NORMAL; DRAWMODE=FILLED; DECAL=0; FACETED=NONE; VERTEX=NORMALS, 2D_TEXTURE) { LOD (DISTANCE=in,out; REFERENCE=x,y,z; TRANSITION=BLEND) { PATCH (NAME=patch_name; F_MATERIAL=glass; B_MATERIAL=F_MATERIAL; VERTEX=RGB, NORMALS; SPECIAL="voodo string" LOCK=OFF) { TRISTRIP { {x,y,z,Nx,Ny,Nz,r,g,b,a} {x,y,z,Nx,Ny,Nz,r,g,b,a} } PATCH (DECAL=1; LOCK = 1) { /* Coplaner patch - enable decal */ POLYSTRIP { {x,y,z,Nx,Ny,Nz,u,v} {x,y,z,Nx,Ny,Nz,u,v} } PMESH { VERTEX_POOL { {x,y,z,Nx,Ny,Nz,u,v} {x,y,z,Nx,Ny,Nz,u,v} } CONNECTION_LIST { {index, index, index} {index, index, index} } CONNECTION_LIST (PCOUNT=4){ {index, index, index, index} {index, index, index, index} } } SPHERELIST (DICE_U=20; DICE_V=20) { {x,y,z,r} {x,y,z,r} } LINE (THICKNESS=4) { {x,y,z} {x,y,z} } TEXT (FONT=QUICK; SCALE=x,y,z; ORIENTATION=x,y,z) { STRING {x,y,z, "Global string"} } POLYGON { {x,y,z,Nx,Ny,Nz,u,v} {x,y,z,Nx,Ny,Nz,u,v} } } PATCH (...) { ... } } /* End of 1st LOD */ LOD (DISTANCE=in,out; TRANSITION=BLEND; REFERENCE=x,y,z) { PATCH (...) { .... } PATCH (...) { .... } } /* End of 2nd LOD */ } /* End of OBJECT */ /* End of Geometry file */ Document Information Authour: J.D. Naughton-Green Create Date: 18 February 1995 Edit Date: 06 April 1995 Save Date: 18 February 1995 Print Date: 18 February 1995 Version: 2 Template: c:\windows\winword\template\dmanual.dot Filename: v:\projects\dvs2.1\docs\dm621-18.man Title: dVS File Specifications Total No Pages: 58 Revision History Revision Date Author Change Description 1st Ed. Rev 0 08/03/93 JNG Original 1st Ed. Rev 1 14/11/93 JNG Added BIZ file format. 1st Ed. Rev 2 20/12/93 JNG Amended after passed around for comments. 1st Ed. Rev 3 18/01/94 JNG Amended in light of 1st Pixel Planes release. 1st Ed. Rev 4 09/02/94 JNG Corrected a few typo's. 1st Ed. Rev 5 11/04/93 JNG Added scoping to materials, textures and ramps. 1st Ed. Rev 6 16/08/94 JNG Added ænÆ polygon CONNECTION_LIST in PMESHÆs 1st Ed. Rev 7 28/09/94 JNG Add locks to the surface specifiers. 1st Ed. Rev 8 10/11/94 JNG Corrected the VTX format - anomolies in specification. This is some old stuff - kept here because may be useful. CYLINDER The CYLINDER section describes arbitrarily oriented cylinders. The cylinder descriptor may include multiple cylinder definitions within the same construct, Each cylinder is described with a different position, orientation, length and radius. The syntax is defined as follows:- CYLINDER (DICE = 8; ENDCAPS = ON) { {x,y,z,p,r,y,len,rad} /* One cylinder */ {x,y,z,p,r,y,len,rad} /* Another cylinder */ .... {x,y,z,p,r,y,len,rad} } The fields are defined as follows:- DICE=count The number of vertices count used to construct the cylinder walls. count is an integer in the range 0, 3..65535. A value of 0 denotes the rendering subsystem selects the DICE value. The default value is zero. ENDCAPS=mode Specify if the cylinders require endcaps. mode is defined as follows:- OFF The default, disables endcap generation. ON Enables endcap generation. {x,y,z,p,r,y,len,rad} Defines the construction of the cylinder as follows:- x,y,z The centre of the cylinder. p,r,y The orientation of the cylinder specified as pitch, roll and yaw in terms of radians. len The length of the cylinder. rad The radius of the cylinder. Cylinder Section The cylinder section may appear anywhere in the BIZ file and is defined as follows:- xx00 0x018 length CYLINDER. Start of a cylinder definition. 0x2020 0x02 dice DICE. The number of sub-divisions to be made when forming the cylinder. dice is a 16 bit integer denoting the dicing value. 0x0019 0xnn x y z p r y len radius {x,y,z,p,r,y,len,radius}. Cylinder definition. x, y and z define the position of the cylinder in space (centre of). p (pitch), r (roll) and y (yaw) define the orientation of the cylinder of length len and radius radius. All parameters are floating point values as defined by the precision flag. dVS File Specifications (c) Division 1995