3DZ File Structure and Editing Notes

Paulo Morais
April 2000

1. Introduction
3DZ files like many other proprietary Microprose file formats used in EAW, like the CDF for example, are the result of a long time continuous development effort that bear its fruits. The proof of this came from the fact that many MPS simulations used exactly this file format to define 3d objects despite very different first publication date and development teams. At least “Fleet Defender”, “PAW”, “M1A2TP2” and “EAW” use this file format for sure and most probably “GP2” also. This continuous development and refinement is a good explanation for MPS avoidance to publish anything related with the format to protect their investment. Another consequence of this is a very complex and optimised internal structure that resisted every identification effort so far.
2. 3DZ File Structure
In the following description of the file format it will be used a C like notation. The example values were taken from the file PHURRF.3DZ.
Each 3DZ file is made of several sections, some of them being optional. The way to calculate the offset to reach a particular section is given in terms of variables previously defined. Some sections can be better represented by a C structure that is repeated depending on the number of elements involved. All values are integers of different sizes, signed or unsigned. Not a single floating point value is used by the 3DZ file format.


Every 3DZ file can only use a single texture file to cover some or all of the internally defined elements. The name must point to the uncompressed version of the texture file, that is always in PCX file format. The size of this last file has varied with time, being 256x200 for older simulations and 256x256 for EAW.
Components are model parts that can have relative motion. Propellers and undercarriage wheels are some of the possible components. Can be internally defined or externally. In the last case is up to the application to provide the name of the missing component. It is for this reason that some of the PAW models are not compatible with EAW. The different parts that make the entire model are distributed in a different way.
Nodes are 3d points that can be used for several purposes inside the file, and are all grouped in a single table. All elements only make references to entries in this table using a single byte instead of defining all three coordinates.
Elements are all the 3d points, lines and different types of polygons, textured or simply painted in one colour, with transparent information or not that are defined inside the file.


The referential used is: Y is the model transversal axis, wingtip to wingtip in the case of aircraft, positive sense from model centre towards left wingtip; Z is the model vertical axis, positive sense downwards; X longitudinal axis; positive sense backwards, from centre towards tail.
This section is absent if the total number of components is one. Otherwise the same data structure repeats for each extra component.


The surface normal is normalised to 16384. That means the square root of the sum of squares of components always gives that value. The fourth value can be the independent term for a clipping plane definition. The fifth can be some curvature value used for rendering the surface. The last is a flag or body ownership value.
Element rendering sequence (_seq)
Located at Offset: sizeof(_header) + (_par-1) x 8 bytes + _ele x 12 bytes
Size: (_ele+1) x 2 bytes
This is a circular linked list with branching that defines the correct sequence of element drawing.
0B0E 3E 00 FF 52 FF ....
This is the trickiest part of the 3DZ file structure. If a element is absent of list it is simply ignored. If misplaced it can be drawn in front of others even if it is physically behind. If the sequence is cutted by a misplaced element entire parts of the model are left blank. The best interpretation I can give is that each value represents a element and also a jump to the relative position from start of sequence that should be occupied by the next element in sequence.

A table containing the absolute offsets from start of file for each individual element. This table is necessary because the size of each element is variable and dependent on its type and number of nodes used.


Some elements have a WORD prefix meaning the element belongs to a certain detachable part like a wing for example. The word is made of a first byte that identify the part, the second byte is a flag. A element from the point of view of the location table, drawing sequence and normals only ends when a FF character is found. So it is possible to find entire chains of several elements including the WORD prefix that only count as one.


6 - Potentially Transparent textured polygon. Depends on contents of TRA texture file. This element share the same structure of the previous
The pairing of TRA and TEX files is application dependent. For EAW that pairing is not defined for every aircraft slot. The usage of non-standard names will also compromise transparent effects.
3. 3DZ File Editing
Until someone has the time and ability to write a full featured 3DZ file editor we must resort to other ways to at least make some simple changes to the base shapes provided in EAW/PAW and other simulations by Microprose.
This is a difficult but not impossible task to perform, even with the sort of tools that are currently available. The setup I use is composed of the following applications:
• A 3D editor like AutoCAD, AutoCAD LT, 3D Studio or any other application capable of importing and displaying 3D DXF file formats. Preferably this application should be able to identify each element by layer or colour when requested by the user. This application is only used to display and identify by number the elements to change. It can also be used to calculate the new node and texture mapping positions.
• A hex-editor. Preferably one that supports data structures like NEO .. This editor is available at <http://www.hhdsoftware.com/Downloads/hex-editor-free.html> and is defined by the author as “free shareware”. All the changes are done with the aid of the hex-editor.
• A Picture Editor like Paint Shop Pro or others widely available to create/modify model skins according to changes made to the models. For example if one choose to change some of the 3D faces that were opaque into transparent ones, a simple change from element type 5 to 6, one must edit both P????TEX.PCX and P????TRA.PCX files to take advantage of the change.
• A ‘good’ file manager for obvious reasons. Here my preference goes to ZTree available at <http://www.ztree.com>.
• Finally, two small DOS applications: 3DZ2BMP.EXE and 3DZ_MAP.EXE that are part of this notes.
1. The first produces a BMP file, using EAW standard palette for aircrafts, containing the outline of all textured polygons defined in a 3DZ file. This program can be used to provide a good starting point to skin the models from PAW or for a deeply changed EAW model.
2. The second program outputs two files: a text dump of all elements, nodes, normals, insertion points, header and drawing sequence where each entity is identified by a letter/number for cross-reference when using the editors; and a 3D DXF file that translates all nodes/3d points (element type 2) as point entities, all polygon faces (elements 3 to 6) as closed polylines using colours according to type number and lines are translated to lines. Each 3d element/point/polygon mapping is placed in a different layer according to its position inside the 3DZ file. So, in layer zero we will find a point entity that represent the first node defined in the 3DZ file; a polyline/line that matches the 3d aspect of the first element defined and a polyline that reproduces the mapping outline of the same element when projected over the surface of the texture file. The same goes for all the rest of the elements and nodes. This program as an alternative 3DZ_MAPC.EXE that produces exactly the same output but the DXF file associate elements to different colours instead of different layers. In some cases this is easier to use and makes the output more compatible with editors that place limitations on the maximum number of layers.
Both programs are best used if placed in the same folder were the 3DZ files are. They can be executed from a DOS box command line or from the Explorer interface. In the last case or if the name of the 3DZ file to map is not given in the command line they will ask for one. After a successful execution the only visible output will a be a simple signon message.

4. Final Notes
This document contains all my knowledge regarding 3DZ file structure at the present moment and can be revised according to new developpments and feedback. It is dedicated to all fellow EAW editors and users that managed to mantain alive a very fine simulation that is getting better all the time.

Paulo Morais
1 May 2000