Zbrush Copy-Paste

Download page - gumroad

ZBrush OBJ Export - subtool name problem!

As many of us know, ZBrush fails to preserve subtool names when exporting to the .OBJ format. All your nicely named subtools end up as just GroupXXXX, which is incredibly frustrating—especially when you need to maintain a strict naming convention for projects and baking workflows, where myModel_1_HP and myModel_1_LP must match.

I’ve personally spent a lot of time manually fixing these names every time I import an OBJ into another 3D program. When working with a complex model containing dozens of subtools, this becomes an unnecessary time sink. I don’t want to fix it manually every single time.

So, I started investigating and discovered that ZBrush has never preserved subtool names in OBJ exports—it simply doesn’t write them into the file.

Since I have experience with ZBrush plugins, I decided to fix this issue as part of my CopyPaste plugin. The fix itself is ridiculously simple—just a few lines of code to write the subtool name into the OBJ file. When the OBJ is written to disk, my plugin parses the file and injects the correct subtool name where it belongs.

use std::fs;
use std::path::PathBuf;
use std::fs::File;
use std::io::Write;

pub fn read_file(path: PathBuf) -> String {
    fs::read_to_string(&path).unwrap_or(String::from("Cant read file"))
}

pub fn name_inject(content: String, subtool_name: String, file_path: &str) -> String {
    /*
        Pattern search where to inject name
        - we injecting name before first vertice position
        pattern = 'v ' which include one space symbol
    */
    let subtool = subtool_name.replace("\\", "/")
        .rsplitn(2, "/").next().unwrap_or("")
        .splitn(2,".").next().unwrap_or("").to_string()
    ;

    let pattern = "v ";
    let shape_name = format!("o {}\n", subtool).clone();
    let transform_name = format!("g {}\n", subtool).clone();

    let cleaned_content: String = content
        .lines()
        .filter(|line| !line.starts_with("g "))
        .collect::<Vec<_>>()
        .join("\n");


    let mut modified_content = cleaned_content.to_string();

    if let Some((index, _)) = cleaned_content.match_indices(pattern).next(){
        modified_content.insert_str(index, shape_name.as_str());
    } else {
        return String::from("g injection feild")
    }
    if let Some((index, _)) = modified_content.match_indices("f ").next(){
        modified_content.insert_str(index, transform_name.as_str());
    } else {
        return String::from("g injection feild")
    }


    let mut file = File::create(file_path).unwrap();
    _ = file.write_all(modified_content.as_bytes());
    return String::from("1")
}

Fixing the Polygroup Issue

Additionally, this fix also addresses a long-standing issue with Polygroups. Normally, if you have a connected mesh with two Polygroups assigned, ZBrush exports hundreds of separate groups instead of just the two original ones. This results in a total mess when importing into Maya, where a single mesh turns into hundreds of separate polygon groups.

This happens because ZBrush assigns groups based on vertex order, which can be totally random. Instead of writing groups like this:

Polygroup 1 ->
g group1
f 1
f 3
f 4
f 59

Polygroup 2 ->
g group2
f 2
f 5
f 6

ZBrush writes them in sorted vertex order. Because of this, you can’t write them in a different way; otherwise, the mesh will break if you change the order without keeping it sorted.

Polygroup 1
g group1
f 1
g group2
f 2
g group1
f 3

As a result, we get a ton of extra groups, causing imported meshes to be a chaotic mess in Maya. While this isn’t an easy fix, my workaround simply removes all unnecessary groups from the OBJ and assigns only one group matching the subtool name.

Why Hasn’t Pixologic Fixed This?

Honestly, I have no idea why the ZBrush team has never fixed this. It’s such a simple fix! I respect Pixologic for their amazing tool, but maybe artists just don’t care about this issue as much as I do. Still, when you’re paying for software, things like this should work properly. Maybe the developers just never noticed or didn’t consider it important.

I really hope future ZBrush updates will fix this problem, making my plugin’s fix obsolete. But for now, my solution will save you time and frustration—finally, your imported meshes won’t turn into a naming mess.

What About GOZ?

Yeah, I know about GOZ, but it’s never worked properly for me in the past 10 years. I don’t know why, but I’ve never managed to get it to work the way I need. And honestly, I don’t always want to use it anyway.