PKG - Revision history

CarLuver69: /* Shaders */ Updated shader formats.

2017-11-28T05:29:39Z

‎Shaders: Updated shader formats.

Midas: /* Files */

2015-12-10T23:25:33Z

‎Files

Fre-Ber: /* Geometry file: The "flags" field of the geometry file is, in fact a DirectX FVF value */

2006-10-03T22:27:22Z

‎Geometry file: The "flags" field of the geometry file is, in fact a DirectX FVF value

Fre-Ber: /* Boundary files */

2006-08-06T20:46:28Z

‎Boundary files

Fre-Ber: /* MTX - Local objects */

2006-08-06T20:45:25Z

‎MTX - Local objects

Fre-Ber: /* MTX - Local objects - Moved description to separate page */

2006-08-06T20:35:46Z

‎MTX - Local objects - Moved description to separate page

Fre-Ber: /* Boundary files - moved descriptions to separate pages*/

2006-08-06T20:33:25Z

‎Boundary files - moved descriptions to separate pages

Fre-Ber: /* Copied bound info from Yallis' description at mm2c */

2006-08-04T19:49:57Z

‎Copied bound info from Yallis' description at mm2c

Fre-Ber: /* MTX Structure */

2006-04-22T20:51:14Z

‎MTX Structure

Fre-Ber: /* MTX - Local objects: According to an old document by Oleg, the nine define a bounding box. */

2006-04-22T20:50:52Z

‎MTX - Local objects: According to an old document by Oleg, the nine define a bounding box.

@@ Line 152: / Line 152: @@
   union PKGShader
+  {
-      FloatPKGShader floatShader; // If type is 0
+      PKGFullShader fullShader; // If type is 0
-      IntPKGShader   intShader;   // If type is 1
+      PKGLightShader lightShader; // If type is 1
+  }
-  FloatPKGShader
+'''NOTE:''' The original format for shaders was ''wrong''! Diffuse and Ambient were reversed, and Emissive was incorrectly named Reflective. The shader names have also been updated to try and better reflect their uses.
+  {
       String  textureName;
       Color4f ambient;
       Color4f specular;
-      Color4f reflective;
+      Color4f emissive;
       float   shininess; // Intensity of specular highlights
+  }
-  IntPKGShader
+  PKGLightShader
+  {
       String  textureName;
       Color4d ambient;
-      Color4d diffuse;
+      Color4d emissive;
       float   shininess; // Intensity of specular highlights
+  }

@@ Line 10: / Line 10: @@
 Each file has a name. This name determines the type of the file.
-; *VL, *L, *M, *H (Geometry file): Files whose name ends with one of "VL", "L", "M", "H" define geometry primitives. The name suffixes define the LOD, the level of detail, of the particular part of the object. A PKG-file can have any number of separate parts, some have special significance, especially for vehicle models. The suffixes themself stand for Very Low, Low, Medium and High respectively. Look [[PKG_Groups|here]] for a description of the special geometry groups.
-;shaders:  A PKG-file always have one ''shader'' file. It defines the visual material properties to use for the surfaces defined in the geometry files. Shaders can be defined in one of two ways, either using floating point colour values or integer colour values. Each shader defines ambient, diffuse, specular and emissive colours. The floating point shader also specifies the shininess used to calculate highlights. Each shader can also specify one texture map. The shaders are organized in groups called ''paint jobs''. When an object is placed in game, a certain paint job is requested, either by the INST, PATHSET or PSDL for monuments and props or by user interaction for player vehicle models. Each paint job holds the same number of shaders, even if a particular shader is identical in several paint jobs. Each group of geometry primitives referens an index in to a single paint-job of the shader list.
+{| class="wikitable"
-;offset: Unknown, probably provides a way to offset every point of this model with a fixed vector. A PKG-file can only contain one offset file.
+! Name !! Description
-;xref: Reference to another PKG. Some objects are constructed by attaching several smaller objects to itself. Often these parts are ''breakable''. This means that they can be broken off from the main object. Examples are awnings on facades or pieces of driveable vehicles that can break off as a result of careless driving.
+|-
 ===Structure===

@@ Line 61: / Line 61: @@
                          // Highly unlikely, but I have no better suggestion at
                          // this time
-      long flags;        // Flags defining what components are provided with
+      long fvf;          // Flags defining what components are provided with
                          // each vertex, see below
       PKGSection[nSections] sections;
@@ Line 112: / Line 112: @@
+  }
-The bits of the PKGFILEData.flags field are defined as follows:
+The bits of the PKGFILEData.fvf field are defined by the DirectX flexible vertex format enumerated type. Some of the bits are as follows:
 <ol start="0">
   <li>Unknown</li>
-  <li>Texture coordinates or coordinates</li>
+  <li>D3DFVF_NORMAL - Normal vector</li>
- <li>Unknown</li>
+  <li>D3DFVF_RESERVED1</li>
- <li>Unknown</li>
+  <li>D3DFVF_DIFFUSE - Vertex colour 0 (diffuse)</li>
- <li>Normal vectors</li>
+  <li>D3DFVF_SPECULAR - Vertex colour 1 (specular)</li>
-  <li>Unknown</li>
+  <li>D3DFVF_TEX1 - One 2D texture coordinate</li>
 </ol>
-All other bits are unknown at this time.
+Other bits can be checked in the DirectX documentation or header file d3dtypes.h.
 The only known value for primType is PRIMTYPE_TRIANGLES (=3) that means that the indices make up lists of complete, separate triangles.

@@ Line 208: / Line 208: @@
 MM2 use three file types for collision detection and material properties on regular PKG objects:
-* [[bnd]] - Simple bound mesh in a plain ASCII format.
+* [[BND]] - Simple bound mesh in a plain ASCII format.
-* [[bbnd]] - Binary version of .bnd
+* [[BBND]] - Binary version of .bnd
-* [[ter]] - Unknown, but the MM2 engine does read these files
+* [[TER]] - Unknown, but the MM2 engine does read these files
 It is not clear when to pick .bbnd/.ter over .bnd, but some indications imply that objects placed with INST typically uses the binary formats.

@@ Line 203: / Line 203: @@
 ==MTX - Local objects==
-Some PKGs have several geometry files that are defined in a local coordinate system. These are recognised by the fact that they have an additional, external file in the filesystem. Look [[Mtx|here]] for more information.
+Some PKGs have several geometry files that are defined in a local coordinate system. These are recognised by the fact that they have an additional, external file in the filesystem. Look [[MTX|here]] for more information.
 ==Boundary files==

← Older revision		Revision as of 19:49, 4 August 2006
Line 217:		Line 217:
	Vector3D origin; // Origin of the local coordinate system		Vector3D origin; // Origin of the local coordinate system
	}		}
		+
		+	==Boundary files==
		+	MM2 use three file types for collision detection and material properties on regular PKG objects:
		+
		+	* .bnd - Simple bound mesh in a plain ASCII format.
		+	* .bbnd - Binary version of .bnd
		+	* .ter - Unknown, but the MM2 engine does read these files
		+
		+	It is not clear when to pick .bbnd/.ter over .bnd, but some indications imply that objects placed with INST typically uses the binary formats.
		+
		+	===BND===
		+	TODO
		+
		+	===BBND===
		+	struct BBND
		+	{
		+	char version; // == 1
		+	long nVertices;
		+	long nMaterials;
		+	long nPolys;
		+	BBNDVertex vertices[nVertices];
		+	BBNDMaterial materials[nMaterials];
		+	BBNDPolygon polys[nPolys];
		+	};
		+
		+	struct BBNDVertex
		+	{
		+	float x;
		+	float y;
		+	float z;
		+	};
		+
		+	struct BBNDMaterial
		+	{
		+	char[32] name;
		+	float elasticity;
		+	float friction;
		+	char[32] effect;
		+	char[32] sound;
		+	};
		+
		+	struct BBNDPolygon
		+	{
		+	short indicies[4];
		+	short material;
		+	};
		+
		+	Bound polygons can be quads and triangles. If a polygon is a triangle, the last index is 0. Therefore a future exporter must never put the vertex index 0 last in a quad polygon. All strings are fixed 32 byte arrays with terminator byte 0x00.
		+
		+	===TER===
		+	TODO

@@ Line 212: / Line 212: @@
   struct MTX
+  {
-     Vector min;    // Minimum x, y and z
+     Vector3D min;    // Minimum x, y and z
-     Vector max;    // Maximum x, y and z
+     Vector3D max;    // Maximum x, y and z
-     Vector cog;    // Center of gravity, object is rotated around this point
+     Vector3D cog;    // Center of gravity, object is rotated around this point
-     Vector origin; // Origin of the local coordinate system
+     Vector3D origin; // Origin of the local coordinate system
+  }

@@ Line 205: / Line 205: @@
 Some PKGs have several geometry files that are defined in a local coordinate system. These are recognised by the fact that they have an additional, external file in the filesystem. The name of this file is ''<pkgname>_<geometryname>.mtx''  where ''pkgname'' is the filename of the ''PKG'', without the ''.pkg'' extension and ''geometryname'' is the name of the internal geometry file excluding the trailing underscore and LOD name. For example, the ''PKG'' named ''vpauditt.pkg'' has a locally defined geometry file named ''WHL0_H''. The ''MTX'' file for this is named ''vpauditt_whl0.mtx''. If the ''geometryname'' only contains a LOD name, the ''geometryname'' is replaced by ''(null)''.
-What the ''MTX'' file does is to define the coordinate system to use for the geometry file in question. MM2 can then manipulate this transformation matrix in order to animate the parts of the ''PKG'' object. For example, turning the wheels depending on current velocity and steering.
+What the ''MTX'' file does is to define the location and extent of the geometry file in question. MM2 can manipulate the piece of geometry based on this information in order to animate the parts of the ''PKG'' object. For example, turning the wheels depending on current velocity and steering, while maintaining quick and accurate collision detection.
 ===MTX Structure===
-The file contains twelve floating point numbers, these make up part of a 4x4 linear transformation matrix. The remaining four floats required are (0.0, 0.0, 0.0, 1.0).
+The file contains four vectors. The first three define a bounding box and a center of gravity while the fourth defines an offset for the coordinate system.
-The matrix was thought to be constructed like this:
+ struct MTX
-{|class="wikitable"
-| f[0] || f[1] || f[2] || f[9]
+    Vector min;    // Minimum x, y and z
-|-
+    Vector max;    // Maximum x, y and z
-| f[3] || f[4] || f[5] || f[10]
+    Vector cog;    // Center of gravity, object is rotated around this point
-|-
+    Vector origin; // Origin of the local coordinate system
-| f[6] || f[7] || f[8] || f[11]