Cinema 4D reference¶
The Conductor submitter for Cinema 4D allows you to ship renders to Conductor from a dialog within the application.
This document is a reference for all features and concepts. If you want to get up and running fast, head over to the Cinema 4D tutorial page.
The submitter dialog generates a submission payload, which is sent to the cloud when you press Submit. This payload is in the form of a JSON object. You can view the resolved submission at any time in the Preview panel near the bottom of the dialog.
By analyzing this payload, you will gain a good understanding of how Conductor works at a conceptual level and will find troubleshooting submission issues becomes much more manageable.
In the Preview Panel, you'll find:
- All Cinema 4D and Conductor tokens are resolved in files paths and in the job title.
- All file dependencies are collected. For optimization reasons, this is done on-demand with the Show Assets button.
- Environment variables active on the render nodes are generated based on your software choices and custom additions.
- Task commands (one per instance) are generated based on your frame range specifications.
The data in the preview panel is updated live as you change settings. It listens to the dialog itself and some other parameters in Cinema 4D. For example, when you change the frame range or output paths in Render Settings, the list of tasks in the preview panel updates.
Multi-take jobs are not supported. If you wish to submit several takes, you'll need to select and press Submit for each.
The job title appears in the Conductor dashboard. It may use any Cinema 4D tokens that are in context. This includes
$take, but not
This refers to a project on the Conductor dashboard. The dropdown menu is populated or updated when the submitter connects to your Conductor account. If the menu contains only the - Not Connected - option, press the Connect button to connect.
If projects are added or removed since connecting to Conductor, you can press the Connect button again to refresh the list.
Specify the hardware configuration used to run your tasks. You are encouraged to run tests to find the most cost-efficient combination that meets your deadline. You can read about hardware choices and how they affect costs in this blog post.
Preemptible instances are less expensive to run than non-preemptible. The drawback is that they may be stopped at any time by the cloud provider. The probability of a preemption rises with the duration of the task. Conductor does not support checkpointing, so if a preemption occurs, the task starts from scratch on another instance. It is possible to change the preemptible setting in the dashboard for your account.
Cinema 4D Version¶
This is the version of Cinema 4D to run on the render nodes. It can be different from your local version, but be aware of feature changes affecting your render.
Choose the renderer that will render your job. We currently support Redshift and the default Cinema 4d renderer. If you choose Redshift, be sure to select a suitable GPU equipped machine in the instance_types menu or you will not be able to submit the job.
A chunk is the set of frames handled by one task. If your renders are reasonably fast, it may make sense to render may frames per task because the time it takes to spin up instances, and sync can be significant by comparison.
Use Custom Range¶
When Use Custom Range is active, a text field appears, and we ignore the frame range specified in the Render Settings window. Instead, you enter a frame-spec.
A frame-spec is a comma-separated list of arithmetic progressions. In most cases, this will be a simple range:
However, any set of frames may be specified efficiently in this way.
Negative numbers are also valid.
Specify a set of frames to render first. We start any tasks that contain these frames. All others are put on hold, which allows you to check a subsample of your sequence before committing to the full render.
You can use a frame spec to specify scout frames, for example:
1-100x30. Alternatively, you can select how many scout frames you want and let the submitter calculate scout frames from the current frame range. To specify three well-spaced scout frames automatically, enter
The remote render nodes execute tasks in their entirety, so if you have chunk size set greater than 1, then all frames are rendered in any task containing a scout frame.
Override Templates allows you to control the generation of the task command, which runs on the remote render nodes. The default Task Template, shown below, does not specify output paths, and therefore the render will use values in Render Settings. The default template should work fine for most cases.
Commandline -render "$ciodoc" -frame $ciostart $cioend $ciostep
Advanced users may want to override the template to add command-line arguments or run a different command altogether.
The task template uses tokens preceded by a
$ similar to C4D's native tokens.
These Conductor tokens are not made available in other parts of Cinema 4D. However, the task template supports most Cinema
4D tokens in conjunction with Conductor tokens.
Always check the Preview panel to see the resolved task commands.
On Conductor's render nodes, the directories that store your uploaded assets are read-only. Therefore you can't write out renders into those directories, and instead, the submission must specify a different directory to save. This destination path appears in the submission as
output_path and is one of only three writable locations, the others being the home directory and the temp directory.
Also, be aware, the destination path must not contain any of the assets you upload.
If your render produces intermediate files such as texture conversions or GI caches, their paths should be below the destination path.
By default, the destination folder entry is hidden, and we generate the value based on the common root of output paths in Render Settings. However, when you override the task template, you must also specify a destination folder, since in that case, the submitter can't infer the output location.
We recommend you turn off AutoSave on any video posts.
Example custom template and resolved task commands¶
Commandline -render "$ciodoc" -frame $ciostart $cioend $ciostep -oimage \"/Volumes/xtr/perishable/my_project/renders/my_image.jpg\" Commandline -render \"/Volumes/xtr/perishable/my_project/my_scene.c4d\" -frame 1 5 2 -oimage \"/Volumes/xtr/perishable/my_project/renders/my_image.\" Commandline -render \"/Volumes/xtr/perishable/my_project/my_scene.c4d\" -frame 7 9 2 -oimage \"/Volumes/xtr/perishable/my_project/renders/my_image.\"
In the example above, the frame spec is
1-10x2, and the chunk size is
the submission contains two tasks, each rendering a maximum of three frames. The start, end, and step
parameters are substituted into the template accordingly.
By default, your job's environment variables are defined automatically based on the software and plugin versions you choose. Sometimes, however, it can be necessary to append to those variables or add more of your own.
For example, you may have a script you want to upload and run without entering its full path. In that case, you can add its location to the
Add an entry with the Add button and enter the Name of the variable:
PATH, the Value
/my/scripts/directory. Make sure Exclusive is switched off to indicate that the variable should be appended.
You can also enter local environment variables in the value field itself. They will then be active in the submission. You might use
$MY_SCRIPTS_PATH (if it's defined) for the value in the above example.
Metadata consists of arbitrary Key/Value pairs that are attached to your submission. The purpose of metadata is to allow you to filter information in the Conductor web UI.
Example: To break down costs by shot number, you can add a metadata key called
shot and enter the shot number in the Value field. You can also enter environment variables in the value field that resolve in the submission. In the above example, you might use
$SHOT for the value.
Add one or more email addresses, separated by commas to receive an email when the job completes.
Use Upload Daemon¶
Use upload Daemon is off by default, which means that the task of uploading assets happens within Cinema 4D itself. Although this requires no extra setup, if you have many assets, Cinema 4D will block until uploading completes.
A better solution may be to turn on Use Upload Daemon. An upload daemon is a separate background process. It means assets are not uploaded in the application. The submission, including the list of expected assets, is sent to Conductor, and the upload daemon continually asks the server if there are assets to upload. When your job hits the server, the upload daemon will get the list and upload them, which allows you to continue with your work.
You can start the upload daemon either before or after you submit the job. Once started, it will listen to your entire account, and you can submit as many jobs as you like.
To run an upload daemon, open a terminal or command prompt, and run the following command.
Once started, the upload daemon runs continuously, uploading files for all jobs submitted to your account.
Submit a job with no tasks. This can be useful in a pipeline for artists who create assets but do not submit shots. If a texture artist submits an upload only job, then by the time a lighting artist needs to test render, all the assets have been uploaded.
A task may fail if the command returns a non-zero exit code or is preempted by the cloud provider. Set a value above 0 if you would like to try the task again in either of these situations automatically.
On submission, you'll usually want to include the current file. It can be tedious to save the scene each time manually. The autosave feature allows you to set a filename template instead.
By default, autosave is active, and the template is the filename, prefixed by
If cleanup is on, then the autosave file is removed after submission.
You cannot use cleanup if you are using an upload daemon because the file itself is one of the assets to be uploaded, and the submitter doesn't know or care when the daemon has uploaded it.
The autosave template has access to Cinema 4D tokens. The default value is:
Attach a location to this submission for the purpose of matching to an uploader and/or downloader process.
If your organization is distributed in several locations, you can enter a value here, for example, London. Then when you run a downloader daemon you can add the location option to limit downloads to only those that were submitted in London.
The submitter interrogates the c4d project file to find paths to all the textures and other files on which the render depends. However, it doesn't always catch everything. For example, you may want to upload a script, a color profile, or an asset referenced by a proxy. In these cases, you should browse the missing assets to ensure they are available on the render nodes.
When you submit a job to Conductor, we recreate the relevant parts of your local filesystem hierarchy on the render nodes. However, those render nodes run Linux, so there are no drive letters. This can cause a problem for absolute asset and output path references in your project. When the render node tries to find those paths, it will fail.
Fortunately, Cinema 4D fully supports relative asset and output paths.
- Assets may be defined relative to the c4d project file or by name if they live in the tex folder.
- Output images may be defined relative to the c4d project.
With these conditions met, the project becomes fully portable and platform independent. For this reason, we make available a function that localizes asset paths and converts output image paths to relative references. To make your project portable:
- Open the Render menu and choose Make Portable
If you now check the Asset Inspector and Render Settings, you'll see all paths are localized or relative to the c4d document.
|$ciodoc||/Users/jane/my_shot.c4d||Job||The full document path (without drive letter on Windows.)|
|$ciostart||1||Task||The first frame of the chunk being rendered.|
|$cioend||10||Task||The last frame of the chunk being rendered.|
|$ciostep||2||Task||The step value for the chunk being rendered.|