Cinema 4d reference¶
The Conductor submitter for Cinema 4D allows you to ship renders to Conductor from a dialog within Cinema 4D.
This document is a comprehensive reference for all features and concepts. If you want to get up and running fast, head over to the Cinema 4d tutorial page.
The preview panel shows how all the other settings combine to create a submission. You'll find it at the bottom of the dialog. Its purpose is to help you check over the final submission properties to avoid mistakes. The Preview panel is your friend.
The data in the preview panel is updated live as you change settings. It listens to settings in the dialog itself and some other settings in Cinema4d. For example, when you change the frame range in render settings, the list of tasks displayed in the preview panel updates.
Multi-take jobs are not yet implemented. Submissions are based on the current take only. If you wish to submit several takes, you'll need to manually switch takes, and press Submit for each.
The title that appears in the Conductor dashboard. You may use angle-bracket tokens to construct the title. For example, if you want it to contain the document name and the take name separated by a dash, enter the following expression.
Only tokens in the JOB scope are valid here. See the token table below.
This refers to one of the projects you created 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.
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 places where files are written, the others being the home directory and the temp directory.
Also, the destination path must not contain any of the assets you upload.
If your render produces intermediate files such as global illumination or ambient occlusion caches, and you want them saved, their paths must be below the destination path.
We recommend you turn off AutoSave on any video posts.
By default, the submitter generates the destination path automatically by finding the common root of output paths specified in Render Settings, and you shouldn't need to override it.
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.
Be aware that some renderers require GPU equipped instances. GPU instances are only available on AWS at this time. If you don't see GPU instances in the instance type list and you need them, contact support, and we'll get you switched over.
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 that could affect 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.
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 switched on, a text field appears, and the frame range specified in the Render Settings window is ignored. 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. This 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 specify how many scout frames you want and let the submitter figure it out based on the current frame range. To specify three well-spaced scout frames automatically, enter auto:3.
Take note that if you have chunk size set greater than 1, then you will likely get more frames rendered immediately than the scout frames you specified. The render nodes execute tasks, and if a task command is set to render a chunk of several frames, then it can't stop after just 1.
This is a template for the commands to run on remote instances. The template defines the shape of a Cinema 4d command-line render. It uses tokens in angle brackets similar to those used in the Job title above.
If you examine the task template and then check the Preview panel, you'll see how task commands are resolved.
Example template and resolved task commands
Commandline -render "<docfile>" -frame <start> <end> <step> -oimage "<docdir>/renders/test." Commandline -render \"/Volumes/xtr/perishable/my_project/my_scene.c4d\" -frame 1 5 2 -oimage \"/Volumes/xtr/perishable/my_project/renders/test.\" Commandline -render \"/Volumes/xtr/perishable/my_project/my_scene.c4d\" -frame 7 9 2 -oimage \"/Volumes/xtr/perishable/my_project/renders/test.\"
In the example above, the frame spec is set to
1-10x2, and the chunk-size is set to
3. Therefore the submission contains 2 tasks, each rendering a maximum of 3 frames. The start, end, and step parameters are substituted into the template accordingly.
docfile token expands out to the full document name, and the
docdir token expands to the containing directory so we can append the
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, the
PATH variable is set by default to point to application and renderer command locations, but you may have a script you want to upload and run. In that case, you can enter the Name of the variable:
PATH, the Value
/my/scripts/directory. You should switch off the Exclusive switch to indicate that the variable should be appended.
You can also enter local environment variables in the value field itself. They will are 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. This means that the task of uploading assets happens within Cinema 4d itself. Although this requires no extra setup, if you have a large number of assets, Cinema 4d will be blocked until uploading is finished.
A better solution may be to turn on Use Upload Daemon. An upload daemon is a separate background process. If you use an upload daemon, assets are not uploaded in the application. The job, 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.
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 template has access to the set of tokens in the token table below, as well as any environment variables available on your local system.
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 the render depends upon; however, it doesn't always catch everything. For example, you may want to upload a script or a color profile, or some asset referenced by a proxy. In these cases, you should explicitly browse the missing assets to make sure they are available on the render nodes.
|Token name||Example value||Scope|