# sollumz: a Blender add-on for GTA V asset creation

> Sollumz is a Python add-on for Blender that imports, exports and creates Grand Theft Auto V assets, covering the game's file formats for drawable geometry, physics, archetypes and maps. It targets modders who build models, interiors, animations and vehicles, and it depends on Blender 4.0 or newer.

**Sollumz/Sollumz** — Grand Theft Auto V modding suite for Blender. This add-on allows the creation of modded game assets: 3D models, maps, interiors, animations, etc.

- Repository: https://github.com/Sollumz/Sollumz
- Website: https://docs.sollumz.org
- Stars: 671 · Forks: 221
- Language: Python
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/sollumz-sollumz

## A Blender pipeline for the game's own asset containers

Sollumz is a Blender plugin to import, export, or create GTA V assets. The project description puts it plainly: it allows the creation of modded game assets, 3D models, maps, interiors, animations and the rest.

That places it in a specific position in the modding pipeline. The plugin is not a game runtime and not a tool for playing with the game's scripts. It is the authoring environment: you model or animate in Blender, and Sollumz moves the result into the file formats the game loads.

The people behind it are named in the README: Skylumz, Colton Fox and alexguirre, and the project has been developed with the CodeWalker contributors among its supporters. CodeWalker is also recommended as a companion tool, with the README pointing at the latest CodeWalker release from their Discord, which is the natural companion for inspecting the game's existing assets while you build replacements.

The documentation lives on a separate wiki at docs.sollumz.org, and the README is explicit that you should read the wiki before posting an issue or asking a question. Support itself is community-run, through a Discord server, and the issue tracker is reserved for bug reports and feature requests.

## Format coverage, and the one gap in it

The supported format list is short and concrete: YDD, YDR, YFT, YBN, YTYP, YCD, and YMAP, with YMAP marked as partial.

That partial mark is the most informative line in the list. Map work is the part of the game's asset set that depends most on the surrounding scene graph, the placement of entities and the streaming logic, so it is also the part where a Blender round trip is least complete. If your project is a map rather than a vehicle or a building, you should assume a larger manual share of the work than the format list suggests.

The formats themselves are not described in the README, so the honest reading of that list is coverage by container, not a claim about how much of each container's schema is modelled. A format appearing in the list tells you the plugin can read and write that file, and says nothing about whether every field inside it is exposed in the UI.

The general feature list is where you get the sense of the workflow: import and export, automatic texture loading, vertex colors, bones and weights, animations, custom normals, shader editing, vehicle creation and editing, and dynamic prop creation and editing. Automatic texture loading is the one that changes daily workflow most, since it removes the manual re-linking of image datablocks after every import.

## The repository is one package per format

The top level of the repository explains how the code is organised, and the answer is that the plugin is a set of format-specific packages sitting under a shared core.

Each format has its own directory: ydd/, ydr/, yft/, ybn/, ycd/, ymap/, ymap_next/, ynv/, ytd/ and ytyp/. The ymap_next directory sitting next to ymap is the visible edge of the partial map support mentioned above, since it suggests work toward the newer map format alongside the existing one. Then there is shared/ for code common to the formats, editor_tools/ for the Blender editor integration, cli/ for command line entry points, tools/ for supporting utilities and versioning/ for version handling.

The Blender-facing surface is spread across the usual addon files. auto_load.py and __init__.py handle registration, dependencies.py resolves Python packages, and then a flat set of modules carries the addon proper: sollumz_operators.py for the operators, sollumz_properties.py for the custom properties that store Sollumz data on Blender objects, sollumz_ui.py and tabbed_panels.py for the interface, known_paths.py and meta.py for locating game files and metadata, lods.py for level of detail handling, and logger.py and sollumz_debug.py for diagnostics.

The flat module layout with a shared/ directory underneath is a common pattern for Blender addons, and it means the format packages are largely independent of the editor layer.

## Getting it running, and the pinned Python environment

Installation is not described in the README itself. It points to the installation instructions on the wiki at docs.sollumz.org, and the stated requirements are Blender 4.0 or newer plus, as a recommendation, the latest CodeWalker release.

The Python side of the project pins its development dependencies in a requirements file, which is also the clearest statement of what the test setup needs:

```bash
fake-bpy-module-latest==20230904
numpy==1.23.5
pytest==9.0.2
pytest-blender==3.0.7
pytest-cov==7.0.0
```

The fake-bpy-module entry exists so that the Blender API can be type referenced outside Blender, and pytest-blender is the harness that runs tests inside a real Blender instance. numpy is pinned to a specific version rather than a range, which is the usual way to keep a numeric dependency from breaking a plugin that links against a bundled copy.

Two details are worth planning around. Blender 4.0 is a hard floor, so an older Blender install will not work at all. And the pinned versions mean the plugin is developed against a frozen toolchain, so when you pull a newer release, the requirements may move with it.

## Linting, typing and release automation in pyproject.toml

The project configuration is small and reveals how the code is checked. The pyproject file carries four tool sections:

```toml
[tool.ruff]
line-length = 120
indent-width = 4

[tool.black]
line-length = 120
```

Ruff is configured for a 120 character line length and 4 space indentation, and Black is configured with the same line length and double quote style. The formatting settings are consistent between the two tools, which is the practical way to keep a linter and a formatter from arguing about the same files.

The basedpyright section sets typeCheckingMode to off. That is a deliberate choice rather than an oversight: the plugin is a large dynamic codebase built on Blender's Python API, and turning off strict type checking keeps the annotation effort focused on the parts that benefit from it. It also means the type checker will not catch a wide class of mistakes for you, so the pytest suite carries more of the verification weight.

The release side of the repository is equally script-driven. prepare_release.ps1 is a PowerShell script for preparing a release, cliff.toml configures a changelog generator, blender_manifest.toml is the manifest format Blender expects, and versioning/ holds the version handling. The setup.cfg, pyproject.toml and .gitattributes round out the packaging.

## Version history, licence and the shape of the project

The release line is versioned and recent: v2.8.2 published on 2026-02-08, v2.8.3 on 2026-03-17, and v2.9.0 on 2026-08-04. The last push to the repository was on 2026-10-18, so the working tree is ahead of the newest tagged release, which is normal for a project that ships through a wiki-guided install rather than a package index.

The licence is the GNU General Public License version 3, and the copyright line reads 2020-2025 Skylumz, Colton and alexguirre. For a Blender add-on that is the conventional choice, and it means a distributed build of the plugin carries the same obligations, including passing on the source of modified versions.

A community project also has a support policy, and here it is unusually explicit. The issue tracker is for bug reports and feature requests only, and the README tells you that if you are not sure whether something is a bug, you should ask on the Discord first. The wiki host is GitBook, and the project is funded through Open Collective and GitHub Sponsors alongside code contributions.

The repository also carries a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and a tests/ directory, which for a format-heavy plugin is the most useful signal about whether a change is safe to pull in.

## Conclusion

Adopt sollumz if you are producing geometry, physics or archetype data for Grand Theft Auto V inside Blender and want the game's container formats handled by a tool with a test suite and a versioned release line. Skip it if your work targets a different game, if you need complete map support, since YMAP is listed as partial, or if you are on Blender 3.x, since the requirement is 4.0 or newer. Before your first export, read the wiki installation page, install the pinned development requirements, and check the release notes for the version you are on, because v2.9.0 shipped on 2026-08-04 and the last push was on 2026-10-18.

## FAQ

### What does the sollumz Blender plugin do?

It imports, exports and creates Grand Theft Auto V assets inside Blender, including 3D models, maps, interiors and animations. Supported formats listed in the README are YDD, YDR, YFT, YBN, YTYP, YCD and YMAP, with YMAP marked as partial.

### What are the requirements for using sollumz?

Blender 4.0 or newer is required, and the latest CodeWalker release is recommended as a companion tool. The README sends you to the installation page on the wiki at docs.sollumz.org for the install steps themselves.

### How is sollumz tested?

The repository has a tests/ directory and the pinned development requirements include pytest, pytest-blender and pytest-cov, along with fake-bpy-module for referencing the Blender API outside Blender. Ruff, Black and basedpyright handle the style and static checks in pyproject.toml.

### Can I report a problem with sollumz on GitHub?

The issue tracker is reserved for bug reports and feature requests, and the README asks you to use the Discord server first if you are unsure whether something is a bug. The wiki is the intended place to look before opening an issue.

## Sources

- [License: GPL-3.0](https://github.com/Sollumz/Sollumz/blob/main/LICENSE)
- [Project website](https://docs.sollumz.org)
- [README](https://github.com/Sollumz/Sollumz/blob/main/README.md)
- [Releases](https://github.com/Sollumz/Sollumz/releases)
- [Sollumz/Sollumz on GitHub](https://github.com/Sollumz/Sollumz)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sollumz-sollumz