Quake3 support

Some resources:

Map Format

• http://forums.ubergames.net/topic/2658-understanding-the-quake-3-map-format/ (patchDef2 and brushDef)
• http://forums.thedarkmod.com/topic/15668-plugin-request-save-map-in-quake-3-format/ (some examples)

MD3 Format

• https://icculus.org/~phaethon/q3a/formats/md3format.html

Shaders

• http://toolz.nexuizninjaz.com/shader/

PK3 Files

• https://github.com/tfussell/miniz-cpp (lightweight zip library)

Todos

• Add support for pk3 files
• Add support for Q3 map files (skip patches and brush primitives)
• Add support for Q3 shaders
• Add support for brush primitives (brushDef)
• Add support for patches (patchDef)
• Add support for md3 models

[tapir]

What's needed for this? What are the main differences between a Quake 1 and Quake 3 *.map file?

[kduske]

I am not quite sure, but I think the main differences are the patches. But apart from that, the following things are necessary:

• Loading and writing Quake 3 map files
• Loading Quake 3 models
• Loading Quake 3 textures / shaders
• Rendering Quake 3 textures and shaders
• Rendering patches
• Editing support for creating and editing patches
• Editing support for additional face attributes?

However, the current source of TB is not easily extended for multiple games. I am in the process of creating a version that will support adding games much more easily.

Are you interested in helping out? If so, I will happily let you know once I get to a point where support for additional games can be added to the editor.

[tapir]

Yes, please let me know. Is there a repo yet for the version you're working on? I'm guessing NewArchitecture branch?

[kduske]

Yes. It's a complete rewrite because the source code of the current version is too hard to maintain and refactor (bad structure, no unit tests, too many dependencies). I will report here as soon as there is something usable.

[motorsep]

I don't think having bezier patches is critical. They are nice to have, but not critical at all.

[motorsep]

Note that how brushes are defines in q3map format is different from q1map format. Same goes for textures and brush flags.

Also q3map2 compiles ASE/MD3 models into BSP tree, so levels can be made of models essentially (or rather mix of brushes and models, since models don't block visibility during VIS stage)

[kduske]

How are brushes defined differently? I thought they were still a list of faces which are made up of planes defined by three points. I realize that the texture and surface attributes are different, though.

[motorsep]

Yeah, I mixed it up with Doom 3 brushes, which are defined a plane and a normalized normal vector.

Here is comparison map files of Quake 1 and Quake 3 (structural and detailed brushes, both have alternative texture projection, e.g. brush "faces" order is different from standard texture projection)

http://pastebin.com/dCGEF2N5

[kduske]

Thanks, I think it's similar to Valve 220 map format where the texture axes are stored in the face definitions as opposed to being dependent on the face normal as in standard Quake.

[motorsep]

This is how same cube looks like in Doom 3 .map format: http://pastebin.com/TpKQRMjP

I can open a separate issue for Doom 3 map design if you wish. One thing about Doom 3, is that all the entities are read directly from <game_folder>/base/def/ (DoomRadiant and DarkRadiant do that). This way as we add stuff to the game, it automatically pops up in the level editor when we run it.

Same goes for other decls.

[kduske]

Yes, please open a separate issue for Doom3.

[barnabyc]

👍 Would still love Quake 3 support!

[motorsep]

I just remembered issue that plagues Radiants editors - precision loss. As designer works on a map, and keeps saving/loading it, without snapping brushes to grid (Ctrl G), eventually planes coordinates go out of whack and gaps between brushes begin to show when playing the level.

NetRadiant has an option that allows automatic snapping to integer values of the grid on every brush operation, on save and load. This ensures that coordinates for brush planes are always integer and never get to be floats, accumulating rounding off error with every save/load cycle.

DarkRadiant doesn't have this, making it difficult to keep track of snapping and that adds additional level of complexity to the workflow.

Is there anything like that in TrenchBroom ?

[kduske]

Yes, TB can keep all plane points on integer coordinates. It will usually find "better" plane points than radiant will if by rounding, too. But TB should store floats with enough precision that there should be no loss going on during save / load, anyway.