Skip to content

Commit ba78990

Browse files
Reorganization + CM Documentation
1 parent 58f8d9e commit ba78990

8 files changed

Lines changed: 829 additions & 3 deletions

File tree

_config.yml

Lines changed: 11 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -51,10 +51,19 @@ callouts:
5151
color: blue
5252
quake4:
5353
title: Quake IV Only
54-
color: yellow
54+
color: quake4
55+
etqw:
56+
title: Enemy Territory - Quake Wars Only
57+
color: quake4
5558
prey06:
5659
title: Prey 2006 Only
57-
color: blue
60+
color: prey06
61+
doom3:
62+
title: Doom 3 Only
63+
color: doom3
64+
wolf09:
65+
title: Wolfstein (2009)
66+
color: wolf09
5867

5968
# Build settings
6069
theme: just-the-docs

_sass/custom/setup.scss

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
$doom3-000: #f14141;
2+
$doom3-100: #f53a3a;
3+
$doom3-200: #e72828;
4+
$doom3-300: #dd1010;
5+
6+
$prey06-000: #7ef3f7;
7+
$prey06-100: #67f4f9;
8+
$prey06-200: #4edfe9;
9+
$prey06-300: #2cbadd;
10+
11+
$quake4-000: #eff77e;
12+
$quake4-100: #f9ef67;
13+
$quake4-200: #e9df4e;
14+
$quake4-300: #ece930;
15+
16+
$wolf09-000: #f7a47e;
17+
$wolf09-100: #f9a167;
18+
$wolf09-200: #e97f4e;
19+
$wolf09-300: #ec7b30;
Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,6 @@ has_children: true
66
nav_order: 1
77
---
88

9-
# Navigation Structure
109
{: .no_toc }
1110

1211
<details open markdown="block">
File renamed without changes.

docs/engine/cm/cm.md

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
---
2+
layout: default
3+
title: Collision Model Manager (CM)
4+
parent: Engine Documentation
5+
has_children: true
6+
nav_order: 2
7+
---
8+
9+
# Overview.
10+
{: .fs-9 }
11+
{:overview}
12+
13+
---
14+
15+
Since Doom 1, ID software has relied on BSP trees to increase the performance of its engines. BSP trees are very useful in both rendering and collision detection. The doom3 engine stores the rendering bsp tree in the.proc file and the collision bsp tree in the.cm file. Oh yeah, the collision bsp can also be used for creating AI pathfinding systems (also known as the Area Awareness System (AAS) in Doom 3).
16+
17+
Hmm, it sounds like this might be helpful with creating AI for Quake Wars: Enemy Territory. 😉
18+
19+
So what's collision detection exactly? Without a collision detection system, the player would be able to walk right through every wall on the map. If you want to experience a game without a collision system, simply enable Noclip in Doom 3. Such a system will calculate whether or not the player (among other objects) makes contact with solid surfaces. If the player does, the system will then prevent the player from passing through. duh!
20+
21+
Simple enough, right? Well, imagine a map with 4,000 brushes, or roughly 24,000 brush faces. Looping through all 24,000 faces in each frame to determine whether or not the player is in contact with one of them is not very efficient. This is where the BSP tree comes in. In short, instead of looping through all 24,000 faces, a BSP tree allows us to eliminate huge chunks of brushes almost instantly. With just a few calculations, a properly configured BSP tree can narrow down the 24,000 brush faces to just a handful! quite an improvement, I'd say.
22+
For much more on BSP's, check out this nice tutorial: ~~http://www.oracledbaexpert.com/BSPTrees/Trees.html~~ dead link.
23+
24+
# In a nutshell
25+
26+
`.cm` files store collision model data. Collision models are a binary space partitioning based format used for collision detection.
27+
They are most commonly used with maps but can also be used with moveable physics objects.
28+
29+
# Export
30+
31+
The creation of a collision model for use with a map is done automatically by the engine upon compile with the `dmap` console command.
32+
To create a collision model for use with a moveable physics object, from within the level editor, you must select the brushes and/or model. Then click `Selection > Export > to CM`.
33+
From this point the `.cm` file must be named and placed in the same directory as the map or model.
34+
35+
# Note
36+
37+
{: .etqw}
38+
> Enemy Territory: Quake Wars encrypt its files so its hard to see what change and what not.
39+
> Encrypted models has the post fix of `b` in this case `.cm**b**`
40+
41+
{: .wolf09}
42+
> This system is deprecated in Wolfstein (2009)

docs/engine/cm/cm_format.md

Lines changed: 140 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,140 @@
1+
---
2+
layout: default
3+
title: Format Specifications
4+
parent: Collision Model Manager (CM)
5+
grand_parent: Engine Documentation
6+
nav_order: 2
7+
---
8+
9+
{: .no_toc }
10+
11+
<details open markdown="block">
12+
<summary>
13+
Table of contents
14+
</summary>
15+
{: .text-delta }
16+
- TOC
17+
{:toc}
18+
</details>
19+
20+
The .cm (Collision Model) file format organizes data into sections for vertices, edges, nodes, polygons, and brushes to comprehensively define collision geometry in a game environment.
21+
22+
# Version File
23+
---
24+
The `"CM"` section on the `.cm` file indicates the version of wich this map/model was made on.
25+
26+
{: .doom3 }
27+
28+
> ```cpp
29+
> CM "1.00"
30+
> ```
31+
32+
{: .prey06 }
33+
34+
> ```cpp
35+
> CM "1.00"
36+
> ```
37+
38+
{: .quake4 }
39+
40+
> ```cpp
41+
> CM "3"
42+
> ```
43+
44+
45+
# Cyclic redundancy check (CRC)
46+
---
47+
This line is used for checksum purposes, this line is bitwise XOR of all entities's CRC, It is used to tell if the map is outdated
48+
compared to the .map file.
49+
50+
```cpp
51+
115442973
52+
```
53+
54+
# Collision Model
55+
---
56+
This is the meat and bones of the Collision system, this inlines models for collision purposes, mostly `func_` entities, a basic look of
57+
`collisionModel`:
58+
```cpp
59+
collisionModel "func_static_1" {
60+
/** Irrelevant Code **/
61+
}
62+
```
63+
There's a special code for `collisionModel` that handles worldmap collision:
64+
```cpp
65+
collisionModel "worldMap" {
66+
/** Irrelevant Code **/
67+
}
68+
```
69+
`collisionModel` also contains 5 subgroups: `"vertices"`, `"edges"`, `"nodes"`, `"polygons"` and `"brushes"`.
70+
71+
## Vertices
72+
A list of vertices used to define the shape of the collision model. Each vertex is represented by a coordinate in 3D space `(x, y, z)`.
73+
```cpp
74+
vertices { /* numVertices = */ numverts
75+
/* vertnum */ ( x y z )
76+
}
77+
```
78+
* `numverts` = The number vertices that are in this group.
79+
* `vertnum` = The vertice that's being proccesed currently.
80+
* `x, y` and `z` = The position to where this vertex is locate at.
81+
82+
## Edges
83+
Defines the edges between vertices. Each edge connects two vertices and is defined by their indices.
84+
Optionally, additional information can be provided, such as edge direction or properties.
85+
```cpp
86+
edges { /* numEdges = */ numedgs
87+
/* edgenum */ ( start end ) internal numpolys
88+
}
89+
```
90+
* `numEdges` = The number edges that are in this group.
91+
* `edgenum` = The edge that's being proccesed currently.
92+
* `start` = The start position to draw the edge from.
93+
* `end` = The end position to where the edge ends.
94+
* `internal` = Tells this edge that it shouldn't collide with internal edges.
95+
* `numpolys` = X many times this edge is used by poly.
96+
97+
## Nodes
98+
This section typically describes the nodes in the collision model's spatial partitioning structure, such as a BSP (Binary Space Partitioning) tree. Nodes are used to efficiently organize and query the collision geometry.
99+
```cpp
100+
nodes {
101+
( index frontindex backindex ) <optional>
102+
}
103+
```
104+
* `index` = The plane index.
105+
* `frontindex` = The front node index used for the BSP tree.
106+
* `backindex` = The back node index used for the BSP tree.
107+
108+
{: .note }
109+
110+
> Nodes are used for spatial partitioning (e.g., in a BSP tree). The exact format can vary depending on the specifics of the partitioning system used.
111+
112+
## Polygons
113+
Lists the polygons that make up the collision surfaces. Each polygon is defined by its vertices (or edges) and has additional attributes such as the normal vector, plane equation, and texture information.
114+
```cpp
115+
polygons {
116+
numverts ( index1 index2 ... ) ( normvectx normvecty normvectz ) distance ( bboxmin ) ( bboxmax ) "texture"
117+
}
118+
```
119+
* `numverts` = The plane indexThe number of vertices this poly has.
120+
* `index1, index2, ect` = The indexes used to conform the polygon.
121+
* `normvectx, normvecty` and `normvectz` = Tells the direction of this vector's normal in the X/Y/Z.
122+
* `distance` = The distance between the polys and the bounding box.
123+
* `bboxmin` and `bboxmax` = The Min/Max of the bounding box.
124+
* `texture` = The texture that's assigned to this polygon.
125+
126+
## Brushes
127+
Brushes are convex shapes used to define solid areas for collision. Each brush is defined by a set of planes, and each plane is defined by a normal vector and a distance from the origin. Brushes are particularly useful for defining static architecture and level boundaries.
128+
```cpp
129+
brushes {
130+
numplanes {
131+
( planenormx planenormy planenormz ) distance
132+
} ( bboxmin ) ( bboxmax ) <optional>
133+
}
134+
```
135+
* `numplanes` = The current brush's plane that's being processed.
136+
* `planenormx, planenormy` and `planenormz` = Tells the direction of this plane normal in the X/Y/Z.
137+
* `distance` = The distance between the polys and the bounding box.
138+
* `bboxmin` and `bboxmax` = The Min/Max of the bounding box.
139+
140+
**Brushes**: define solid volumes through planes. Each plane in a brush contributes to the definition of a convex volume.

0 commit comments

Comments
 (0)