FuncGodot: bringing Quake and Valve map formats into Godot 4

What FuncGodot actually does with a .map file

FuncGodot is a plugin for Godot 4 that generates Godot scenes using the Quake MAP file format and the Valve Map Format. In practice that means a level authored as brushes in a classic mapping editor arrives in Godot as an editable scene tree rather than as a flat mesh import.

The scene generation covers the things a brush level is made of. Meshes come from the brush geometry itself, materials and UVs are derived from the texture definitions in the map, and collision is produced as convex and concave collision shapes. That last point is the one that separates this from a plain mesh import: a static geometry importer would give you a visual mesh and leave physics to you, while FuncGodot produces collision volumes alongside the visuals.

The repository is small and shaped like a Godot plugin should be. The top level contains a LICENSE, a README, .gitattributes, .gitignore and a single addons/ directory, which is where Godot expects an editor plugin to live. There is no separate application, no command line tool and no build system of its own.

The project is a reworking and rewrite of the Qodot plugin for Godot 3 and 4, and the credits trace that lineage back further, to the original Qodot for Godot 3.5. That history explains a lot about the design, since the hard parts of a Quake map format are the entity and texture conventions rather than the brush geometry.

Format and palette coverage

Two map formats are supported, the Quake map format and the Hammer vmf format, and the palette side covers four container types:

map
vmf

WAD2
wal
WAD3
lmp

The palette containers are where the age of the format shows. WAD2 is the Quake palette archive, WAD3 is the Half-Life one, wal is the Quake 2 palette and lmp is the loose palette format. Supporting all of them means a level made in 1997 and a level made in a modern editor can both resolve their textures to real colours rather than to a flat grey.

Textures themselves live in the map as texture definitions, and FuncGodot reads the material and UV information out of those definitions. Brush faces reference texture names, and those names have to be resolved through the palette container and then interpreted as image data, which is where a converter usually falls over. The palette list in the README is therefore the honest measure of how much legacy content the plugin can actually open rather than a claim about formats it has never been tested with.

The README also links the Quake Map Format and Valve Map Format references on their respective wikis, which is where the classname and key value pair conventions the plugin relies on are specified.

Entity definitions: where the work actually goes

The entity support is the part of FuncGodot that goes beyond geometry, and it is the part that will take your time.

Entities are fully customizable and can be defined for map editors and then generated in Godot. The plugin builds on the map format's classname and key value pair systems rather than inventing its own, so the definitions read the way a mapper already expects. You define the visual and collision properties of brush entities on a per-classname basis, which is the mechanism behind the whole feature: a classname such as a light or a door gets the treatment you assigned to it.

Two more pieces matter for workflows that involve the map editor. The plugin can retrieve mesh metadata giving easy access to per face material information, and it can define point entities that are generated either from a node class name and script or from packed scenes. The packed scene route is the practical one when you already have a Godot scene you want to place in the level, since it lets the map reference your scene instead of generating something generic.

For the map editor side, the plugin exports GLB display models with the correct orientation and scale for point entities in editors that support GLTF, and it exports FGD, the Forge Game Data file that a mapper's editor uses to know which entities exist and what properties they take. The FGD export is what keeps a round trip sane: without it the map editor has no idea what your custom entities are.

The downside is equally clear. There is no ready-made entity library described here. Per-classname behaviour is yours to write, and a level that uses forty classnames means forty definitions, each of which is a place where the visual result and the collision result can disagree with what the mapper intended.

TrenchBroom and NetRadiant Custom integrations

A converter that reads map files is only half the problem. The other half is making the editor that produced them behave, so FuncGodot ships integrations in both directions.

For TrenchBroom, the recommended editor for most people, the integration covers a GameConfig export so the editor knows how to launch and interpret the game, brush and face tags so you can annotate brush entities and faces, and support for the model keyword with a scale expression, which is how a mapper places a model with the right size rather than the engine's default one.

For NetRadiant Custom the integration takes a different shape, appropriate to how that editor is configured: a gamepack export, shader definitions, and customizable build options.

The README lists four editors as confirmed compatible, TrenchBroom, Hammer, J.A.C.K. and NetRadiant Custom, and asks readers to help extend the list by testing their preferred editor and proposing compatibility solutions. That invitation is a reasonable signal about the state of coverage: four editors confirmed, others possible with work.

The distinction matters when you plan a pipeline. If your team maps in TrenchBroom and ships to Godot, the round trip is supported today. If your team maps in something else, the map may still import, but the editor-side conveniences, the tags, the config and the shader handling are what you are likely to be missing.

Getting the plugin and its documentation

The README does not give a command line install for the plugin, which is normal for a Godot editor plugin. The distribution point is the repository itself, and the plugin lives under addons/, so installing it means placing that directory into your Godot project's addons folder and enabling it in the editor.

For documentation, the README points to an online site for the FuncGodot manual and also offers a standalone copy of the manual as a release download, so the docs can be read without a network connection. There is an official Discord server for help and for contributing to the project.

Two things about the release scheme are worth knowing. Tags are named by year and month, FuncGodot 2025.12, 2025.9 and 2025.8.2, with the 2025.12 release dated 2025-12-28 and the 2025.9 release on 2025-09-02. So the version string in your project tells you the month the build was cut rather than a semantic version.

The last push to the repository was on 2026-10-12, so work on the plugin is current even though the most recent tagged release is the December 2025 build. That gap is typical of a plugin distributed by copying a folder into a project, and it means you should decide deliberately whether to track a tagged release or a development snapshot.

Limits: Godot 4 only, brush geometry only, no material pipeline

The boundaries are clear from the README, and they are the reason to read the feature list carefully.

The target is Godot 4. There is no Godot 3 support here, and the ancestor plugin for that era is Qodot, which the README says FuncGodot reworks and rewrites. If your project is still on Godot 3 you are reading the wrong tool.

The scope is brush-based levels. FuncGodot converts maps that were authored as brushes, and nothing in the feature list suggests it converts a Quake-engine .bsp into a Godot scene. If your existing content is a compiled BSP rather than an editable map file, the input side of this tool does not meet you where you are.

Materials and UVs come from the map texture definitions, and there is no mention of a material authoring pipeline, of PBR conversion from Quake texture properties, or of how the generated materials are then edited in Godot. Expect the output to need visual work after conversion, which is a given for any tool that carries 1990s texture conventions into a modern engine.

The release channel is also thin. There are no nightly builds, no published package on a language package registry and no migration notes between the year.month tags. Since the project is MIT licensed with no fee for use, the legal side is simple, but the upgrade story is copy the folder again and hope nothing moved.

FuncGodot against Qodot and against a plain glTF pipeline

There are two realistic comparisons, and they answer different questions.

Against Qodot, the difference is scope and lineage. Qodot for Godot 3.5 came first, Embyr ported it to Godot 4, and FuncGodot is the reworking and rewrite of that port, with contributions from the FuncGodot, Qodot, Godot and Quake mapping communities. So FuncGodot is the current branch of the same idea rather than a rival approach. If you already use Qodot, the practical question is what the rework changed, and the README does not itemise that, so the honest answer is to read the changelog and the manual rather than to take the rewrite on faith.

Against a glTF pipeline, the difference is that the two tools assume opposite authoring models. A glTF pipeline means your artists export finished, textured, lit meshes from a modern DCC tool, and Godot imports them directly. That pipeline produces better-looking results with far less configuration, because the exporter and the importer both understand the same conventions.

The brush pipeline assumes the opposite. A mapper works with convex volumes, face textures and entity classnames, and the value of FuncGodot is that it understands that world: it knows what a classname means, how a texture definition maps to a material, and how to produce collision shapes that match the brush volume. A mapper-authored level is faster to build for someone who thinks in brushes, and it carries over a level design that can be shared with a Quake engine game. What it cannot give you is the lighting, rigging and shading pipeline of a modern engine.

So the deciding question is not which tool is better but which side of that divide your content already lives on.

Editorial conclusion

Adopt FuncGodot when your art pipeline already produces brush-based map files and you want those levels in a Godot 4 project without rebuilding geometry by hand, and expect to maintain entity definitions yourself since per-classname behaviour is yours to configure. Do not adopt it for a project already built around glTF assets, or for Godot 3, since the plugin targets Godot 4 only. Verify first that your editor is on the confirmed compatibility list, that the map compiles in TrenchBroom or Hammer before you import it, and that the generated collision shapes match the brush volume you expect.

Frequently asked questions

Official sources

1. func-godot/func_godot_plugin on GitHub
2. Issues
3. License: MIT
4. README
5. Releases