Choose an upload mode
Choose ZIP or PROJECT packaging and configure project-root handling for reliable, repeatable submissions.
Updated 2026-08-04
Both modes trace scene dependencies. They differ in how the files are stored remotely and what a later submission can reuse.

*PROJECT adds reusable file synchronization and the path boundaries that come with a common root. The add-on refuses to submit until path warnings are resolved.*
ZIP: self-contained by default
ZIP packages the .blend and discovered dependencies into one archive for the job.
Choose ZIP when:
- this is the first test of a scene
- assets live outside one clean project root
- dependencies span multiple drives or volumes
- portability matters more than incremental upload speed
- you need a simple fallback after a PROJECT path warning
The add-on uploads the full archive again for each new submission, even when most files did not change.
PROJECT: incremental reuse
PROJECT uploads files into the selected Superluminal project's isolated remote area. Later submissions compare files and send only new or changed data.
Choose PROJECT when:
- shots share a stable project directory
- submissions reuse large assets
- dependencies can map under a common root
- the time saved on repeat uploads outweighs the initial structure work
PROJECT has path boundaries
The trace can exclude dependencies with absolute paths outside the project root and dependencies on another drive. Make those paths relative, move the assets beneath the root, or switch the submission to ZIP.
Automatic project path
With Automatic Project Path enabled, the add-on inspects the saved file and its dependencies and picks a usable common root. The panel refreshes a dependency summary and warns when files do not fit the mapping.
Automatic selection works best when the .blend and assets already live beneath a deliberate production folder.
Custom project path
Disable Automatic Project Path to choose the root yourself. The custom root should:
- be an ancestor of the submitted
.blend - contain the dependencies that should be reusable
- stay stable between related submissions
- not rely on drive-relative mapping across separate volumes
A root that is too narrow excludes sibling folders. A root that is too broad drags in a huge tree.
Decision guide
| Scene layout | Recommended starting point |
|---|---|
| One-off scene or first remote test | ZIP |
| Assets scattered across folders or drives | ZIP, then reorganize if repeat uploads matter |
| Episodic or shot-based work under one production root | PROJECT |
| Large shared texture/cache library under the same root | PROJECT |
| PROJECT scan reports excluded dependencies | Fix paths or use ZIP |
Relative paths are mode-specific advice
Use relative asset paths for PROJECT. ZIP does not require them, because ZIP packages a self-contained set anyway.
Reliable project structure
my-production/
├── shots/
│ ├── shot-010.blend
│ └── shot-020.blend
├── assets/
│ ├── textures/
│ ├── linked-blends/
│ └── caches/
└── color/Use Blender's path tools to make eligible file references relative to this root. After moving assets, reopen the scene, check for missing paths, render locally, and submit one remote test frame.
- Dependencies: Review asset classes, render-time add-ons, and validation steps.
- Troubleshoot an upload: Interpret path warnings and jobs that never register.