-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
58f8d9e
commit ba78990
Showing
8 changed files
with
829 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
$doom3-000: #f14141; | ||
$doom3-100: #f53a3a; | ||
$doom3-200: #e72828; | ||
$doom3-300: #dd1010; | ||
|
||
$prey06-000: #7ef3f7; | ||
$prey06-100: #67f4f9; | ||
$prey06-200: #4edfe9; | ||
$prey06-300: #2cbadd; | ||
|
||
$quake4-000: #eff77e; | ||
$quake4-100: #f9ef67; | ||
$quake4-200: #e9df4e; | ||
$quake4-300: #ece930; | ||
|
||
$wolf09-000: #f7a47e; | ||
$wolf09-100: #f9a167; | ||
$wolf09-200: #e97f4e; | ||
$wolf09-300: #ec7b30; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
--- | ||
layout: default | ||
title: Collision Model Manager (CM) | ||
parent: Engine Documentation | ||
has_children: true | ||
nav_order: 2 | ||
--- | ||
|
||
# Overview. | ||
{: .fs-9 } | ||
{:overview} | ||
|
||
--- | ||
|
||
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). | ||
|
||
Hmm, it sounds like this might be helpful with creating AI for Quake Wars: Enemy Territory. 😉 | ||
|
||
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! | ||
|
||
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. | ||
For much more on BSP's, check out this nice tutorial: ~~http://www.oracledbaexpert.com/BSPTrees/Trees.html~~ dead link. | ||
|
||
# In a nutshell | ||
|
||
`.cm` files store collision model data. Collision models are a binary space partitioning based format used for collision detection. | ||
They are most commonly used with maps but can also be used with moveable physics objects. | ||
|
||
# Export | ||
|
||
The creation of a collision model for use with a map is done automatically by the engine upon compile with the `dmap` console command. | ||
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`. | ||
From this point the `.cm` file must be named and placed in the same directory as the map or model. | ||
|
||
# Note | ||
|
||
{: .etqw} | ||
> Enemy Territory: Quake Wars encrypt its files so its hard to see what change and what not. | ||
> Encrypted models has the post fix of `b` in this case `.cm**b**` | ||
{: .wolf09} | ||
> This system is deprecated in Wolfstein (2009) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,140 @@ | ||
--- | ||
layout: default | ||
title: Format Specifications | ||
parent: Collision Model Manager (CM) | ||
grand_parent: Engine Documentation | ||
nav_order: 2 | ||
--- | ||
|
||
{: .no_toc } | ||
|
||
<details open markdown="block"> | ||
<summary> | ||
Table of contents | ||
</summary> | ||
{: .text-delta } | ||
- TOC | ||
{:toc} | ||
</details> | ||
|
||
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. | ||
|
||
# Version File | ||
--- | ||
The `"CM"` section on the `.cm` file indicates the version of wich this map/model was made on. | ||
|
||
{: .doom3 } | ||
|
||
> ```cpp | ||
> CM "1.00" | ||
> ``` | ||
{: .prey06 } | ||
> ```cpp | ||
> CM "1.00" | ||
> ``` | ||
{: .quake4 } | ||
> ```cpp | ||
> CM "3" | ||
> ``` | ||
# Cyclic redundancy check (CRC) | ||
--- | ||
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 | ||
compared to the .map file. | ||
```cpp | ||
115442973 | ||
``` | ||
# Collision Model | ||
--- | ||
This is the meat and bones of the Collision system, this inlines models for collision purposes, mostly `func_` entities, a basic look of | ||
`collisionModel`: | ||
```cpp | ||
collisionModel "func_static_1" { | ||
/** Irrelevant Code **/ | ||
} | ||
``` | ||
There's a special code for `collisionModel` that handles worldmap collision: | ||
```cpp | ||
collisionModel "worldMap" { | ||
/** Irrelevant Code **/ | ||
} | ||
``` | ||
`collisionModel` also contains 5 subgroups: `"vertices"`, `"edges"`, `"nodes"`, `"polygons"` and `"brushes"`. | ||
## Vertices | ||
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)`. | ||
```cpp | ||
vertices { /* numVertices = */ numverts | ||
/* vertnum */ ( x y z ) | ||
} | ||
``` | ||
* `numverts` = The number vertices that are in this group. | ||
* `vertnum` = The vertice that's being proccesed currently. | ||
* `x, y` and `z` = The position to where this vertex is locate at. | ||
## Edges | ||
Defines the edges between vertices. Each edge connects two vertices and is defined by their indices. | ||
Optionally, additional information can be provided, such as edge direction or properties. | ||
```cpp | ||
edges { /* numEdges = */ numedgs | ||
/* edgenum */ ( start end ) internal numpolys | ||
} | ||
``` | ||
* `numEdges` = The number edges that are in this group. | ||
* `edgenum` = The edge that's being proccesed currently. | ||
* `start` = The start position to draw the edge from. | ||
* `end` = The end position to where the edge ends. | ||
* `internal` = Tells this edge that it shouldn't collide with internal edges. | ||
* `numpolys` = X many times this edge is used by poly. | ||
## Nodes | ||
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. | ||
```cpp | ||
nodes { | ||
( index frontindex backindex ) <optional> | ||
} | ||
``` | ||
* `index` = The plane index. | ||
* `frontindex` = The front node index used for the BSP tree. | ||
* `backindex` = The back node index used for the BSP tree. | ||
{: .note } | ||
> 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. | ||
## Polygons | ||
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. | ||
```cpp | ||
polygons { | ||
numverts ( index1 index2 ... ) ( normvectx normvecty normvectz ) distance ( bboxmin ) ( bboxmax ) "texture" | ||
} | ||
``` | ||
* `numverts` = The plane indexThe number of vertices this poly has. | ||
* `index1, index2, ect` = The indexes used to conform the polygon. | ||
* `normvectx, normvecty` and `normvectz` = Tells the direction of this vector's normal in the X/Y/Z. | ||
* `distance` = The distance between the polys and the bounding box. | ||
* `bboxmin` and `bboxmax` = The Min/Max of the bounding box. | ||
* `texture` = The texture that's assigned to this polygon. | ||
## Brushes | ||
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. | ||
```cpp | ||
brushes { | ||
numplanes { | ||
( planenormx planenormy planenormz ) distance | ||
} ( bboxmin ) ( bboxmax ) <optional> | ||
} | ||
``` | ||
* `numplanes` = The current brush's plane that's being processed. | ||
* `planenormx, planenormy` and `planenormz` = Tells the direction of this plane normal in the X/Y/Z. | ||
* `distance` = The distance between the polys and the bounding box. | ||
* `bboxmin` and `bboxmax` = The Min/Max of the bounding box. | ||
**Brushes**: define solid volumes through planes. Each plane in a brush contributes to the definition of a convex volume. |
Oops, something went wrong.