VFX Pipeline Consulting and Custom Tool Development

Pipeline consulting from a supervisor, not a vendor

Most pipeline advice arrives from one of two places. A large consultancy that has never sat in a dailies session, or a developer who has never had to explain a missed delivery to a producer.

Cristian Spagnuolo works from the other side. Twenty years supervising VFX and CG on features, series and commercials at DNEG, MPC, Mill Film, Framestore and Pixomondo, at every tier from boutique shops to Tier-1 facilities. He has run the shots that a broken pipeline makes expensive.

That is the whole basis of the offer. A pipeline problem is rarely a software problem. It is a decision that was made once, for a good reason, and never revisited when the work changed shape. Finding that decision takes someone who recognises the smell of it from the artist side and the production side at the same time.

Based in Montreal, working with studios worldwide, in English or Italian.

What happens on a pipeline engagement

The first phase is watching, not proposing. Sitting with the departments that complain the loudest, and with the ones that have gone quiet because they stopped expecting a fix.

What comes out of that is a map of where time actually goes, separated into three buckets: work that is genuinely hard, work that is slow because of a tool, and work that is slow because of a handoff nobody owns. The third bucket is almost always the biggest one, and it is almost never the one a studio expects.

From there the recommendations get ranked by what they cost to implement against what they return. Some are configuration changes that land the same week. Some are a tool that needs building. Some are conventions and documentation, which are unglamorous and frequently the highest-return item on the list.

Nothing gets recommended that has not been used in production. Systems over chaos, and no overkill.

Workflow optimization that survives contact with a deadline

A workflow that only works when everything goes right is not a workflow, it is a demonstration.

The optimization work centres on the steps a studio repeats every single day: publishing, versioning, review, handoff between departments, delivery. Those steps carry the compound cost. A small manual step, repeated by every artist on every version across a whole show, is where the schedule quietly goes.

The method is non-destructive. Existing work stays recoverable, changes get layered rather than baked, and no artist loses a day to a migration that was supposed to help. Rebuilding a slow step matters less than making sure the rebuild does not break the twelve things downstream of it.

The other half is integration at the right layer. Buying a tool and dropping it in the middle of a pipeline that was not shaped for it creates two problems where there was one. The right layer is usually lower and duller than the sales demo suggests.

Production discipline, not theory.

Custom tools, with shipped software as the evidence

A supervisor who says he can build tools should be able to point at the tools.

PXLsuite is a working toolset, built and shipped, in use and sold publicly. It includes PXLtools, artist-facing tools for Maya and Nuke, PXLbid for AI-assisted bidding and quoting, PXLflow for production tracking and dailies review, and PXLrv. Public documentation and guides sit at blackmamba3d.com/pxlsuite/.

None of that exists because of an interest in software. It exists because the same problems kept appearing on every show, and eventually sitting with a problem long enough turns into building the thing that removes it. That is the honest framing. Not an engineer who learned VFX, a supervisor who got tired of the same bottleneck.

For studio work, the same applies. Custom DCC tooling across Maya, Nuke and Unreal, built against a real pipeline rather than a generic one, with the deployment and the documentation treated as part of the job rather than an afterthought.

On AI: approximately one year of hands-on production experimentation, presented as exactly that. AI belongs where it holds up in dailies and nowhere else.

Documentation, conventions and the boring layer that holds

Ask a studio for its naming convention and the answer is usually a person, not a document. That person becomes the pipeline, and the pipeline goes home at night.

Cris writes and runs documented pipelines. On his own film project he operates a full production pipeline with written naming conventions, folder structure, scene hierarchy, delivery specifications and onboarding documents, and lives inside those rules daily rather than authoring them and moving on.

This layer is where most of the recoverable time hides. A convention that is written down survives a crew change. An onboarding document shortens the ramp for every new artist who arrives mid-show. A delivery spec that exists in a file stops the argument that happens at 2am on the night of a turnover.

It is unfashionable work. It is also the part a studio keeps after the engagement ends.

How an engagement starts, and what a studio gets

It starts with a conversation, not a proposal document. Thirty minutes on what is actually hurting, which is usually enough to tell whether there is a real problem to solve or whether the studio already knows the answer and needs permission to act on it.

If it goes further, the shape is normally: a short assessment phase with a defined scope and a fixed end date, followed by a written findings document with ranked recommendations, followed by implementation work only if the studio wants it. The assessment stands on its own. No obligation to continue into build work.

Deliverables are concrete. A findings document, prioritised recommendations, any tools built and deployed with source and documentation, and written conventions the studio owns outright.

Questions studios ask