mildred / t3d2map

Convert WhelOfTime / Unreal1 maps in t3d to something else
2 stars 1 forks source link
conversion quake-engine t3d unrealegine wheel-of-time

t3d2map

Convert WhelOfTime / Unreal1 maps in t3d to Valve .map files

Work in progress... The issue with this conversion is that map files are only composed of convex brushes while Unreak/t3d starts with a filled world and use CSG operations to excavate from it resulting in mostly concave geometry. This converter makes use of CGAL algorithms to achieve this.

map file created with Unreal 1 engine and opened in TrenchBroom

This is however a very heavy work even for very simple maps because CSG and triangulation create many many vertices and there is no optimization. Perhaps a better solution would be to parse Unreal compiled maps and extract the BSP tree which already contains a stream of convex polygons ready to be imported in any other engine without running costly CSG.

This repository makes use of CGAL to perform the CSG to get the concave mesh. This in itself is error prone because the concavity of Unreal Engine maps is very concave. Also planes that splits zones cannot be represented. Then there is an improvized BSP cutting algorithm (cut at random places until there are no more concave meshes) that is very inefficient.

T3D file format stores the CSG tree but the compiled Unreal Engine maps have the pre-computed BSP tree that might be exported. This would be a better strategy. See https://www.acordero.org/projects/unreal-tournament-package-tool/ which can open Unreal Engine Packages and view polys.

C++ Build

Conan build does not work because of conan v2, until it works, ensure CGAL is installed system-wide. Once it works, perhaps this will be how to install the CGAL dependency:

conan profile detect --force
conan install . --output-folder=build --build=missing

Build with CMake:

cmake .
make

Run

Use:

./t3d2map ./examples/test.t3d

Or:

make && rm -f dbg_*.obj && ./t3d2map --debug-mesh --convert ../WoT-conversion/textures/CONVERSION --game WoT -o examples/test.map examples/test.t3d

Or:

make && for t3d in ~/Games/wineprefix/WoT/drive_c/*.T3D; do ./t3d2map --obj "${t3d%.*}.obj" "$t3d"; done

Usage

The --game flag is only used to populate the // Game: xxx at the top of the file to ensure TrenchBroom pick up the correct game settings when opening the file.

The CONVERSION file via the --convert flag is a file containing a texture for each line. For each texture it has 3 fields separated by spaces:

example:

BannWall1918 textures/AesSedaiT.utx AesSedaiT.utx/BannWall1918
BannWall1919 textures/AesSedaiT.utx AesSedaiT.utx/BannWall1919
BookBook1752 textures/AesSedaiT.utx AesSedaiT.utx/BookBook1752
BookBook1755_m textures/AesSedaiT.utx AesSedaiT.utx/BookBook1755_m

Roadmap:


CGAL algorithm

Note: I believe there is no way to have face properties in a Nef_Polyhedra. Given this limitation there are two options:

General algorithm:

resources

.map file format

T3D format:

Convex decomposition:

Boolean operations:

tools:


UV Mapping

T3D format defines UV mapping for each face with 2 vectors (U, V) and 2 numbers (UPan, VPan). Both U and V must be orthogonal to the face normal vector (hence be "coplanar" with the face). The 2D point defined by U and V represents the origin on the 2D texture coordinates (pixels). U=2 means that the texture starts at the 3rd pixel on the left.

The texture is applied to the face such that on 3D space the U vector represents the horizontal axis of the texture image, and the V vector represents the vertical axis. For a texture not to be deformed the U and V vector must be orthogonal. The length of the vectors represents the length of the texture. A unit vector represents the full width or height of the texture.

The .map format represents convex meshes with a set of intersecting planes, each plane represented by 3 points (not necessarily on the surface mesh) organized so the normal vector points out. Original texture information was subject to incoherences so Valve updated the format to remove all ambiguity.

Quake standard format for UV mapping represents for each face after the texture name real numbers for : X offset, Y offset, rotation, X scale, Y scale. Texture are applied naturally on faces that are orthogonal to the X, Y or Z axis. If a face is not orthogonal to the X, Y or Z axis, the texture will be stretched in some way.

Valve texture format represents UV mapping after the texture name with: