Fast64: a Blender add-on for exporting Nintendo 64 display lists

What the plugin does, and the constraint that shapes everything

Fast64 is a Blender plugin that allows one to export F3D display lists, and it also has the ability to export assets for Super Mario 64 and Ocarina of Time decompilation projects. It supports custom colour combiners, geometry modes and similar settings, and the exported C code can also be used in homebrew applications.

The constraint that shapes the whole tool is the target. F3D is the display list format of the Nintendo 64, and the hardware it describes is not a modern GPU. It has a fixed texture memory, a specific way of combining texture layers, vertex colours rather than arbitrary material parameters, and a lighting model that works on a per-vertex basis. An artist working in Blender has to express their intent in those terms, and the plugin exists to translate.

That is why the material system is not optional. Any exported mesh must use an F3D Material, which can be added with the Create F3D Material button in the F3D material inspector, and the documentation says in caps that you cannot use regular Blender materials. If you have a model with Principled BSDF materials, there is a conversion operator that maps them automatically: the image in the Base Color slot becomes texture 0 and the image in the Subsurface Color slot becomes texture 1.

The version requirements are narrow in a way that reflects the Blender add-on ecosystem. The plugin requires Blender 3.2 through 5.1.2, and Blender 4.0 and later is recommended.

The project is a fork of the original fast64 by kurethedead, originally on BitBucket, and it has been carried forward since. The licence is GPL-3.0, the primary language is Python, the last push was on 2026-10-11, and the recent releases are v2.6.0 on 2026-09-01, v2.5.4 on 2026-08-11 and v2.5.3 on 2026-03-21.

Installing it in Blender, and the crash you should expect

Installation is manual and takes a moment, because Blender add-ons are installed from a zip rather than from a package index.

You download the repository as a zip file, then in Blender go to Edit, then Preferences, then Add-Ons, and click the Install button to install the plugin from the zip. You find the Fast64 add-on in the list and enable it. If it does not show up, you go to Edit, then Preferences, then Save and Load, and make sure Auto Run Python Scripts is enabled.

That last step is the usual cause of a Blender add-on appearing to install and then not being present. Blender blocks Python execution by default for security reasons, and an add-on written in Python will not load at all until that switch is flipped. The documentation flags it as a troubleshooting step rather than a warning, which is the right way to present something that catches everyone once.

The tools then live in the properties sidebar under a Fast64 tab, which you toggle open with the N key, and the F3D material inspector sits in the properties editor under the material tab.

Then there is the caveat that shapes your workflow, and it is worth reading before you start rather than after losing an afternoon of work. Make sure to save often, as this plugin is prone to crashing when creating materials or undoing material creation, and the README attributes the problem to Blender rather than to the plugin, linking a developer forum issue about it.

That is an honest and specific piece of engineering communication. The crash is in a documented Blender issue, it happens on material creation and on undo, and the workaround is autosave. The alternative, a conversion operator that avoids the crashy path for the common case of an imported model, is mentioned separately as the Principled BSDF to F3D conversion.

The repository also ships an updater, which can also be used to try out testing features and bug fixes, with instructions linked in the documentation.

F3D materials, vertex colors and the large texture mode

The material model is where the Nintendo 64 constraints show up, and the three features to understand are F3D materials, vertex colours and large texture mode.

Vertex colours work through a preset. You select a vertex coloured texture preset and add two vertex colour layers to your mesh, named Col and Alpha, and the alpha layer uses the greyscale value of the vertex colour to determine alpha. That is a direct reflection of how the console did transparency, and the naming convention is the same one the game code uses.

Large Texture Mode addresses the other big constraint. In F3D material properties you can enable it, and it lets you use textures up to 1024 by 1024 as long as each triangle in the mesh has UVs that can fit within a single tile load. Fast64 then categorises triangles into shared tile loads and loads the portion of the texture when necessary.

That is a workaround for a real limitation, and the condition on it is strict. Every triangle in the mesh must have UVs that fit within a single tile load, so a large texture only works if the mesh is laid out to suit it. Anyone planning a 1024 by 1024 texture needs to design the UV layout around that rule rather than discover it at export time.

The decomp and homebrew compatibility switch is the last of the three. There may be cases where code is formatted differently based on the code use case, and in the tools panel under the Fast64 File Settings subheader you can toggle homebrew compatibility. The distinction is between output that matches what the original decompilation expects and output that is freer for a new homebrew project.

And for projects still on the older material format, there is a migration path. A new optimised shader graph was introduced to decrease processing times for material creation and exporting, and to convert an old project you click the Recreate F3D Materials As V5 operator near the top of the Fast64 tab in the 3D view. It may take a while depending on the number of materials, and then you change the display mode in the outliner to Orphan Data, the broken heart icon, and click Purge in the top right corner, purging multiple times until all of the old node groups are gone.

glTF import and export, and the F3DEX3 feature set

Two extensions of the plugin go beyond the original scope of exporting display lists.

The first is glTF 2.0 support. Fast64 supports several glTF extensions that can be exported and imported via the glTF 2.0 io add-on integrated into Blender through hooks, and it also implements hacks for broken versions of that add-on. The current limitation is stated plainly: only basic N64 material properties and F3D properties are supported, but extensions for game modes like Super Mario 64 and OOT can be added in the future. The glTF README under the F3D directory has the details and the schemas.

The second is F3DEX3, which is modded microcode bringing many new features and higher performance. Fast64 supports exporting data for it, with an important caveat that preview of these new features in the 3D view is not currently supported, although they will be exported correctly. There is a separate trick for one specific combination: to modify the vertex colours of an object whose material uses packed normals, which is shading and lighting and vertex colours together, you temporarily switch to a vertex coloured preset or uncheck Lighting in the F3D geometry mode settings, and once the colours are painted as you want, you re-enable Lighting and Packed Normals.

Selecting F3DEX3 as your microcode adds a large number of additional presets, and the documentation lists them with abbreviated names, since the full preset names get very long. Shaded computes lighting, which normally affects the shade colour. Vcol means vertex colours are enabled in addition to lighting, and normally these are multiplied together to become the shade colour. Ao is ambient occlusion. Cel is cel shading, with a number giving the number of cel levels, and Ltcol loads the cel shading tints from the light colours. Blend versus Mul for cel shading is whether to apply the tint in the hardware blender with linear interpolation or by multiplication in the console, with the note that the latter sometimes looks better but does not support vertex colours. And Lerp versus Mult for multitexture, used for water, is whether the two textures are combined by linear interpolation or multiplication.

The recommendation for cel shading is to start with one of the cel shading presets and then modify the settings under the Use Cel Shading panel, hovering over each control for an explanation of what it does.

The project structure, and how development is set up

The repository is laid out as a Blender add-on with the internal packages under fast64_internal/.

The top level holds a .github directory, the .gitignore, a LICENSE.txt, the README, an __init__.py, two files named addon_updater.py and addon_updater_ops.py, the fast64_internal/ directory, an images/ directory, a pyproject.toml, and a scripts/ directory. The updater being two separate files at the top level rather than inside the package is a hint about where it came from, and the pyproject configuration confirms it: the Black configuration excludes the addon updater files with a comment saying the updater is copied from another repo.

The per-game documentation is inside the package. There are README files under the sm64 and z64 directories for Super Mario 64 and Ocarina of Time, and a glTF README under the F3D directory. The tool's own documentation site is at fast64.readthedocs.io, with pages for the updater and for the repository settings.

For development, the README points at a tutorial on using Visual Studio Code as an external IDE for writing Blender scripts and add-ons, to get proper autocomplete, and includes an unusual piece of advice: skip the linter for now, because the project needs to make sure the entire codebase is linted before enabling autosave linting, since the changes will be massive.

Formatting is handled with Black, version 23. You install it with pip install 'black>=23,<24', and you make VS Code use it by changing the python.formatting.provider setting to black. To format the whole repository you run black . from the root, or python3 -m black . depending on how it is installed.

The pyproject.toml holds the configuration:

[tool.black]
# Black configuration (code formatter)
# See https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html
# or `black --help` for what can go here

# Require black version to be 23.x.y
required-version = '23'
# Install such a version with:
# pip install 'black>=23,<24'

line-length = 120

target-version = [
    'py310', # used by Blender 3.1
]

The line length of 120 is longer than Black's default of 88, which is a deliberate choice for a project with long lines, and the target version of py310 is there for Blender 3.1 compatibility. There is also a Pyright section that sets reportInvalidTypeForm to none, which turns off a type-narrowing complaint that Blender's dynamic API would otherwise trigger constantly.

The credits name anonymous_moose, Cheezepin, Rovert, and especially InTheBeef for testing, and there is a Discord server for support and development.

Editorial conclusion

Adopt Fast64 if you are working on a Nintendo 64 decompilation project or writing homebrew and need a Blender authoring pipeline that produces real F3D output rather than a generic mesh. Do not adopt it for general 3D work, because the material system is specific to the console and regular Blender materials cannot be exported. Before you export anything, read the note about saving often, because the add-on is prone to crashing while creating materials, and check the Blender version range, since it requires 3.2 through 5.1.2.

Frequently asked questions

Official sources

1. Fast-64/fast64 on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases