Skip to content

Work

Capability case studies

Studio work is described at capability level only. No show names, path templates, configs, or proprietary detail. Personal Pax / agent-native work is called out separately.

Studio capability

  • 01

    OCIO 2.x / ACES migration and cross-DCC colour rules

    Problem
    Studios stuck on older OCIO stacks drift across Nuke, Maya, Houdini, Blender, and review viewers. File rules and context switching become silent footguns: wrong looks on write, farm, or publish.
    Approach
    • Lead an OCIO 1.1 to 2.x / ACES 1.3 style migration at capability level: config versioning, context-aware switching, shared rules.
    • Align DCC and review (including RV-class viewers) on one colour story.
    • Close Blender gaps where native file-rule support is incomplete, with a Python workaround pattern.
    • Add guardrails so invalid colour context fails loudly before publish or farm submit.
    Result
    One coherent colour pipeline across major DCCs and review, with fewer "looked fine in my DCC" surprises. Migration owned end to end; Blender gap handled rather than ignored.
  • 02

    Deadline farm: fail-closed robustness

    Problem
    Render farms that mark jobs complete when DCC tasks actually failed poison schedules and shot status. Custom plugins and long-frame timeouts make green untrustworthy.
    Approach
    • Customize Deadline for studio DCCs with honest error contracts: fail the task when the app fails.
    • Preflight and sanity checks before submit (licenses, mounts, context).
    • Pair farm plugins with batch publish paths so farm and interactive publish share validation.
    • Treat farm bootstrap as a thinner runtime where a full Toolkit stack is not needed on every frame.
    Result
    Farm status becomes closer to production truth; fewer silent half-publishes. Ongoing robustness backlog around fail detection and submit safety.
  • 03

    ShotGrid / FPTR Toolkit, launchers, and multi-DCC env

    Problem
    Artists need one Desktop / Toolkit story across Nuke, Maya, Houdini, Blender, and farm tools. Launch env, Software registration, and DEV vs site configs drift by OS.
    Approach
    • ShotGrid Toolkit / Flow Production Tracking custom engines, apps, and publish hooks.
    • Multi-OS launchers and env bootstrap (shell env plus Toolkit).
    • Blender as a first-class Toolkit citizen (tk-blender style engine plus Desktop launch).
    • Batch / farm publish beside interactive publish.
    • Config split: shared defaults plus DEV-local overrides without shipping secrets.
    Result
    Artists launch the right DCC with pipeline context; Blender sits in the same Toolkit universe as the rest of the floor.
  • 04

    Workstation provisioning: Puppet and Rocky

    Problem
    Artist and farm boxes need repeatable Rocky-class images: licenses, Deadline client, mounts, and monitoring. One-off machine setup does not scale.
    Approach
    • Puppet (or equivalent) for studio workstation and farm provisioning.
    • License and Deadline client wiring as code, not tribal knowledge.
    • Monitoring hooks so "machine looks up" is measurable.
    Result
    New seats and farm nodes come up closer to a known good state, beside the pipeline code lane.
  • 05

    Native Nuke plugins (burn-in / slate)

    Problem
    Delivery and review need reliable burn-in and slate without fragile Python-only hacks on every show.
    Approach
    • Nuke NDK C++ plugins for burn-in and slate at capability level.
    • Integrate with delivery / publish so metadata stays consistent.
    Result
    Stronger delivery tooling story where Python alone is not enough.
  • 06

    Performance: Rust / PyO3 hot-path compare

    Problem
    Hot paths in Toolkit-core style version comparison can dominate interactive publish or scan loops in Python.
    Approach
    • Reimplement a hot compare path in Rust with PyO3 bindings.
    • Keep the public Python API stable for Toolkit callers.
    Result
    Order-of-magnitude speedup on the compare hot path (about 10x, brief claim).

Personal / Pax · agent-native

Agent-native ShotGrid MCP and generative video infra

Personal / Pax
Problem
Pipeline TDs and AI film desks need agent-usable production APIs (ShotGrid / FPTR operations, cook and fleet control) without pasting secrets into chats.
Approach
  • ShotGrid MCP surface for agent workflows (on the order of 15 tools).
  • Generative video infra as productized pipeline craft: production desks, cook / orchestrator patterns, publish paths.
  • Consulting frame: Pipeline Autopsy (diagnose) and Pipe Doctor (fix / ops) at paxflix.com.
Result
Portfolio differentiator: classic VFX pipeline TD plus agent-native and generative production tooling. Studio capability work and Pax product work stay in separate cards.

Product desks stay private until a clean-room public story exists. No private repo links here. See also Pipeline Autopsy and Off the clock.