Currently, every vertex within a polygon is assigned a unique index. However, the game engine supports sharing vertex indices across multiple polygons. This is beneficial because in the current binary format, there are "only" 65.535 indices available (i.e. 16.383 quads / 21.845 triangles).

By enabling this feature, more polygons can be constructed, enhancing the design process of very large and complex maps.

Example (data extracted from an original bound file)

Polygon
Bound Number: 0
Flags: 4
Vertices Indices: (6, 4, 5, 7)
Vertices Coordinates: [{-1.01,1.34,-2.07}, {-1.01,0.33,-2.07}, {-1.01,0.33,2.11}, {-1.01,1.34,1.49}]
Plane Edges: [{0.00,1.00,-2.07}, {1.00,-0.00,0.33}, {-0.53,-0.85,-1.97}, {-1.00,-0.00,-1.34}]
Plane N: {-1.00,0.00,0.00}
Plane D: [-1.01]

Polygon
Bound Number: 1
Flags: 6
Vertices Indices: (4, 0, 1, 5)
Vertices Coordinates: [{-1.01,0.33,-2.07}, {1.01,0.33,-2.07}, {1.01,0.33,2.11}, {-1.01,0.33,2.11}]
Plane Edges: [{-0.00,1.00,-2.07}, {-1.00,0.00,-1.01}, {-0.00,-1.00,-2.11}, {1.00,0.00,-1.01}]
Plane N: {0.00,-1.00,0.00}
Plane D: [0.33]

:(

The game uses DDS files for textures.

It would be nice to have a function that can automatically convert multiple JPGs into a DDS format that Midtown Madness supports (including images that should be transparent).

The libraries PIL and imageio may come in handy for this.

The Editor currently uses the numpy library for vector operations in several geometric calculations, such as computing normals. While numpy is powerful, the custom Vector2 and Vector3 classes provide tailored methods that could enhance performance and reduce external dependencies.

For instance:

def compute_normal(vertex_1: Vector3, vertex_2: Vector3, vertex_3: Vector3) -> np.ndarray:
    v1 = np.array(vertex_2) - np.array(vertex_1)
    v2 = np.array(vertex_3) - np.array(vertex_1)
    normal = np.cross(v1, v2)
    return normal / np.linalg.norm(normal)

Could be refactored into:

def compute_normal(vertex_1: Vector3, vertex_2: Vector3, vertex_3: Vector3) -> Vector3:
    v1 = vertex_2 - vertex_1
    v2 = vertex_3 - vertex_1
    normal = v1.Cross(v2)
    return normal.Normalize()

While the README in the Setup folder is sound, it can be improved further by using markdown instead of a txt file.

Also, there are some edge cases in the installation process that should be documented.

For better readability and maintainability, some parts of the script should be split (e.g. class constants, or Blender related operators/panels). This will be a continuous WIP for the future.

The Wiki will include more background info about the Editor, as well as the older tools used for Map making.

Current Facade settings use distinct integer values for each condition, leading to potential overlap and confusion.

Converting the integer values to bitwise flags did not give the expected outcome/values, hence a review is needed.

In the current race configuration setup, when the same opponent car is selected multiple times for a specific race, only the last entry is processed. For example, if three Panoz GTR-1's are selected CIRCUIT 1, in-game, there will only be one GTR-1 appearing in the first circuit race. This issue stems from the way Python's dictionaries handle key-value pairs.

This should be fixed.

When adding a fresh polygon from blender, that isn't already in the standard example map included in the script, the rotations dont match the values that midtown madness has, causing them to rotate incorrectly when compiling a level with new polygons, based on blenders' coordinate values, and not midtown madness'.

Currently, when a polygon is set, it only works for one side / face.

The side is determined by the order and winding of the coordinates.

Setting double-sided polygons can be especially useful when users set vertical walls, such that both sides will have collision and textures.

This feature can be added as a parameter double_sided = True in the function create_polygon()

Reading and Writing the player's datafile (.sav) will enable users to customize their player profile.

This includes for example the PlayerName, LastCarPicked, LastRacePicked, among other variables.

In file are also records for individual races written, e.g. Dearborn Dash | 19.47 | Fati | Panoz GTR-1

This issue relates to issue Imperfect Generation of the Portals File.

For the game to properly render the cells, it primarily relies on a well constructed portal file.
In edge cases however, a .CELLS file is used to ensure certain cells are visible from other cells.

The contents of a .CELLS file are as follows:
Cell ID, buffer, flag, visit_count, visible_cells

36,462,0,0
37,462,0,0
39,462,0,3,37,239,8

Where in the example above, the game ensures that from cell 39, three additional cells will be rendered, with the cell index: 37, 239, 8.

The Map Editor relies on this method quite extensively, that is, generate a portal file as best as possible, and then make sure all cells are visible from each cell (users can make exceptions on this, always_visible: bool = False in create_polygon()).

Concretely, a line in the .CELLS file of a custom map may look like this:
1,8,64,38,99,201,861,202,1,862,203,2,863,204,205,...,...,...

Where 99 additional cells are visible from cell index 1 (the data line has been truncated for example purposes).

This method works well in practice, however the game's engine only reads the first 254 characters in each row.
This means that as the number of polygons (= cells) increases, the number of characters in each row will surpass the limit CELL_CHARACTER_LIMIT = 254, and subsequently crash the game.

To avoid this problem, the reading limit must be increased, likely involving reverse engineering functions in the Open1560 project.

Doing so will greatly expand the Map making capabilities. The geometry of e.g. Yoshi Falls from Mario Kart Wii has already been successfully imported in Midtown Madness, however, due to the visibility problem described above, the player only sees a fraction of the available polygon/cells, making the map unplayable. Only in the geometry-view (see below), the full map is visible.

Approximately the second half of the {map_name}_HITID.BND file consists of lookup tables.
These tables are crucial for optimizing collision performance by quickly determining the room/cell an object is located in.

Reverse engineering the table generator is challenging. The game engine generates these tables through a series of function calls as outlined below:

mmCullCity::Init --> asRenderWeb::Load --> mmBoundTemplate::GetBoundTemplate -->

mmBoundTemplate::Load      
(if (x_dim && y_dim && z_dim))

	mmBoundTemplate::MakeTable
		
		mmBoundTemplate::DoMakeTable 	

			mmPolygon::Plot
			
					mmPolygon::PlotTriangle
							
							Vector3::Swap
							swapf
							
							mmPolygon::PlotScan 
							
									j_clamp
									mmBoundTemplate::AddIndex

			mmPolygon::MaxY
			
					mmPolygon::CornersHeight
					
							sqrtf_fast_0
							mmPolygon::CheckCorner
							
					mmPolygon::CheckCellXSide
                    
					mmPolygon::CheckCellZSide

For more context, see the pictures below.

Chicago without a collision table:

Chicago with a collision table:

Visual representation of the collision table in-game:

When a player collides with a prop, the prop can "break" into multiple other (sub) props.

With the proper configuration, it should be possible to break a small bench into multiple huge trucks.

More info on this feature later.

Over time, several custom Blender Shortcuts were added to the Map Editor.

While all of them are functional, some keybindings may conflict with other (important) Blender operations (e.g., Shift + R or Ctrl + E).

In general, all keybindings should be reviewed, and during that process, they should also be grouped more logically.

The Blender Waypoint Functions have been designed with Vector from Mathutils, but this library is notoriously difficult to install outside Blender. So use existing Vector3 functions or implement new ones to replace the current Mathutils Vector present in the functions.

Normally, when hitting a bridge crossgate, the crossgate will split/break/fall into multiple smaller pieces

However, in custom maps (so far), the crossgate doesn't break when an object "collides" with it

No previous custom maps featured custom bridges, making it unclear whether the inconsistency originates from an incorrect bridge file or if custom maps inherently have limitations in some way

While the issue is relatively minor, it would be nice to have it solved in the future

Below are a few pictures below for more info / context

Coplanar vertices in perfectly vertical polygons are currently causing computational and collision detection issues (see e.g. polygon with bound number = 5).

NaN Outputs for Perfectly Vertical Polygons

POLYGON
    Bound Number: 5
    Vertices Indices: [50, 51, 52, 53]
    Vertices Coordinates: [{ -10.00, 0.00, -70.00 }, { -10.00, 30.00, -70.00 }, { 10.00, 30.00, -70.00 }, { 10.00, 0.00, -70.00 }]
    Plane Edges: [{ nan, nan, nan }, { nan, nan, nan }, { nan, nan, nan }, { nan, nan, nan }]
    Plane N: { 0.00, 0.00, -1.00 }
    Plane D: -70.0

Infinite Collision Height with Minor Z-Axis Deviation

POLYGON
    Bound Number: 5
    Vertices Indices: [50, 51, 52, 53]
    Vertices Coordinates: [{ -10.00, 0.00, -70.00 }, { -10.00, 30.00, -69.99 }, { 10.00, 30.00, -69.99 }, { 10.00, 0.00, -70.00 }]
    Plane Edges: [{ 1.00, -0.00, -10.00 }, { 0.00, -1.00, 69.99 }, { -1.00, -0.00, -10.00 }, { 0.00, 1.00, -70.00 }]
    Plane N: { 0.00, 0.00, -1.00 }
    Plane D: -70.0

Accurate Collision Detection with Larger Z-Axis Deviation:

POLYGON
    Bound Number: 5
    Vertices Indices: [50, 51, 52, 53]
    Vertices Coordinates: [{ -10.00, 0.00, -70.00 }, { -10.00, 30.00, -69.80 }, { 10.00, 30.00, -69.80 }, { 10.00, 0.00, -70.00 }]
    Plane Edges: [{ 1.00, -0.00, -10.00 }, { 0.00, -1.00, 69.80 }, { -1.00, -0.00, -10.00 }, { 0.00, 1.00, -70.00 }]
    Plane N: { 0.00, 0.01, -1.00 }
    Plane D: -69.998

Ideally, the user should be able to set coplanar vertices as this is more convenient in both Blender and in the editor. However, currently, this is not possible due to the issues mentioned above. Moreover, the offset is not arbitrary, adding either 0.2 or -0.2 will change the collision face. This issue requires additional investigation.

Since the game utilizes the same custom file formats (.BND and .BMS) for cities as for cars, extending the Editor's capabilities to include a workflow for designing and exporting drivable cars should be feasible.

Meticulous attention to detail should be applied in designing the Blender UI to ensure it is as intuitive and user-friendly as possible.

More information on this feature will be added as it is implemented step by step.

Similar to the issue of Implement mmPlayerData Class, implementing the mmPlayerConfig class enables users to customize their player configuration.

Especially setting the Audio volumes can be quite handy, as they're very loud by default. Additionally, setting the PhysicsRealism and MouseSensitivity is often preferred by players.

The picture below depicts the main portion of the config variables.

The Editor's race_data dictionary has already successfully integrated most of the fields from the game's AIMAP files. However, as ambient traffic is likely to become more commonplace in maps, users should also be able to set traffic path exceptions.

These exceptions, listing the path ID, density, and speed limit, will help users further customize their races.
Below is an example of how the AIMAP file looks:

# Ambient Traffic Exceptions
# Rd Id, Density, Speed Limit
[Exceptions]
7
648 0.0 45
646 1.0 60
644 0.3 45
647 0.3 45
152 0.0 45
153 0.0 45

It would be great if there was a road generator which creates sidewalks, light poles, trees and other stuff with the road we are creating.

The output that is obtained when debugging portals is incorrect.

Currently, we get this:

(7, 861, 10.00, -70.00, 9.90, -70.00)(2223, 2224, -156.59, -204.88, -191.82, -223.82)(203, 863, 93.01, 70.00, 140.00, 70.00) ... 

While we should get something like this:

PORTAL
    Flags: 2
    EdgeCount: 2
    Gap 2: 101
    Cell 1: 22
    Cell 2: 23
    Height: 50
    Min: (10, 0, 30)
    Max: (10, 0, 60)
	
...
...

This should be fixed.

When polygon data is imported, the custom Vertex Panel correctly displays the coordinates of a selected polygon's vertices. In addition, when a coordinate is changed in the panel, the polygon's shape updates accordingly (see picture one). However, there is an issue where the Vertex Panel does not update its values when a vertex is manually manipulated (e.g. via vertex snapping), as shown in picture two.

The coordinates in the Vertex Panel should reflect the polygon's shape consistently, regardless of the method used for manipulating vertices. This issue requires further investigation.

Currently, when importing waypoints into Blender, the flag is simply blue (1).

It would be nicer to apply the game's checkpoint texture to the flag instead. However, the original texture is of low resolution, and the text on the right side is vertically flipped (2). Additionally, to precisely match the game, the last waypoint for Blitzes and Races should have the 'Finish' texture. For Circuits, the first waypoint should have the 'Finish' texture applied to the flag.

(1)

(2)

Currently, a portals file is generated based on the polygon vertices used in the HIT_ID bound file. Portals are important for visibility of the map, among other things (e.g. the AI).

Issue one is that the height is disregarded during the construction of the portals (i.e. it is being set to y = 0).

The second issue is that the portal lines do not follow the curvature of the road in the current design process.
Typically, when modeling a road, a base quad is selected, and then extruded multiple times. For curved roads (as shown in the picture), triangulation is necessary to ensure correct collision generation. The picture clearly shows that the portal lines follow the shapes, and not the road's curvature (which is the intended behavior).

This issue needs to be further investigated.

Currently, bound polygons for all areas are consolidated into a single {map_name}_HITID.BND file.

This implementation differs from the original design, where spatial data was more granularly managed:

1. A primary reference polygon (or polygons) for each specific area / cell (e.g. cell 201) is defined.
2. Detailed polygons for these areas are stored in dedicated bound files (e.g., BOUND201.BND).
3. The {map_name}_HITID.BND file serves primarily as an index, directing the game to load detailed data from the appropriate BOUND file. Should a detailed file be missing, the game defaults to the (minimal) polygon data in _HITID.BND.

See the pictures below for more context.

HITID Polygons:

Separate Polygons:

The pedestrian skeleton files .SKEL are text-based and not written in binary

Hence, it should be relatively straightforward to customize the skeleton of different pedestrians and integrate them into the Map Editor

Below are a few pictures below for more info / context