Multi-Render Guide

Start here

A Job is one submission. Each Render ID is an independently tracked render inside it. A State is a saved set of supported settings in Blender before submission. Ordinary single rendering uses one Render ID. Multi-Render uses one prepared project with independent saved states, even when only one state is enabled.

Before submitting, connect in Blender Preferences → Add-ons → Freedom Render Farm → Account Connection using a dedicated Blender add-on token. Follow the installation and connection steps; use connection troubleshooting if a token has expired or belongs to a different website. Website passwords and Manager / Render App tokens are not accepted by the add-on.

1. Save your Blender file. In Output Properties → Freedom Render Farm, enable Multi-Render. Enabling it does not copy files.
2. Select Prep First State. Wait for preparation to finish before editing states. Choose rendering add-ons before preparation; the engine and add-on selection are shared.
3. Change supported settings in Blender and choose New from Current, or edit the selected draft and choose Save Changes. Selecting a row alone does not apply it to Blender; use its explicit Apply control.
4. Give states useful labels and output prefixes. Duplicate, reorder, enable or remove states using the list controls. Each saved state is complete, not a patch on the previous state.
5. Check differences, inherited fields, effective collections, dependency warnings and limits. Preview a saved state before submitting.
6. Choose Submit Renders. Wait for a confirmed receipt and use Open Submitted Job. An upload percentage alone is not a receipt.

These steps describe the implemented interface. Farm execution uses website-configured Blender version/engine pairs and deployment readiness checks. Enabled targets are not a claim of complete compatibility certification. See the rendering release guide for deployment and target-host verification.

Base, working file and dependencies

Preparation freezes a saved base file and its static dependencies. The working Blender file remains editable, but only the supported state settings below enter a saved state. Meshes, materials, lights, transforms, parenting, constraints, animation authoring, engine and other arbitrary edits are not per-state changes. To change shared content, save the file and prepare a new base.

Discovery includes supported scenes, layers and collections, including hidden content. Saving a later frame range can extend image-sequence coverage after checking source identity and bytes. Existing prepared files are never silently overwritten. Missing or changed source files fail the extension; restore the matching source or deliberately refresh the base. Cache retention does not prove that a cache can render arbitrary frames.

Removing a state recalculates included dependencies; immutable reserve files remain available for reuse but are excluded from the archive when no longer needed. Disabled states retain their dependencies. Submit uses the saved prepared revision, not refreshed live assets.

Refresh Initial State is a full reset: after successful replacement preparation, previous states, IDs and previews are discarded. A failed or cancelled refresh retains the valid previous session. Sessions are temporary: closing/loading another file or disconnecting clears them. Missing or corrupt prepared files require new preparation. This does not edit a Job already submitted to the website.

Animation, cameras and collections

Keyframed or driven supported properties inherit the prepared file's animation. Their sampled value at the current frame cannot become a static override. Locked inherited fields are rechecked when saving. Editing keys, actions, NLA, drivers, object transforms or constraint targets after preparation can produce an ignored-edit warning. Detection is targeted; absence of a warning does not mean every arbitrary edit was captured.

Ordinary single mode preserves camera-switch markers through file-camera inheritance. Multi-Render rejects camera-bound markers even with one state. Choose an existing prepared camera; camera position/rotation/scale and camera type are not state settings. Lens and depth-of-field settings are allowed as listed below. Focus objects must resolve to an existing prepared object.

Collection render visibility is global to that collection, while exclusion, holdout and indirect-only are specific to a view-layer occurrence. A parent's exclusion and other occurrences can change the effective result. Inspect the effective collection details and preview; a checkbox alone does not guarantee visibility. Engine/version semantics must be verified for your combination.

Active sequencer scene strips are blocked by current preflight. Muted/unused strips are distinguished; this does not certify arbitrary sequencer projects. Unbaked simulations are blocked; baked/cache/add-on combinations without passing evidence remain unverified. Active compositor File Output nodes are blocked in this workflow for output isolation. Film transparency does not choose an alpha-capable format for you: choose RGBA and a compatible format yourself.

Preview a saved state

1. Select the state and frame, then Preview from Base.
2. If the draft is dirty, choose Save and Preview, Preview Saved, or Cancel. Preview Saved ignores unsaved draft changes.
3. Wait for the separate Blender process; use View Preview to inspect the labeled image. The local adapter uses Cycles CPU. A missing compatible runtime or failed preflight is an error, not a preview success.
4. Check the state, frame and revision on the result. Changed settings/base make old results stale. Cancel preserves valid states.

Preview does not render the live working scene, modify the prepared base, upload outputs, increment farm progress or incur farm charges. It cannot certify another engine, device or host.

Submission and confirmation

The receipt maps saved states to the website Job and its Render IDs. Preserve it when asking for help. A lost response can be retried using Retry Prepared Submission; the same confirmed request returns its existing receipt instead of creating another Job. A changed submission is a different request. Do not repeatedly start fresh submissions to resolve an uncertain response.

Local state enable/remove/refresh controls affect future submissions. Website controls affect the submitted Job. A receipt confirms acceptance, not worker compatibility, payment settlement, completed rendering or available artifacts.

Follow progress and waiting reasons

Open the Job from Dashboard or Uploaded Jobs. Expand Render ID rows for accepted frames, current rendering/uploading/processing, errors, costs and actions. Accepted frames are server-confirmed outputs; a rendered local file still uploading is not accepted. IDs can render, upload and finish independently. Disabled and failed IDs remain in the requested-frame denominator. The dashboard counts Jobs separately from Render IDs.

Check the observation timestamp beside a waiting reason. A stale report cannot establish what a worker is doing now. Job detail refreshes every 30 seconds; refresh again before interpreting a long wait. No eligible worker, credit holds, paused/disabled work, disk pressure, upload backlog, expired leases and compatibility blockers require different remedies. The generated contract reference lists the exact reason vocabulary.

Activity history records durable owner-scoped events. Replayed events do not create new work or a second charge. Controls report affected, unchanged and blocked counts; partial action success is possible. A button visible in an old page is rechecked by the server and may be refused.

Controls and recovery

• Pause Job / Resume Job: add/remove the parent hold. Resume does not clear unrelated manual, credit or resource holds.
• Pause / Resume Render ID: affect that ID. Siblings remain independent. Enable/Disable controls govern that ID's eligibility, not deletion of history or accepted outputs.
• Cancel: stops unfinished targeted work. Parent cancellation applies to unfinished siblings; ready downloads remain subject to retention. Cancellation is not a refund or a reset of accepted frames.
• Retry Upload: retries declared output under a valid server checkpoint/lease. It does not rerender already accepted frames. An expired source or lease may require another recovery path.
• Retry Render: applies only when offered for a rendering failure and within the persisted budget; accepted frames remain.
• Retry Processing: resumes the failed conversion/compression/upload stage; it does not restart successful rendering. Missing/expired sources cannot be recovered by pretending they exist.

Use only actions offered for the current ID. Automatic transport/render/processing budgets are finite; refreshing the page does not reset them. If no recovery action is available, record the Job, Render ID, stage, error and timestamp for support. Never send passwords or API tokens.

Credits, cost and independent downloads

The Job total reconciles per-ID render/output cost plus shared initial/package charges shown once. Shared charges may be billed through one ID but are not additional charges each time they are displayed. The estimator is an estimate; use the recorded cost for accounting. Completed work and accepted billing data survive retries, disabling or cancellation.

Insufficient credits hold new rendering across the account, including other Jobs. Authorized ready-output uploads and independent finalization may continue. Top up through Credits, confirm the recorded balance, then explicitly resume eligible work. Resume All Paused Jobs does not override disabled IDs or unrelated holds.

A Render ID's verified output links appear as soon as its artifacts are published, while siblings can still run or fail. Use Download available outputs for the available IDs, or that ID's ZIP-part links. Partial downloads mean only the published available outputs, not a guarantee that every requested frame exists. Processing, missing or expired artifacts are not ready. Existing child links still open the corresponding render.

Video IDs use their own format and effective FPS (FPS divided by FPS base). Explicit signed frame order is preserved. There is exactly one image per video frame: frames 1, 3, 5 at 24 FPS produce three video frames (0.125 seconds), not five frames with holds. Image and video IDs may share one Job.

Download and back up results promptly. The default shared-package cleanup threshold is 30 days after every sibling is completed or cancelled with a stop time; paused/disabled unfinished IDs and live assignments pin the package. This is a package rule, not a guaranteed download lifetime. Output cleanup and storage availability also matter; the deployed retention settings and expiry notices are authoritative. Incomplete uploads default to a 24-hour expiry. Refreshing a download link cannot recreate deleted data.

Single and multi examples

Single image sequence

1. Save a simple prepared-compatible Cycles project with a camera and frames 1–3. Keep ordinary single mode; camera markers may inherit from the file.
2. Set PNG and choose RGB/RGBA deliberately. Check credentials and file data, then submit using the add-on's ordinary export/upload path.
3. Follow the confirmed Job/Render ID. After accepted frames and processing finish, download its available ZIP parts and check the files locally.

Two states from one base

1. Prepare once with Multi-Render. Save state A for PNG frames 1–10.
2. Create state B from supported current settings for frames 11–20, choosing its own camera/lens, resolution and video profile/FPS if needed. Check dependency extension and preview both saved states.
3. Submit once and keep the receipt. Both IDs share the package; each has its own progress, cost and output.
4. When A becomes ready, download A immediately even if B is uploading or failed. Recover only B's failed stage when offered. Check shared charges once in the Job total.

The equal-capacity three-PC planning fixture distributes these 20 frames as 7/7/6 across the combined workload. Real allocation still depends on availability, weights, eligibility and holds. These are conditional walkthroughs backed by separate local fixtures. A connected installed add-on → farm → downloaded-output walkthrough is still pending and must not be described as passed.

Complete supported-settings reference

This is the schema allowlist, not farm certification. Every field is subject to prepared-file identity, animation inheritance and preflight. Decimal camera distances use Blender units; lens/sensor dimensions use millimeters. Aperture rotation is stored in radians (Blender may display degrees). Clip end must not precede clip start. Render-enabled is the inverse of Blender hide-render. A setting irrelevant to the existing camera type does not change that type.

Range start must not exceed end. Output prefixes are safe names, not arbitrary filesystem paths. Object/collection references must resolve in the frozen base; creating or renaming objects after preparation is not supported. Animation inheritance metadata is generated from that base.

Limits

These are versioned default limits. Server configuration can be stricter; a local estimate cannot override rejection. Bytes below are exact. Disk/backlog/concurrency values describe worker safeguards; they are not a customer speed guarantee.

State and waiting reference

Tested compatibility contract

Dispatch enabled: true. No unlisted version is implicitly supported. Blocked means rejected; unverified means evidence is incomplete, not supported. Exact local CPU evidence does not certify GUI, Docker or GPU execution.