GoB, the Blender extension that pulls meshes and polypaint back from ZBrush

The interchange problem GoB exists to solve

A digital artist working in ZBrush and Blender hits the same wall repeatedly. Sculpting happens in ZBrush, layout and assembly happen in Blender, and every sculpt session ends with a manual round trip of exported geometry that loses information on the way. GoB is described as a "GoZ-alike" tool for exactly that swap, and the list of what it transfers is specific: objects, but only meshes, plus polypainting, UVs, a mask, FaceSets, polygroup, and the diffuse, normal and displacement maps.

That list is the useful part of the pitch. Polypaint and masks travel alongside the geometry, which means the colour work and the selection data do not have to be reapplied by hand in Blender. For a user who has done this transfer manually, the value is not the mesh itself, which any exporter can move, but the layers around it.

Who it fits is a desktop artist on a single machine, working locally with a local copy of ZBrush and a local copy of Blender. There is no server, no account and no network component in the repository layout. The trade-off is that this is a pair of cooperating applications on one workstation, which is also its limit: nothing here is designed for a render farm, a build pipeline or a version control system.

The README does not describe a licensing model for the exchange itself, a file format for the session, or any way to run the transfer from a script. What it describes is an add-on with buttons.

GoB is a maintained fork of a script that started on ZBrushCentral

The repository description is blunt about its own status: "Fork of original GoB script (I just added some fixes)". The acknowledgement section names the original author, user "Stunton", and links the ZBrushCentral thread where the script was first posted, described in its title as an unofficial GoZ for Blender. A second link points to the Blender wiki page for the Import/Export add-ons category, where the author is listed as "ODe".

Those two credits matter for anyone deciding whether to use this. You are installing somebody's fork of somebody else's script, and the fork is maintained by a single person who describes the changes as fixes rather than a redesign. The original code was published as a Blender 2.6 era add-on, and the wiki location reflects that era. The fork exists because the add-on system itself moved on.

The licensing follows the code. The repository is GPL-3.0, which is the right licence to check before you fork the fork yourself. GPL-3.0 is a copyleft licence, so if you modify GoB and distribute the modified version, the obligations travel with the distribution. For a solo artist who installs the add-on and never touches the source, nothing about that changes how the tool behaves. For a studio that plans to patch the fork and share the result internally or publicly, the licence is the part of this project that deserves a real reading.

The upstream links are still in the README, which is a small courtesy in a fork. It tells you where the code came from and gives you a place to check whether the original author addressed the same problems the fork claims to fix.

The code is split by concern: geometry, nodes, paths, preferences

The repository layout shows how the add-on is put together, and it is a recognisable modern Blender extension rather than a single monolithic script. The top level holds an `__init__.py` and a `blender_manifest.toml`, which is the extension manifest Blender reads when you install from disk. Alongside them sit focused modules: `gob_export.py`, `gob_import.py`, `geometry.py`, `nodes.py`, `paths.py`, `preferences.py`, `ui.py` and `utils.py`. There is also a `Blender/` directory, a `ZScripts/` directory, an `icons/` directory, and a `tests/` directory.

The module names line up with the three halves of the work. The export and import sides have their own files, `gob_export.py` and `gob_import.py`. `geometry.py` and `nodes.py` cover the scene data side, with `nodes.py` pointing at the shader node graph that carries the texture maps. `paths.py` and `preferences.py` handle where files live and how the add-on is configured, and `ui.py` is the panel code.

The `ZScripts/` directory is the part that shows this is a two-application tool rather than a pure Blender plugin. ZBrush has its own scripting side, and shipping scripts alongside the Blender extension means the transfer is a conversation between the two programs rather than a one-directional file write. The `icons/` folder is what supplies the Import and Export icons that appear in the top info panel, and the presence of a `tests/` directory at least means the project has a place to put automated checks, though the README does not describe what they cover or how to run them.

One detail worth noting for anyone reading the layout: the default branch is `master`, and the `Blender/` directory sits next to `ZScripts/` rather than inside them, so the two sides of the bridge are kept in separate trees.

Installing it means downloading a release zip and using install from disk

The setup sequence is written for people who already have both applications open, and it is worth following in order because the install path has changed across Blender versions. The first step is to download the latest "Source code (zip)" from the repository's Releases page. The wording matters: it is the source code zip, not a packaged installer, and the releases are named with an underscore format such as `v4_5_3`.

In Blender, the path is Edit > Preferences > Get Extensions. If a previous version of GoB is installed, the instructions say to find it in the extensions list, open the drop-down menu on the right of that entry and choose uninstall, which avoids the two copies of an add-on fighting over the same buttons. Installation then happens through the drop-down menu in the top right of the extensions window, where you pick install from disk and select the zip you downloaded in the first step. After that, GoB appears under Edit > Preferences > Add-ons, where its settings live.

So the whole flow is: zip from Releases, uninstall any older copy, install from disk, then configure under Add-ons. There is no pip install, no package index and no build step in the documentation, which is convenient until you hit a problem, because a failed install from disk gives you very little to go on. The README has no troubleshooting section and does not record which Blender version the add-on targets or which ZBrush version the scripts in `ZScripts/` expect.

If the install fails, the two things to check first are the file you selected and the manifest, since `blender_manifest.toml` is what Blender reads to decide whether the zip is a valid extension. A zip produced by GitHub's own source code download is not always the same artifact as a release asset, and this project documents the former.

Three buttons in the top info panel drive the whole transfer

Operation is entirely through the viewport. The add-on adds icons to the top info panel, and the README describes three controls on them. The Export icon exports the selected mesh objects into ZBrush. The Import icon toggles autoloading mode, which makes Blender automatically load any model exported from ZBrush via GoZ. A Manual icon performs a one-time import of the most recent model exported from ZBrush via GoZ.

The autoload mode is the feature that changes the working rhythm. With it enabled, the artist does not file-browse or re-import anything: the ZBrush side sends, and Blender updates. That is the behaviour that removes the tedious part of the round trip, and it is the reason the tool needs both applications running at once.

The Manual icon is the escape hatch, and it is worth knowing it exists before you enable autoload and then wonder why a sculpt update did not appear. It pulls in the most recent export on demand, once, without changing the autoload state.

The scope limits are visible here too. Export works on the selected mesh objects, so non-mesh data, such as curves, lattices or lights, is not part of the exchange. The features listed in the documentation, polypaint, UVs, mask, FaceSets, polygroup and the three maps, describe what travels with a mesh, not what happens to other object types.

There is no documented option for a partial or filtered export, for choosing which layers travel, or for a resolution or format setting. If you need to control which of those layers are included, that control is not in the interface as described.

Where GoB stops: mesh only, one workstation, no scripted path

Three constraints define the boundaries, and all three come straight from what the documentation does and does not say.

The first is the object type. Objects transfer as meshes only, and that restriction is stated in the feature list. A workflow that relies on moving any other object type, or on preserving non-mesh scene data through the exchange, is outside what this tool does.

The second is the deployment model. The add-on is installed into one Blender profile on one machine, and the ZBrush side is a set of scripts in `ZScripts/`. There is no documented headless mode, no command line entry point, and no description of running the transfer as part of an automated batch job. For a solo artist this is irrelevant. For a studio that renders a queue overnight, or wants the sculpt step in a farm, there is nothing here to hook into.

The third is documentation depth. The README is short. It lists features, gives the install steps, and explains the three buttons. It does not state which Blender versions are supported, which ZBrush versions the scripts target, what to do when the autoload connection fails, or whether the transfer is safe when the two applications hold the same file open. It also does not mention whether the mask and FaceSet data survive a round trip in both directions, or only inbound.

The honest reading is that this is a working tool with thin documentation, and the thinness is where a new user will lose the most time. The tests directory in the repository suggests someone is thinking about verification, but nothing in the README tells a user how to run it.

Release naming tells you the fork is tracking Blender's extension system

The release history reads like a project that exists to keep an old add-on usable. The three most recent releases are `v4_5_1` on 2026-08-30, `v4_5_2` on 2026-09-11, and `v4_5_3` on 2026-09-16. The last push to the default branch was on 2026-09-16, and the repository is not archived, so the fork is receiving work.

The version numbers line up with Blender's own extension versioning scheme rather than with anything in the feature list, which supports the reading that the fork's job is compatibility. The gap between `v4_5_1` and `v4_5_2` is twelve days, and between `v4_5_2` and `v4_5_3` is five days. That is a short cycle, so the practical cost of staying current is low for a user who only installs from disk, and the risk of falling behind on a compatibility fix is real for a user who does not.

The upgrade path itself is the install path, which is a nice property of a zip based extension. You download the new zip, install it from disk, and the old copy is replaced. There is no database migration or configuration file to reconcile, though the documentation does warn you to uninstall a previous version first when setting up, and doing the same thing on each upgrade keeps the extensions list clean.

The two consequences for an adopter are worth spelling out. First, with releases in the 4_5 range and no stated Blender support matrix, the responsible check before you install is to open `blender_manifest.toml` in the release you plan to use and see which Blender version it declares. Second, because the project has no GitHub releases history of substance beyond these recent tags, and the upstream script predates the extension system by a long way, you should assume the fork, not the original, is the thing that will keep working.

The alternative is ZBrush's own sender, and the real difference is scope

The comparison to make is not with other Blender add-ons. It is with the GoZ route the project is named after. The README calls GoB a GoZ-alike and refers to models exported from ZBrush via GoZ as the source of what its own import buttons read, which means the built-in sender is a genuine alternative path for the same job. The documentation does not set out what the built-in sender covers, so the honest comparison is limited to what GoB itself claims.

The difference in approach is that GoB arrives as a Blender extension you install from disk and configure in your preferences, and it presents its transfer as three specific controls in the top info panel, with autoload as the default mode of working. It claims support for a particular set of layers alongside the mesh: polypaint, UVs, mask, FaceSets, polygroup, and the diffuse, normal and displacement maps. If your pipeline depends on those layers surviving the move, that claim is the reason to try GoB rather than whatever your ZBrush installation offers out of the box.

The other alternative is the manual one. Export the file from ZBrush, import it into Blender, relink the maps, redo the selection data. For an occasional asset this costs minutes, and it costs nothing in setup, nothing in compatibility risk and nothing in maintenance. GoB only becomes worth the install if the transfer happens often enough for the repetition to add up.

One thing to keep in view is the difference in risk profile. A manual round trip cannot break your session. An extension with autoload enabled, running against a second application, changes what happens in your working files while you work, and this project documents no recovery path for a failed or partial transfer. That is the trade you are making: convenience and layer fidelity against a moving target that a single maintainer keeps patching.

Editorial conclusion

GoB is worth the setup time for a solo artist or a small studio that works in Blender for assembly and in ZBrush for sculpting, since the alternatives are manual re-imports or relying on the sender that ZBrush ships with. It is the wrong tool for a pipeline that needs automated batch transfers, a maintained upstream project, or anything beyond meshes, because the fork supports mesh objects only. Verify three things before adopting it: which Blender version your copy of the extension targets, whether your ZBrush setup matches the scripts in the ZScripts directory, and whether the release zip you download matches the v4_5_x naming the repository uses. The code is GPL-3.0, so a modified copy that you distribute carries the same licence obligations as the original.

Frequently asked questions

Official sources

1. Issues
2. JoseConseco/GoB on GitHub
3. License: GPL-3.0
4. README
5. Releases