1. Naming and project structure

All files and folders of the project must be named in Latin letters, without special characters and without spaces.
As_delimiter_use_underscore.

Correct name:
Project_Name_Cam_01.c4d
Project_Name_Cam_02.c4d
Project_Name_Cam_03.c4d

Project structure:

The project folder structure should look like this:

1. The main folder, which contains all other files and subfolders;
2. One or more scenes to be rendered;
3. Subfolders with assets and the assets themselves in the following variations:

a) all assets (including textures) are added to the project folder;
b) textures are added to the standard Tex folder, the rest into one folder with the project.

2. Project collect

Each asset is written as a path to an external file on the hard drive. If this path is specified incorrectly, then when the scene is opened, this asset will not be loaded. Therefore, paths to assets (textures, alembics, etc.) must always (!) be specified locally. The local or relative file path is a path that indicates the location of the file relative to where the project scene is located.

Example. There is a project scene D:\Project\Render\Test_Scene.c4d. A texture with a global path is loaded into this project D:\Project\Render\Sample.png. In the material, the local path to this texture will look very simple - Sample.png. If we put this texture in the tex folder, then we also don't need (!) to specify anything except the name of this file.

You can check the paths to assets manually, but if there are many of them, then it is easier to use the Project Assets Inspector window (appeared in the 21st version of Cinema 4d), in which you can control all the assets in the scene.

Almost any project uses various assets or external data:

• bitmap files - textures (*.tiff, *.jpg, *.png, *.psd, *.hdr, *.tga etc.)
  
• XRefs (*.c4d)
  
• Alembic (*.abc)
  
• IES files (*.ies)
  
• GI and MoGraph cache files(*.gi2, *.mog)
  
• Substance files (*.sbsar)
  
• Volumetrics (*.vdb)
  
• Sound files (*.wav, *.aiff, *.mp3)

All assets are written in the scene in the form of paths to files that are loaded into the scene in the course of work and image rendering: textures in materials, IES in light sources, alembics in corresponding objects, etc.

If you put all the assets used in it (without subfolders) into one folder with the scene and simply specify the paths to these assets as the names of these files, then they will all be loaded into the project correctly.

Key requirements for any asset:
1. All assets used in projects must be uploaded together with the scene (or scenes) to the cloud.
2. The name of any asset must be in Latin letters without spaces (use underscore as a separator).
3. In the project, the path to each asset must be local.

Check the links in the Redshift Asset Manager of the render. All should be marked with a green checkbox (excluding clone cache). Red crosses need to be tweaked or cleared.

Correct setting on the example of Redshift

Clearing unused links

Assets

To check assets before preparing the scene for rendering:
1. The final scene has been assembled, in which all the edits in the render settings have been made.
2. Check that all assets are specified in the scene (globally or locally). The main task of this check is to make sure that all data will be read. To do this, open the main menu Window> Project Asset Inspector. If some asset has an incorrect path, then a red cross will be shown in front of it. Depending on what asset was lost, you must either specify the correct path, or delete it. The final task is that in the Project Asset Inspector window, all positions are marked with green checkmarks.
3. Apply the command File - Save Project With Assets and specify where to save. After cleaning, there should be no errors that some file was not found. When saving on the hard disk, a folder will be created, inside which there will be a file of the same name and a Tex subfolder, into which all textures and volumetrics in VDB format will be copied (!). The rest of the assets (scenes in * .c4d format for Xref, alembics, Mograph cache in * .mog format, IES files, sound files) will be copied to the main folder where the project file is located. In this case, most of the paths to assets will be automatically set locally.
4. Open the Project Asset Inspector, and check that in the Status field opposite each asset there is a green checkbox and that in the Path field all paths to assets are local. If some assets are left with global paths, then you need to check them manually by opening materials, containers of alembics, etc. and see how these paths are indicated there. If the path is local, do not touch anything and do not pay attention to errors. If global, then edit manually.

3. Render settings

If there is nothing in Multi-Pass and the psd format is displayed, uncheck the box

Octane. If the checkbox is active in the passes, you must enter the path ./out/octane_pass/$prj

In Render Settings, leave only those settings that are used in the project (one or more, if takes are used).

Render Settings > Output

Render Settings > Save

Render saving is indicated in the Save or Multi-Pass Save fields.

The paths for saving files are specified locally, i.e. as to where the project scene lies. If you just write down the name of the file, for example render_test.exr, then this file will be saved in the same folder as your scene. If you want to save the render result in a subfolder, then just write ./render/render_test. The ./ syntax in this case means referring to a subfolder. Always place a closing slash (/) after the folder name. If this folder already exists in your project structure, then the files will simply be saved there. If this folder does not exist, then it will be created. Paths are indicated only in Latin letters and without spaces.

It is highly recommended to use tokens - simple text variables used in path and file names. Here are the main ones.

• $prj: project file name
  
• $camera: the name of the camera used
  
• $take: the name of the take used
  
• $pass: Multi-Pass layer name or Object ID name
  
• $userpass: the name of the Multi-Pass layer or the name of the Object ID specified by the user (renamed in Render Settings by double clicking on the desired layer)
  
• $rs: the name of the render settings used
  
• $res: image size (for example, 800*600: we get 800X600)
  
• $fps: frame rate per second (for example 25)
  
• $renderer: the name of the renderer used to render the image, for example Redshift
  

A simple example of using tokens when saving a frame sequence using AOV so that each pass is saved in a separate folder:

In the Save field: ./render/$prj/$prj
For Multipass Save: ./render/$prj/pass/$prj_$pass/

4. Parametry and cache

A wide variety of animation tools can be used in any animation project. Some of them are procedural and involve some variation in playback. This applies to almost any speaker, Dellay effector, some Fields and Xpresso setups, and some deformers. For the render result to be correct, all this must be cached before being sent to the render farm. In most cases, caching comes down to three main options:

• recording animation in the form of animation keys
• caching of different dynamics with built-in Cinema 4D tools
• export of the entire scene or individual objects in Alembic format and further replacement of the original objects with cached ones.

Camera. Camera animation can be carried out in Cinema in a variety of ways and, in principle, not all of them require caching. But based on personal experience, it is most correct to send a camera to the render, which contains only the frame-by-frame animation P(S)R and, if necessary, other parameters, for example, Focus Distance. No Xpresso, no complicated hierarchies or anything else.

There are many options for camera setups (spline driven, parent controlled, XPresso or Python tag controlled, etc.). In any case, there is a Camera object that you need to get for rendering without all the unnecessary things.

Follow these instructions:

1. The original camera (for example Cam_1) is copied and placed below at the zero level of the hierarchy. It is better to rename the copied camera to Cam_1_For_Bake, for example.
2. If there are subsidiaries in the copied camera, they should be deleted (they remain in the original).
3. If there are any tags on the copied camera, they should be deleted. The configured Redhsift Camera or Octane Camera tag can be left.
4. If the copied camera has animated PSR tracks (Position, Scale, Rotation), then they need to be deleted.
5. If the copied camera has other animated parameters, you can keep them.
6. Next, the Rigging Tags> Constraint tag is hung on the Cam_1_For_Bake camera (in older versions, Character Tags> Constraint).
7. In this tag, in the Basic tab, switch the Priority parameter to Generator mode and set the value in the adjacent field to 10. Activate the Camera Dependent checkbox. Below we activate the Transform checkbox (in older versions of PSR)
8. In the Transform tab that appears (in older PSR versions) at the bottom in the Target field, you must specify the source camera (Cam_1). As a result, the new camera will be linked in position and rotation to the original one.

Mograph. Cloner, Matrix, Fracture, Voronoi Fracture, MoInstance, MoText, MoSpline objects - in most cases, you need to cache using the Mograph Cache tag.
If the amount of cached data is small (conventionally within 500 mb), then they can be stored inside the scene, thereby increasing its size. If the volume is larger, it is better to cache it as a sequence of external files in *.mog format.

When there is no animation on Mograph objects, they don't need to be cached.

The general caching scheme is simple:

1. It is better to name each cached object with its original name in Latin without spaces.
2. Add the Mograph Cache tag to each cached object.
3. In the attributes of the tag, press the Bake button, the cache will be calculated and initially recorded inside the scene. The amount of used memory will be shown below.
4. If the cache is large, then it is better to export it to a sequence of external files. To do this, specify in the File field where to save the cache (usually this is the same folder where the scene is located). It is better to use the original name of your Mograph object as the name, and then click Export Cache to File.
5. In the future, you will need to specify the local path for each cache.

1. Next, you need to bake the animation on this camera. To do this, open the Timeline window in Dope Sheet mode (key mode) and drag the Cam_1_For_Bake camera to the Timeline window. If it does not appear there, then in the Timeline window, in the local menu View> Show> uncheck the Show Animated checkbox (show only animated objects).
2. After that, using the Go To Start command, go to the zero block.
3. Before baking the animation, you need to check which parameters will be recorded. In addition to Position and Rotation, quite often it may be necessary to record some other camera parameters, which can be controlled via Xpresso or something else. In order for these parameters to be recorded, it is necessary to create an empty track on each of them. To do this, in the camera attributes, right-click on each desired parameter and select Animation> Add Track from the drop-down menu. Those. we get tracks without animation keys.
4. Select Cam_1_For_Bake in the Timeline window and call Functions> Bake Objects command in its local menu. In the window that opens, set the following parameters:

• frame range, usually the length of the entire project
• we leave Bake Expressions enabled (write the data of expressions, in particular the Constraint tag)
• leave the Create Copy checkbox on - a new camera will be created
• leave the Clear Tags checkbox - removes unnecessary tags on the copy
• uncheck Clean Tracks
• do not enable All Parameters!!! otherwise, all camera parameters will be recorded
• leave the Position checkbox on - record the position
• if necessary, enable the Scale checkbox - record the scale (this is extremely rare)
• leave the Rotation checkbox on - record the rotation
• enable the Animated Parameters checkbox - if there are any animated parameters or parameters with an empty track on the camera, they will be recorded.

After that press Bake.

However, the MoGraph cache is not capable of caching all Mograph objects.

• Voronoi Fracture, if you have, for example, an Emitter used as a Source (the number of points changes or they move)
  
• Mospline with the effect of particle effectors, such as Turbulence or Field Force - the effect of these objects is not recorded in the Mograph Cache (only standard effectors)
  
• MoSpline in Turtle mode is not recorded
• Tracer is not recorded
• MoExtrude is not recorded
  
• Poly Fx is not recorded

There is only one way to get around this limitation - to export these objects to Alembic files, and then replace the original objects with cached ones. You can export either using the standard export method via the File> Export> Alembic menu, or using the Bake As Alembic command. It is better to export each object separately.

As for some Mograph effectors (Dellay, Push Appart and others) that can be used as deformers, their action also needs to be cached. This can be done either by exporting to Alembic.

Fields. Fields generally do not require caching, because most of them perform procedural functions without variation. Dleay and Decay effects may be an exception. You can cache them in different ways, depending on what they affect in the setup. If for Mograph objects, then via Mograph Cache, if for geometry, then via export to Alembic.

Deformers. All Jiggle and Collision deformers are cached by standard object data tools, Cache tab. In this case, the cached data is stored inside the scene.
Alternatively Alembic caching can be used.

Cloth Dynamics. All objects with the Cloth tag are cached by the standard means of this tag, the Cache tab. In this case, the cached data is stored inside the scene.
Alternatively Alembic caching can be used.
The only limitation is that tear rags are not supported.

Hair Dynamics. All Hair objects are cached by the standard means of this object, the Cache tab. In this case, the cached data is stored inside the scene.
Alternatively Alembic caching can be used.

Spline Dynamics. All splines with the Spline Dynamics tag are cached by the standard means of this tag, the Cache tab. In this case, the cached data is stored inside the scene.
Alternatively Alembic caching can be used.

Soft & Rigid Body. All objects or groups of objects with the Dynamics Body tag are cached by the standard means of this tag, the Cache tab. In this case, the cached data is stored inside the scene. Alternatively Alembic caching can be used.

Thinking Particles. Thinking Particles does not natively have any caching tools, so the only option is Alembic caching.

For this you have to:
1. Create a TP Geometry object. Give him an original name.
2. In its attributes in the Particles Group field, drag the required group from the TP Settings window.
3. Select only the TP Geometry object.
4. Set the following settings in Main Menu> File> Export> Alembic.
5. When importing, use the following settings.

Simple Particles. Standard particles are cached via the Simulate> Particles> Bake Particles command (active if emitter is selected). After its application, the Bake Particles tag appears on the emitter, in which the cached data is stored (stored inside the scene). With a large number of particles, it can significantly increase the size of the scene. Alternatively, you can export to Alembic similar to Thinking Particles.

X-Particles. X-Particles are cached by standard means of this plugin through the XpCache object. In most cases, caching goes in the form of external data, in a separate subfolder in the project hierarchy (Cache) in native X-Particles formats.
When sending for rendering, it is enough to specify the local path to this folder and all data will be automatically loaded.

XPresso. Various XPresso setups can be cached in two ways. Export to Alembic, or bake animation in the Timeline window via Bake Objects.

Тег Constraint. Any animation using Constraint tags is best cached. This is mainly done by analogy with caching the camera into animation keys via Bake Objects (see above).

Тег Constraint. 4 scenarios:

• cache nothing
• bake animation of bones through Bake Objects in the Timeline window, but for example with a Character object this does not always work
• bake character deformation in Point Cache, disable Skin
• caching character geometry via Alembic

Mo Text. MoText should preferably be converted to mesh. If it is impossible, put the fonts you are using in the project folder and inform the manager.

5. Plugins

Plugins. When using third-party plugins, you must place them next to the project in the plugins folder. If this is not possible, please inform the manager.