> For the complete documentation index, see [llms.txt](https://know.rendernetwork.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://know.rendernetwork.com/docs/advanced-pipelines/large-productions.md).

# Large productions

Plan test renders, memory requirements, frame batches, and delivery for large images and long sequences.

## Test the expensive parts first

Choose frames with the most geometry, heavy effects, difficult lighting, or fast motion. Render them at the final resolution and quality, with the passes and outputs you intend to deliver. Include a short consecutive section to check animation, motion blur, and flickering.

A low-resolution preview is useful for timing and camera moves, but it does not prove that the final render fits in memory. In Octane, denoising also adds memory requirements that grow with resolution. See OTOY's [memory guidance](https://docs.otoy.com/houdini/HardwareRequirements.html).

For a dome, headset, or wraparound display, test the sequence on the intended display when possible. Check pacing, projection seams, and where the viewer needs to look, as well as individual frames.

## Use the test to choose settings

Before starting the full sequence:

* Check [supported software](/docs/get-started/supported-software.md) and keep the application and renderer versions consistent across your exports.
* Check the peak GPU memory used by your test. Set **Minimum Node VRAM** with room above that usage, using the options available for your [render tier](/docs/web-app/render-tiers.md).
* Check the downloaded test in your compositing app. Confirm every required pass, colour space, bit depth, and filename pattern in [Output Configurations](/docs/web-app/outputs.md).
* Use representative local render times in the [Cost Calculator](/docs/web-app/cost-calculator.md), then compare the estimate with a small network test before budgeting for the whole sequence.

In Octane, out-of-core rendering moves some scene data into system memory and can slow rendering. A successful local out-of-core render is a reason to check memory carefully before choosing network requirements. OTOY explains the trade-off in [Out of Core Settings](https://docs.otoy.com/standaloneSE/OutofCoreSettings.html).

## Split work where it helps revisions

Keep shots or delivery sections in clearly named [projects](/docs/web-app/projects.md). If you submit frame batches, record each batch's start and end frames so the final sequence has no gaps or unintended overlaps. Use [frame ranges](/docs/web-app/render-settings.md) to render a test or a section from the same uploaded scene.

Reducing a job's frame range does not shrink its uploaded scene. If the animation export itself is too large, split the export in your source application. The [Cinema 4D Wizard](/docs/tools-and-api/c4d-wizard.md#split-a-long-octane-export) provides this for Octane ORBX exports.

For shots that share a large asset library, consider an [assembly pipeline](/docs/advanced-pipelines/assembly-pipelines.md). Use [differential uploads](/docs/prepare-your-scene/differential-uploads.md) when revising supported scene formats.

## Include delivery in the schedule

Download a test batch to the final destination early. Check the folder layout and available disk space, then use its size to estimate how much storage the full sequence will need.

Choose [local or desktop downloads](/docs/web-app/download-frames.md), or [cloud delivery](/docs/web-app/cloud-storage.md), before starting the full render. Allow time after rendering for downloads, compositing checks, and corrections.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://know.rendernetwork.com/docs/advanced-pipelines/large-productions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.