> 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/assembly-pipelines.md).

# Assembly pipelines with Octane

Build Octane scenes from reusable assets, keep shot revisions separate, and submit the assembled scene for rendering.

An assembly workflow keeps reusable assets separate from the shot that places, lights, and renders them. For example, a forest shot can use a shaded tree library plus scatter data, so changing the layout does not require exporting every tree again. Andrey Lebrov's [Octane assembly pipeline](https://lebrov.com/octane-pipeline) develops this approach around Octane Standalone.

## Build a reusable library

Prepare geometry, materials, and textures as assets you can use across shots. Keep the files at stable locations: an [OCS scene](/docs/prepare-your-scene/octane-standalone-and-orbx.md) references external files, so moving or renaming them can break those links.

For repeated objects, separate the asset from the data that places its instances. Octane's [Scatter node](https://docs.otoy.com/standaloneSE/Scatter.html) uses transforms to place copies of connected geometry. [LMI Tools for Houdini](/docs/advanced-pipelines/lmi-tools.md) provides a workflow for exporting that placement and animation data.

## Assemble the shot in Standalone

1. Bring the required assets into the Node Graph Editor. Use **Import**, or drag an OCS or ORBX file into the editor. Use a **Reference** node when you want to reference an OCS or ORBX asset.
2. Connect the assets, scatters, camera, and lighting for the shot. Check the intended render target.
3. Save the shot separately from its asset library. Render a test that includes the camera, materials, and any animated elements.

OTOY's [importing guide](https://docs.otoy.com/standaloneSE/ImportingandExporting.html) describes the nodes for each file type.

## Revise the part that changed

Keep layout, camera, and asset revisions distinct. A lighting change should stay in the shot; a revised model belongs in its asset file. Reload changed files in Standalone and check the result before submitting another render.

If several shots reference one asset, replacing that asset can affect all of them. Keep separate asset versions when some shots must retain an approved look. Lebrov's [scene-file guidance](https://lebrov.com/the-octane-assembly-pipeline/manifest-articles/scene-files) explains the relationship between a master scene and its referenced library.

## Submit the assembled scene

Use [Render Network Manager](/docs/tools-and-api/manager-app.md) to upload an OCS scene with its referenced assets. Follow [Differential uploads](/docs/prepare-your-scene/differential-uploads.md) for the setup and format requirements.

For a browser upload, save an ORBX package from Standalone and follow [Upload Scenes](/docs/web-app/upload-scenes.md). Keep the editable master scene and its library for further revisions.


---

# 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/assembly-pipelines.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.