MeshSynergy: A Character Pipeline Layer Built for Production

TLDR: MeshSynergy is the name I use for the ecosystem of tools, assets, and working methods that have crystallized around the way I build characters. None of it started as a product. It started as the accumulated residue of fifteen-plus years of character work across studios, across project types, across the same coordination problems hitting me over and over in slightly different shapes, until at some point I noticed I was writing the same short scripts to patch the same gaps on every job, and that those gaps were not only mine. The BaseMesh began in 2016, and the same year I shared it with Disney Animation alongside LandmarkManager so the character team could standardize mesh usage across departments. As far as I know, that same base mesh is still in use there. The tools arrived one at a time, each from specific production friction I kept hitting on my own projects: MeshManager, CreaseManager, and LandmarkManager. All built solo, on my own time, on my own hardware, alongside full-time roles. The working method the tools encode is the one I still use on every character I build.

DETAILS

• Studio: SergiCaballerStudio LLC

• Project: MeshSynergy (BaseMesh + Maya Python tools + educational content)

• Role: Founder, Designer, Developer (solo)

• Tools: Maya, Python, ZBrush

• Year: 2016-present

• Shipped: MeshManager (pipeline backbone, stable), CreaseManager (crease workflow across Maya and ZBrush, stable), LandmarkManager (semantic regions across Maya and ZBrush, stable), ToolsBundle pricing architecture, Gumroad storefront, meshsynergy.xyz site.

• Links: MeshSynergy site, Gumroad storefront

THE CONTEXT

MeshSynergy is the only project on this site where I was the brief, the director, the modeler, the engineer, the marketer, and the support channel all at once, and where the budget was whatever hours I had left after a full-time role at Disney and later at Meta.

The origin is older than the brand. For over fifteen years, through features at Kandor, Aardman, and Disney, through a collectibles run at Riot Games, through the move into real-time platform work at Meta, I kept running into the same category of coordination problem on every character project. Not the topology itself, and not the creative work. The connective tissue around them. Crease data dropped between Maya and ZBrush. Mesh metadata (vertex IDs, symmetry maps, UV correspondence) reset when files moved between tools. Semantic regions for the face or body defined three different ways by three different departments on the same character. Every studio solved these internally, every freelancer solved them from scratch, and every time I hit one of them I would write a short script to patch it, file it on my own drive, and move on.

In 2016, two things happened in parallel. I finalized the first production-ready version of what would become the BaseMesh, a biped topology built for stylized character work with the deformation behavior, UV discipline, and subdivision behavior I had been refining across studios for over a decade. And I shared that base mesh with Disney Animation, alongside an early version of LandmarkManager, so the character team could standardize mesh usage across modeling, rigging, and look development. As far as I know, that same base mesh is still in use there. That handoff is the first moment my own off-the-clock work crossed the line from personal toolkit into production infrastructure at a studio I also happened to be employed by.

The brand came later. The tools came one at a time, each from a specific production issue, each built to unblock myself on a real project. At some point the collection stopped looking like a drawer of scripts and started looking like a pipeline. MeshSynergy is the name that pipeline ended up wearing.

THE CHALLENGES

Character production in Maya is mostly solved, until you start moving the work between contexts. Then the same three problems show up on every project.

Crease data does not travel. A low-resolution mesh with vertex creases defining subdivision sharpness is the cleanest way to work, but neither OBJ nor FBX reliably preserve crease metadata across Maya and ZBrush round-trips. Every trip through the sculpt tool strips the information. You re-crease the same edges by hand on the way back, and you do it again the next time, and the time after that.

Mesh-associated data does not travel either. Vertex IDs reset, symmetry maps rebuild inconsistently, UV sets get renamed, outliner hierarchy scatters. The mesh survives the move; the package of information around the mesh does not. On a single asset, this is annoying. On a production with multiple LODs, variants, and revision cycles, it becomes the dominant cost of moving any asset anywhere.

Semantic regions collapse across departments. Modeling defines face and body zones one way, rigging defines them another, look development defines them a third. When those definitions diverge, characters that share the same topology still drift structurally. The visible symptom is inconsistent deformation. The root cause is that three teams are looking at the same mesh and reading three different maps of it.

None of these are glamorous problems. None of them make a demo reel. Every one of them eats real production time, on every project, forever, and the off-the-shelf solution for each is a separate utility script that sits next to a dozen other separate utility scripts, none of them talking to each other. The gap is not "a tool is missing." The gap is "the tools do not compose."

THE APPROACH

The decision that shaped everything else was to treat MeshSynergy as a system, not a collection of independent utilities. Every tool had to share the same underlying model of what a character asset is, what data belongs to it, and how that data travels. Longer to design. Slower to start. But a new tool becomes an added capability to an existing pipeline, not another isolated utility that the user has to stitch in by hand.

A controlled environment first

Before any tool could be useful, the topology underneath it had to be predictable. The BaseMesh is the piece everything else runs against. A biped topology developed from years of character production across studios, with edge flow tested against real deformation ranges, UV sets covering production standards including MetaHuman compatibility, and subdivision behavior validated against actual rig requirements. Free base meshes are everywhere. Topology that has been stress-tested against fifteen years of stylized character rigging, and of which one particular branch has already spent time inside a major studio's production pipeline, is not.

The BaseMesh carries a second function that is less obvious. It is also the reference point every tool was designed against. MeshManager knows what mesh-associated data looks like because the BaseMesh was the test case. LandmarkManager knows what a clean semantic region layer looks like because the BaseMesh was the first surface it was run on. The tools work on any topology, but the specifications they were built against came from an asset that had already proved itself in production.

In 2016 I shared the corresponding branch version of the BaseMesh with Disney Animation, alongside an early version of LandmarkManager, so the character team could standardize mesh usage across departments. The tool and the topology went across together, because they were designed together. To the best of my knowledge, that base mesh is still in use there today.

The metadata has to travel with the mesh

MeshManager is the pipeline backbone. It packages a character asset as a full unit: geometry plus the metadata that actually matters, vertex IDs, topology classification, symmetry mapping, UV sets, outliner hierarchy. Import and export carry the whole package, not just the OBJ. Mesh class, type, and LOD can be defined per project, so the naming and categorization scale to production conventions instead of forcing one on the user.

The tool sounds mundane. It is not. Almost every downstream failure I kept hitting on character projects traced back to the moment a mesh left its original context and arrived somewhere else with its data stripped. Fix that once, at the foundation, and every subsequent tool built on top inherits the assumption that the data is still there. The backbone had to be built first, even though it is the least glamorous tool in the set, because without it every other tool is building on sand.

The friction that became a product

CreaseManager is the tool that made MeshSynergy a product. It came out of a three-year freelance run sculpting thirteen collectible figures for Riot Games between 2018 and 2020 without an aid support to carry the crease information across sessions and file versions.

I built a script to stop repeating myself. That script is now CreaseManager, and it is still my daily driver.

The pattern CreaseManager encoded is the one every tool in the set follows now. Real production friction, sustained long enough that the repetition becomes signal, scripted first to unblock myself, then hardened into a shippable tool only once I had used it on enough of my own work to know it held.

Semantic regions that hold across departments

LandmarkManager handles the color shading set layer. Named, reusable regions that define facial and body zones, portable across Maya and ZBrush through PolyGroup integration, editable and transferable across meshes. The tool is small. The problem it solves is not.

When a modeler, a rigger, and a look dev artist all work on the same character but define its semantic regions independently, the character drifts even when the topology does not. Hair groomers assume one region map, skin shading assumes another, the rig expects a third. A character that should be consistent across departments becomes quietly inconsistent in ways that show up as extra review rounds and extra fix time. LandmarkManager gives the three departments a shared ground truth to work against. One region definition, transferable, editable, and propagable across characters. On a specific asset, this might not be an issue unsurfable, but at scale, this becomes a nightmare.

Shipping, and what it actually meant

What is in market today is three stable tools (MeshManager, CreaseManager, LandmarkManager), available on Gumroad with personal and studio licensing, and an ecosystem site at meshsynergy.xyz carrying the product pages, documentation, and the beginnings of a writing practice around topology and craft.

MeshSynergy also taught me everything about small-business infrastructure that twenty years in feature animation and tech did not. Pricing, licensing, distribution, refund policy, changelog discipline, documentation as a first-class product surface, support as an ongoing cost of having users, the difference between a product that exists and a product that is actually being sold. None of that knowledge was available to me while I was only employed at studios. The only way to get it was to run the small thing on the side, make the mistakes that come with running it, and pay attention to what the mistakes were telling me.