Open topic with navigation

Preferences

Project Scale

Units in general

In earlier versions of CINEMA 4D (< R 12) there were no real units. You could define mm, m or km, but none of this made any difference for CINEMA 4D. It was always an appendage without a function in the respective value field.

This is now different: 1m is now 100 centimetres and 1 kilometer is 1000 metres etc., i.e. if you change the Units in the default settings, e.g. from Meters to Centimeters, a 2m wide cube is then displayed as 200cm. The values are therefore converted if the Show Units option is activated.

In combination with the double (internal) precision (which has been increased from 32 bit to 64 bit as of R 12), rounding errors are now a thing of the past, i.e. you can model 2 small dust particles in the millimeter range in one and the same scene, then switch to kilometers and place a gymnasium around the dust particles. CINEMA 4D now handles this perfectly.

It is now also possible to load objects modeled in mm into a scene where the objects have sizes of hundreds of meters, i.e., if you copy objects from one scene to the next, the conversion happens automatically.

You can adjust units here within Cinema 4D:

Units can be set anywhere here.

Scale Project

This parameter is the most important unit parameter. It determines how the numerical value saved in the file is actually interpreted. 3 meters, 3 kilometers or rather 3 yards? An empty, new scene always opens with the project default settings. This is the right time to consider the scale in which you want to model. Simply use the real, actual sizes of the object to be displayed as a guide. For a house, for example, this would be Meters, for the insides of a clock Millimeters, for a mountain range perhaps Kilometers.

The default factor additionally scales the scene by any value.

You can change the Scale Project at any time if you are working in very large and very small dimensions at the same time.

Note:Please also note the following Scale Project command, which you can use to simply scale scenes to the correct scale. This is often easier than experimenting with the factor here by trial and error. Characters, including working rigs, can also be scaled and fitted into other scenes without any problems.

Scale Project...

When loading old scenes or objects imported from other programs, these often do not have the correct length units or none at all. This command is used to bring such scenes to the correct dimensions.

Imagine you have imported an IGES hexagon head screw with unknown scaling. You know that it is an M6 screw. The project is set to the preset "Centimeters". You now only need to select one point on each of the opposite sides of the hexagon and determine the distance between the two (the Coordinate Manager provides information).

Assuming that the two points are 0.18 cm apart, you only need to enter the following values here and the scene will be scaled correctly:

Note:Please also note in this context that you can use it to scale characters including their working rigs (which can then be copied into differently scaled scenes).

FPS[1..2500]

This value determines the frame rate for the current project. CINEMA 4D uses this value to calculate all animations in the scene.

Basically, frame rates can be defined in 4 places in Cinema 4D:

By default, all 4 of these are set to 25 (e.g. Germany) or 30 images (e.g. USA) per second. In most cases, it is advisable to set these 3 to an identical value.

NoteYoucan also specify a frame rate for the calculation in the Render Settings (see Frame Rate). However, this does not recalculate the animation data. If the values are different (Scene Settings on the one hand and Render Settings on the other), this may result in a loss of quality, as calculated animation times may have to be skipped (frames are omitted) or additional frames may have to be inserted (as there is no recalculation, this is done by duplicating frames).

Project Time

This is the current time that is defined by the time slider of the animation palette.

Time Min

Here you specify the start time of animation tracks. This value can also be negative, e.g. to start a particle system before the calculation of a movie begins.

Time Max

This is used to define the end time of animation tracks.

Preview Min

Preview Max

These are the two points in time that limit the displayed preview area. These can also be changed by double-clicking on the points marked above in the power slider.

Level of Detail[0..100%]

Note:Please also note the LOD object, which provides extensive detailed level functionality.

This default value influences the display of all objects in the current scene for which you can select a specific level of detail. Such objects include all basic objects, the metaballs and all generators.

Regardless of the Level of Detail set in the individual object, you can further reduce the level of detail here.

If the value is set to 100%, all objects appear in full display (according to the values defined in the object properties).

If the value is set to 50%, for example, all objects in a scene are only drawn with half of all lines in the view window.

Note: This and the following parameter only affect the display in the Viewport.
Note: A change to the Level of Detail in the View window display menu affects the default setting here.

Render LOD in Viewport

Regardless of the value defined for the Level of Detail, the value defined in the Render settings is used when rendering in the Viewport.

Animation

Expression

Generators

Deformers

These 4 options do exactly the same as if you switch them via the options of the same name in the "Modes / Execution" menu of the main menu. Details on the functionality can be found here.

Motion System

If you want to switch off the Motion System temporarily, you can do this here or via the option of the same name here: Main menu: Modes|Execution menu.

Voreingestellte Objektfarbe

Color

Here you have the option of setting a color for all objects without explicitly assigning a material.

Connect Watch Folder

This and the next setting relate to the functionality of the Watch Folders, details of which can be found here.

This option allows you to specify at project level whether the existing "tex" folders from the scene storage location should be set as watch folders. This path can be adjusted with the following setting.

Relative Path

By default, the "tex" folder at the scene storage location is set here. However, you can also specify any other path here either as a relative path or select a path using the folder icon on the right. If possible - the folder is located on the same drive as the saved scene file - a relative path is then automatically set here (see also File for some details on relative paths).

View Clipping

Near[0..+∞m]

Far[0..+∞m]

If you get incorrect displays as shown on the left, it helps to set a different clipping area.

Due to the possibility of working simultaneously in very large dimensions (e.g., kilometers) and also in very small dimensions (e.g., nanometers), the view display (and only this, rendered it works perfectly anyway) is somewhat overstrained (the Z-buffer has only a limited resolution and at some point can no longer distinguish which polygons are behind each other, which results in poor display quality).

In this case, you have the option of setting a clipping area here. Outside this clipping area (calculated in the direction of the camera view), the display is cut off. Within the clipping area, the ratio of Near to Far should not be too large, the display is then always correct.

Select a suitable area from the selection menu or set a manual area using Near and Far.

Color Management

2025
The Color Management settings in the Preferences.

The settings in this section determine how imported colors are interpreted and rendered colors are displayed or passed on in an image file. In general, color management deals with the basic problem that, on the one hand, we need the most precise color and brightness values possible during rendering, but set color values or textures used in materials often only use a small part of this color space. In addition, the human eye or display devices can only perceive or display a very small part of the computationally possible color values. On the other hand, the further processing of the rendered images in post-production benefits from the highest possible brightness and color density.

Note:In this context, please also note the color picker in Cinema 4D. You will also find a menu there that you can use to select the color space in which you want to set a color. This will often be the sRGB color space, but you can also use the ACEScg color space, for example, to set HDR colors directly. The configured color is automatically converted to the render color space. You can find more information on this on the color picker pages.

Colors often have to be converted from smaller color spaces (e.g. color values set via color selectors or loaded JPG textures) into larger color spaces for rendering, while the render results have to be converted from these larger color spaces back into smaller ones, e.g. for displaying material preview images or in the Picture Viewer. Even monitors with a high dynamic range cannot fully display the huge color spaces used for rendering.
By default, an implementation of the OpenColorIO system (OCIO) is available for this purpose, in which the ACES color spaces are also available. This enables comprehensive color management across different programs. With version 2025.0, its use has been further simplified so that you often don't have to worry about anything else.

Please note, however, that older project files may still have been configured with other color spaces and the Linear workflow. In such cases, the Color Management settings will then appear partially grayed out. The old color management is then retained for these scenes in order to be able to continue rendering comparable results. However, the Change Render Space... button can also be used to convert such older scenes to the more modern ACEScg color space, for example.
Here you can find information on the older Linear Workflow. The corresponding "Simple" color management of earlier versions is documented here.

The theory of color management is quite sophisticated and is subject to constant development. If you would like to learn more about its basics, you will find an overview here. The following explanations deal more with the specific settings and modes as they are made available to you here in Cinema 4D.


Note:

The large color space used for rendering makes sense not only for the accuracy of the image calculation, but above all for post-processing. The more color information and gradations in the brightness are available, the more intensively color and brightness transitions can be edited in post-production without tearing or other artifacts. Therefore, only formats that can handle the high bit depths and floating point values, but at the same time can also contain additional layers, for example, should be used to save the renderings. Special HDRI formats such as OpenEXR are often suitable for this.


Change Render Space...

In general, it always makes sense to use the largest possible color space for rendering so that, for example, extreme lighting conditions in the scene do not result in visible gradations in brightness gradients (banding) or the clipping of color values. Even if these problems are not immediately visible in the rendered image, it can make subsequent recoloring or brightening in post-production impossible, for example, as this will result in tearing in these areas.
It is also helpful for the rendering that a gamma weighting of the brightness is not already calculated. This would often mean that contrasts would already be enhanced, which would also make post-processing more complicated and change the mathematically precise color values. For this reason, color spaces that use colors and their brightnesses in a mathematically precise and linear way are ideal for rendering. For this reason, Cinema 4D only offers color spaces for rendering that meet these criteria by default.
The currently selected color space is always displayed to the right of the button.


Current Render Space

First, the color space currently used for rendering is displayed in the Convert Render Space dialog under Current Render Space. For new projects, this is always ACEScg, as this color space only uses positive values for color components and can therefore be processed by all image and video programs without any problems. In addition, this color space is large enough for most applications. Only the ACES2065-1 color space is even larger, but can also contain negative values.
When loading older projects, the Compatibility Mode can also be displayed here, which corresponds to the old linear workflow (see also the left side of the following illustration). By changing the New Render Space setting, all color spaces can generally be converted to each other. However, when changing from larger to smaller color spaces, there may also be changes in the renderings. By default, however, the textures and colors entered are not converted.


Convert Color settings for render color space.


New Render Space

If you want to adjust the render color space, e.g. due to specifications from post-production, you can use the New Render Space menu. Below you will find explanations of the different modes and also a graphic that shows the different color spaces schematically.


Color space (gamut) Description
ACES 2065-1 This ACES color space is considered future-proof and represents the most comprehensive color space. However, it may also contain negative color components that not all further processing programs can handle.
ACEScg This color space was developed after ACES 2065-1 in order to overcome the limitations of common post-production applications, as only positive values occur in this color space. At the same time, however, there is still enough space for a large gamut. According to ACES conventions, this should only be the "in-house" format, as the color space is reduced compared to ACES 2065-1 and is not considered an ACES-compliant storage format.
Scene-Linear DCI P3 D65 This format closely follows the gamut that typical cinema projectors have, with the white point here set to daylight. Please enquire what white point is required on delivery as this could be a lower Kelvin value. With ACES 2065-1 this would not matter or need to be considered during production. Current top of the range laser projectors can display all colors defined in Rec. 2020 (see definition of Scene-Linear Rec. 2020 below).
Scene-Linear Rec. 709 - sRGB This is the standard for HDTV and computer monitors, using integer numbers. It was published in 1993, with the current version BT. 709-6 dates from 2015 and has many variants due to its relationship with sRGB, especially with regard to gamma definitions. The specification as a scene linear enables a much simpler exchange here, as all gamma variations and definitions are excluded. Therefore, both are linear and offer the same color space (gamut). In Cinema 4D, both (Scene-Linear Rec. 709 and Scene-Linear sRGB) are used interchangeably, based on linear floating point values. This is not the case when they are down-converted to integers. For color fidelity, a linear float-based file format is mandatory. In this way, the possible color definitions have increased drastically. These are based on values above 1.0, even for colors that might be below 1.0 in larger color spaces. With proper conversion in post-processing, greater color fidelity is achieved than would ever be possible with integer 8-bit or 16-bit formats in sRGB.
Scene-Linear Rec. 2020 This color space was established in 2012 as the new standard for UHD (Ultra High Definition) and defines a color space that significantly exceeds the sRGB color space and the DCI-P3 color space. Later, UHD, which was incorrectly referred to as 4K (3840 pixels wide), was no longer the only format defined in Rec. 2020. The second format is 7680 pixels wide and is often referred to as 8K; in either case, a 16:9 ratio is considered. The standard is described as 10- and 12-bit/channel integer, with floating point, also known as scene linear, being qualitatively preferable during production. The linear mode of operation allows the entire pipeline to basically manipulate color values without truncating data, helping to avoid constraints within the pipeline.
Legacy (sRGB linear workflow) This mode corresponds to the mode of operation of older Cinema 4D versions(Standard Renderer or Physical Renderer) and does not correspond to the ACES workflow or the color spaces offered by OCIO. In this mode, all colors entered are saved as non-linear sRGB values and then converted to the linear sRGB color space during rendering. The disadvantage of this principle is that no colors can be used that lie outside the non-linear sRGB color space.


Schematic representation of some ACES color spaces in comparison to common color spaces of display devices, such as Rec.709/sRGB. The colors contained in the ACES color spaces go far beyond the colors that can be displayed in sRGB, so the color representation here is only symbolic.


If you switch from one ACES color space to another ACES color space, all color values used in the interface are converted so that they appear as visually unchanged as possible. Images and loaded films that are not in the project's color space are converted accordingly. However, when switching from a larger to a smaller color space, color values may change when rendering again.

Please also note that the color management system cannot know how colors are to be used within a material, for example. Colors and textures that are used in data channels, such as bump, displacement, normal or alpha maps, are also included in this conversion. Example: a color shader in the alpha channel. For this reason, you will also find options for selecting which color space is to be used in each case at these points where textures, shaders or colors can be set and loaded. Normal and displacement maps, for example, are often interpreted linearly, whereas color textures are usually available in the sRGB color space with an imprinted gamma.


Convert Colors

If this option is active, all colors used in the scene, e.g. within color selectors or loaded textures, are converted to the new color space. This is the default setting and should only be switched off if you know what you are doing and want to avoid color conversion at all costs. Keep in mind that when switching from a larger to a smaller color space, information may be lost in the colors if they are in the outer range of the original color space.

View Transform (Project)

Here you will find a number of options that display transformation calculations for color values from the render area so that you can review your work in the editor and, for example, the Picture Viewer or Redshift RenderView. The transformations offered are often a kind of tonal value correction that converts the often very finely graded or very large color values calculated during rendering into the small and limited display values of, for example, your monitor. This can be useful, for example, to set a correct exposure. The Display Space and the selected View Transform (Project) setting together describe the Output Transformation.

You also have the option of switching the View Transform directly in the Picture Viewer if you want to experiment with the various options. But the Viewport Settings also offer you options for overriding the View Transform directly in the 3D views. In addition, an individual override can also be made in the Redshift RenderView. These options can be seen in the following image.


The viewport color space can be switched individually for the editor views in the Viewport Settings (left) with the View Transform setting. The Picture Viewer (middle view) and the Redshift RenderView (right) also offer individual color management settings for overwriting the transformation of the display or view color space.

View Transform (Thumbnails)

The same options are available here as for View Transform (Project) (see above), but these are only used here for the material thumbnails and the preview areas of Nodes.

Display Space

This setting allows us to specify how the color information from the scene-related (rendered) data is interpreted in order to view it on a display device (usually your monitor). Currently, sRGB is the only standard, so you will not be able to make any changes here.

OpenColorIO Config

You can link an OCIO configuration file here by clicking on the folder symbol to the right of the field. However, a corresponding file is already installed with Cinema 4D, which you can automatically refer to with the abbreviation $( DEFAULT).
Alternatively, you can also define your own environment variable under the abbreviation OCIO and use it to refer to your own file path. You can then also access this variable directly via the term $(OCIO) in this field. If $(OCIO) is not defined or cannot be found, $(DEFAULT) or the supplied OCIO configuration file is also used.
Further explanations on creating environment variables can be found here.

OpenColorIO File Rules

This also automatically subjects the color profiles of loaded image files and textures to the rules of the active OCIO configuration file.


Information

In the lower part of the Color Mangement settings, all information is summarized once again, such as which Color Mangement system (e.g., OpenColorIO) is used, which render color space is active and how the colors and textures are interpreted.


General information on Color Mangement:




Linear Workflow

The Linear Workflow (or far too many gammas)

In a nutshell

In recent years, the principle of linear workflow (hereinafter referred to as "LWF") has almost become a mythical process that promises miracles. Well, it can't perform miracles, but it can help you to produce better images that were previously only possible with additional effort or workarounds.

Overexposed areas are reduced.

The effects of LWF can be seen in the illustration above. This scene is illuminated by 2 light sources (inverse square fall-off). The quality with LWF on the right is dramatically better.

The following advantages can be noted:

Note:Please note that you cannot simply transfer old scenes to the LWF. The lighting must be readjusted. Of course, older scenes are loaded in such a way that they are rendered unchanged (the Linear workflow and Input Color Profile options are then deactivated). If you want to use old material libraries (which in most cases were NOT saved linearly) with the LWF, make sure to set sRGB for the Input Color Profile.
Note, the 2nd Note in connection with multi-pass rendering and After Effects, so that the passes rendered with linear workflow are interpreted correctly there.
Tip:For the impatient: You don't have to do anything else. With the option Linear Workflow activated, everything is done in CINEMA 4D to immediately benefit from the advantages of the LWF. CINEMA 4D sets everything internally to the correct values. You don't have to worry about anything else. Textures that are not displayed directly (relief, normal, alpha and displacement channels) are omitted.
Note that all CINEMA 4D-internal material colors and gradients are also changed directly in the preview. This can of course lead to all kinds of confusion, as simple grayscale gradients, for example, look different than before.

The colour value of 128,128,128 ( Linear workflow option deactivated) saved in a regular greyscale gradient at half length changes to approx. 192,192,192) when this option is activated. This behaviour is CORRECT!

Those of you who are interested in the backgrounds, read the next section, everyone else can now immediately enjoy more beautiful images.

Details

Note:In order not to disturb the flow of reading too much, the following sections always refer to images with a gamma of 2.2. Strictly speaking, this is not correct. They are equipped with such a gamma value that they work well with a monitor gamma of 2.2, i.e. the images actually have a gamma of 1/2.2 = 0.45 (this is also often omitted in corresponding Internet texts in order to simplify the topic).

The whole issue of gamma values and the associated LWF is due to the simple fact that a renderer calculates internally with linear gamma (= 1), but it is fed a different gamma (usually 2.2, since macOS 10.6 also for Mac users, previously 1.8) as input (textures, shaders etc.), although it also expects gamma = 1.

As a result, the renderer basically calculates "more incorrectly" (in the sense of less physically correct) than it actually should.

If you now cry out: "Oh dear, have I only ever produced sub-optimal results for the last 10 years?", you can only answer with a decisive "Yes and no". If what comes out in the end is pleasing to the eye, then that's all well and good. However, over time you get used to the peculiarities of a renderer and work around the problem, so to speak. Maybe you put a fill light here, change the color there to achieve the desired result, which might not have been necessary when using an LWF.

This is also the reason why old scenes do not automatically look better if you activate the LWF now, because they are designed to work well without the LWF.

If you keep using old, existing, optimized lighting configurations, you should adapt them when you switch to LWF. However, if you are satisfied with the rendering results, there is of course no reason to use only LWF.

Why are there actually gamma values?

Monitors, for example, usually have a gamma value of 2.2. If you paint a texture in an image editing program of your choice, this image will be displayed and saved with a gamma of 2.2. The vast majority of images that you have created yourself or that you find on the Internet have a gamma of 2.2.

Only with this gamma do images look good on an average monitor. This is due to the fact that images with a lower bit depth (8-bit and 16-bit) are stored in such a way that a brightness gradient satisfactory to the human eye is displayed. The eye is able to recognize finer gradations in dark image areas than in bright ones.

A gamma-corrected 8-bit image with gamma = 0.45 is displayed on a monitor (gamma = 2.2) with a linear brightness gradient for the human eye.

Renderers on the other hand (including CINEMA 4D) work internally with linear gamma gradients (i.e. gamma = 1; this is what the common algorithms want) and expect this from the things they are fed with (textures, shaders, etc.). However, this has not been the case until now. The renderer would like to have gamma = 1, but gets 2.2. It is logical that this results in deviations from the physically correct result.

As soon as the renderer has completed its work, it must reduce the color and brightness of the calculated image (unless it is saved in 32 bits - in which case the gamma adjustment is shifted to a subsequent processing step) and at the same time apply a gamma value (namely 2.2) so that the finished image can be displayed on the monitor in a meaningful way.

How does the LWF fit into the above? Quite simply, as soon as you activate the LWF, all elements required for the rendering process (textures, shaders etc.) are converted so that the renderer sees them with the required linear gamma (=1). After rendering correctly this time - the renderer also produces images with a gamma of 1 internally as a result - the images must be converted again to a gamma value that matches the output device (usually the monitor with gamma 2.2).

In a nutshell, this is the whole "secret" of the LWF. If you would like to read more details about what has just been described, please refer to the highly recommended PDF "Be gamma correct!", which is freely available on the Internet by Martin Breidt (an Internet search for these terms will take you there). Don't worry if it refers to a different 3D program in places, the functionality is basically the same.

You will find the color space "sRGB" in the settings of the lin. workflow. This is approximately the same as the gamma = 2.2 mentioned above, i.e. if images are saved for gamma = 2.2, this is usually sRGB.

"Simple" Color Mangement

General

Everyone has heard of it, but very few people understand it. This is not entirely unjustified, as entire books have been and are being written about it. Below you will find a brief introduction to the problem of color fastness.

You will certainly be familiar with the effect that an image that looks perfect on your monitor (the colors are exactly as you imagine them, brightness, contrast, tonal values, etc. are to die for) looks completely different, usually much worse, on your colleague's monitor or even printed out on paper.

Why is this?

Imagine colleague A, who has created the image in an image editing program. Logically, he works according to how his monitor presents the bitmap to him. At some point, colleague A decides that the image is now complete and saves it. And this is exactly where it starts: The image editing program must save the colors in a reproducible color definition (namely the color space, usually RGB). A color profile is usually selected for this, which corresponds to the output device, which is usually sRGB for monitors (but not necessarily!), CMYK for printers, etc.

In other words, the red value that colleague A sees on his monitor must end up as the corresponding RGB value in the file. It must be ensured that colleague A's monitor reproduces the colors exactly as the image processing program wants to display the RGB value. To do this, colleague A's monitor should be calibrated. Monitors change their color representation over the course of their service life and should be recalibrated every 4 weeks for real, continuous color management. Regular recalibration also applies to all input and output devices that the image passes through (monitors, printers, scanners, etc.).

If all this is guaranteed, the image (created by colleague A) should look exactly the same when scanned on the monitor of colleague C (who received it as a printout from colleague B) as it does on the monitor of colleague A. Anyone who has ever tried something like this knows how impossible this is (in fact, 100% conformity is not even possible, since not all device color spaces can be converted into others without loss). But at least on different monitors, an almost one hundred percent match can be achieved.

To put it simply, this is the problem that color management has to contend with. Basically, it's about consistent, unambiguous color definitions within the creation process through the editing process to the final display of an image.

And what does all this have to do with Cinema 4D?

The good news first: If you've never heard of color management and you create your renderings by eye: "Looks good. Fits!", then you can ignore this functionality with a clear conscience (and leave all adjustable color profiles in CINEMA 4D at the default sRGB ). Between you and me, "inexperienced" users often have a hard time seeing the difference between images that were created completely under color management and those that were produced using pi * thumbs.

Note:Only change the color profile settings if you know exactly what you are doing, as this can change all kinds of colors that have been familiar for years, which can lead to perplexed faces and shattered monitors. If in doubt, set sRGB everywhere again (see illustration below).
sRGB is the color space that has been used automatically for many years anyway, unless another color space has been explicitly defined. This is why, for example, 99% of all images found on the Internet are saved for this color space. CINEMA 4D (<R 12) has also saved images exclusively for the sRGB color space.

For everyone else, the "Places" in Cinema 4D where color profiles can be set are now listed:

The most important color profile settings in Cinema 4D.

As you can see here, there are virtually 3 "interfaces" to/from Cinema 4D where color profiles (or device profiles) are evaluated:

A list of all image formats that can handle color profiles can be found in the appendix.

Input Color Profile

Details can be found under Color management (sRGB is correct in most cases).

Here you define 3 things:

The text field below shows exactly what the selected option does.

sRGB

Linear

As long as textures have embedded color profiles, these options define how the color selection fields, color gradients, etc. are displayed in CINEMA 4D. sRGB is the usual display method (so always use this if in doubt). Linear is the unusual option that is more difficult to use.

Off

In this mode, embedded color profiles of textures are NOT taken into account, but an sRGB color space is always assumed. If the Linear Workflow option is deactivated at the same time, this corresponds to the mode known from earlier CINEMA 4D versions (< R 12).