A personal pipeline for organizing 3D production projects

Throughout much of my professional experience, the complete 3D animation workflow has been handled by one person: preparing models, organizing scenes, creating cameras, animating, rendering, reviewing, and delivering.I developed the pipeline so the structure of files, shots, revisions, and renders would not have to be defined again for every project.

Read the process

Why I formalized the process

When several projects move through the same workflow, the number of Blender scenes, models, textures, renders, and recovery copies grows quickly. Each resource needs a defined location, name, and versioning rule. I created the pipeline to turn those recurring decisions into conventions that Blender can apply consistently.

How does it work?

The workflow starts in Project Organization. I define the project root, whether I am working in a shared or local location, the type of file, the revision, and the scene number.

From those values, the extension calculates the destination path and the file name. Before the first save, it checks the numbering, possible collisions, and path length, creates any missing folders, and saves the .blend in the calculated location.

Structured format:

The project separates the base 3D model, proposal views, renders, storyboard files, animation files, and temporary work. Each category has its own revisions and, when needed, its own scene folder.

Each branch repeats the same logic: editable files, scenes, and outputs are separated into predictable folders. When relevant, names retain the scene, shot, camera, version, and revision.

Naming format:

Each name combines tokens for the project, file type, scene, and revision. When needed, it also includes the shot, camera, and version. This lets me recognize what each file contains without opening it.

The convention changes with the resource: Proposal View identifies proposal views; Render identifies rendered images and scenes; Storyboard and Animation retain their own tokens.

Saving system:

The Save As panel applies the convention to the file I am about to save. I choose Render, Proposal View, Storyboard, or Temporary; the extension combines that type with the project, scene, shot, and revision.

Render Version adds V01, V02, or V03 when I need variants. The same versioning applies to RAW and final files because both can contain different versions of the same render.

Organization in Blender:

The extension is organized into several panels, each dedicated to one part of the workflow. In SC010, the Shots panel gathers the takes created in the scene and isolates the selected one with Solo Active Shot.

From the same panel I can create, duplicate, refresh, and render shots in RAW. In the Outliner, each shot repeats the same structure: camera, lights, main element, props, and background.

Organized camera system:

The Cameras panel keeps several cameras linked to their shot and gives each one a consistent name, such as SHOT_01_CAMERA_1. From there I can reorganize or rename them without losing their relationship to the take.

The Margins / backgrounds controls display the background and adjust its horizontal and vertical margins for the selected camera.

Output files for review and delivery

Render Configs applies common output formats and shows the relative destination of the shot. Below it, Output Files defines Test and Final destinations and provides access to the project’s output folders.

What the extension actually automates

The pipeline handles the operational decisions that should remain consistent: paths, folders, names, numbering, shot structures, camera references, output names, and backups.

It does not decide the composition, lighting, materials, motion, or final visual direction. Those decisions still require my judgment. The extension keeps the environment organized so I can focus on them.