Goal
A good Soko project structure should make it easy to:
navigate quickly (artists, supervisors, producers), scale from small to large teams and from one title to many episodes, keep dependencies traceable (what feeds what), enforce consistency (naming, templates, outputs, statuses), support vendors and permission boundaries when needed. Soko supports multiple valid structure patterns. The “best” choice depends on team size, number of episodes, external vendors, and how your departments collaborate.
1) Separate “Scope levels” (what the work belongs to)
Animation pipelines typically have at least these scopes:
Show / Project-wide (e.g., global references, tech docs, standards, style guides) Episode / Reel / Segment (or “Unit” in a feature film) Sequence (story/scene grouping) Asset (character, prop, environment, rig, etc.) Best practice: ensure your folder objects/types and task templates reflect these scopes.
2) Use templates + empty outputs to standardize expectations
Use Task Templates so every shot/asset/episode gets the same baseline tasks. Use Empty Outputs so it’s always obvious what should be published where (preview, cache, render, final, etc.). Keep templates few and stable. Prefer “one template + optional add-ons” over dozens of variants. 3) Keep naming predictable (for filtering, reporting, automation)
Use fixed padding and increments where possible (####, start at 10, step 10). Avoid “freeform names” for high-volume objects like shots. 4) Make links explicit (dependencies)
Regardless of folder structure, downstream work must clearly reference upstream outputs:
edit → audio/post → master (timelines feed finishing)
Use task links so “Inputs” are visible and scheduling makes sense.
5) Keep statuses small and stable
6) Top-level production container (recommended naming)
For animation and VFX, the main “production container” at the top level should use a name that matches how your team thinks and speaks. We recommend one of these three standard names:
SHOTS (universal for films and series)
Use when the production is primarily shot-driven and you want a consistent structure across all show types. EPISODES (clearest for series)
Use when the episode is the primary planning and reporting unit (schedules, deliveries, reviews). SEQUENCES (if sequence is your primary planning unit)
Use when the sequence is the main organizational unit and the team naturally groups work by sequences first. Note: These names describe the top-level container. Inside, you can still nest other levels (e.g., EPISODES → SEQUENCES → SHOTS).
Project structure patterns
Pattern A — Episode/Reel-centric structure (self-contained per episode/reel)
Best when: small-to-medium teams, limited external vendors, high need for context, you want each episode/reel/act to feel self-contained.
Summary
Work is organized primarily inside an Episode/Reel/Act container. Inside that container you keep:
Episode-wide work (editorial, audio, post, approvals) in a dedicated “common” area Recommended top-level (series)
Recommended top-level (feature film options)
Choose one depending on how your show is structured:
SHOTS (if you’re shot-driven) SEQUENCES (if you plan by sequences) REELS / ACTS (if editorial structure is primary) Episode/Reel subtree (recommended)
Inside each episode/reel/act:
00_COMMON (generic folder) Best practices
Do
Use a dedicated 00_COMMON area folder for work that belongs to the whole episode/reel. Keep 00_COMMON strictly for episode/reel-wide work (not shot/asset work). Keep sequences/shots consistent and predictable under the episode/reel. Use an Episode/Reel template that creates only episode/reel-scope tasks + empty outputs. Use a Shot template that creates shot-scope tasks + empty outputs. Don’t
Don’t model 00_COMMON as a “fake sequence” if sequences are expected to behave consistently (automation, metrics, templating). Don’t spread episode-wide deliverables across multiple unpredictable places—keep a single “home” for them. Pros
Best “one place per episode/reel” navigation. Easy packaging/archiving/hand-off per episode/reel. Strong context for supervisors and producers. Cons
Department teams (editorial/audio/post) may need to jump across episodes. Permission boundaries are harder if vendors need only a department slice. Deep paths can happen—keep naming short and consistent. Pattern B — Department-centric structure (separate Editorial/Audio/Post/Deliveries)
Best when: larger teams, multiple episodes, external vendors, strict permission boundaries, department managers want a single home.
Summary
Shots live under the production container (EPISODES or SHOTS), while department work lives in dedicated top-level areas. Episodes are mirrored across departments (e.g., EDITORIAL/EP01, AUDIO/EP01).
Recommended top-level (series)
DELIVERIES (optional but common) Recommended top-level (feature film)
Best practices
Do
Mirror episode naming across departments (EP01, EP02…), so navigation stays consistent. Make linking mandatory: department tasks should pull inputs from shot/sequence outputs. Keep DELIVERIES as the single source of truth for approved finals and official exports. Use department templates and enforce output naming (so exports are consistent). Don’t
Don’t duplicate the same “final” in multiple places; nominate one truth location (usually DELIVERIES). Don’t let department work drift without links to upstream sources (you’ll lose traceability). Pros
Scales well to many episodes and parallel departments. Better for vendors and permissions. Clear department ownership and onboarding. Cons
More navigation across the tree. Requires discipline (links, naming, templates). Context can be lost if a user only lives in one department area. Pattern C — Hybrid structure (common for growing productions)
Best when: you want episode/shot-centric navigation for production, but also want clean governance for finals and/or one or two departments separated.
Summary
Daily production stays inside your production container (EPISODES or SHOTS). One or two critical areas (often DELIVERIES, sometimes EDITORIAL) are top-level for “single truth”. Everything remains linked so traceability stays intact. Best practices
Keep work-in-progress close to where it’s produced (episode/sequence/shot). “Graduate” approved outputs into DELIVERIES. Maintain strict naming and versioning conventions for deliverables. This avoids reorganization as the project scales.
Implementation guidelines (applies to all patterns)
1) Choose your primary navigation axis
Pick one:
Production-first: EPISODES/SHOTS/SEQUENCES → (shots) Department-first: EDITORIAL/AUDIO/POST → (episodes) Everything else should support that axis rather than fight it.
2) Avoid “special-case objects” that break automation
If an object type (like “Sequence”) is expected to behave consistently across the project:
do not create exceptions (e.g., a “sequence” that is actually episode-wide common work).
Use a generic folder. 3) Standardize outputs by intent, not by software
Across 2D/3D pipelines, these categories are universal:
Workfile (editable source) Name outputs by what they are (preview, cache, workfile) rather than tool-specific naming.
4) Keep template count low
A scalable baseline set:
Episode/Reel template (episode/reel-wide tasks) Shot template (shot-level pipeline) Asset templates by asset class (character/prop/environment), optional
Add-ons for special cases (FX-heavy shots, hero assets) as separate templates. 5) Use links to make Inputs reliable
Links enable:
reliable inputs across folders and departments. Even in episode-centric structures, linking makes department handoffs robust.
Quick selection guide
Pick Episode/Reel-centric if:
you want everything per episode/reel in one place, the team is small or multi-role, vendor separation is minimal. Pick Department-centric if:
strong department ownership, external vendors and strict permissions, lots of parallel work across episodes. Pick Hybrid if:
you want to scale without restructuring later, you want governance around final deliveries, you want production clarity + department clarity where it matters.
Example directory structure
01_PREPRO
Animatic
Art
Mocap
Notes
Script
02_ASSETES
In general, if data is used in more than one shot, it should be published as an asset. If it is used only in a specific shot, it should be published in that shot.
1_Prop - used for static and animated 3D objects.
2_Char - used for 3D characters
3_SubSet - a reusable assembly without shot-specific dressing (e.g., a kitchen assembly, a street module, a shop interior kit)
4_Set - a shot-ready, fully dressed assembly (final layout/dressing, ready for the layout/lighting stage)
5_FX - reusable FX setups* used for particles, fire, smoke, water, ..
6_Sim - reusable Sim setups* used for cloth, hair, muscle, rigid body, soft body simulation.
7_Crowd - reusable Crowd setup* used for3D crowd setup.
*Shot-specific caches (Alembic, VDB, sim caches, bakes) should be published as Shot outputs.
8_Library - used for generic 3D assets created In "2D/3D" SW, e.g. generic material,textures, animation loops,etc.
x0 - On_set_data - for on set data (HDR, Color checkers, Scans, Measurements, Ref images,Lens Grid..)
x1_2D_asset - used for 2D assets created in "2D" SW (PS,Nuke,..), graphic, general nuke scripts, Titles,Fonts..