If you just installed the Windows version of C4DtoA 2.x, and you don’t see C4DtoA in the Plugins menu, it’s probably because you need to install the Visual Studio 2015 redistributable.
You can’t. The background object isn’t visible in refractions. Or reflections, or anything but camera rays.
Here’s an example: a refractive sphere in front of a torus, in front of the background checkerboard object. The black areas are where the background object isn’t visible to refraction rays.
The “background object” is actually a shader plugged into the Arnold background slot.
You won’t see it in Cinema 4D, but when C4DtoA translates the scene to Arnold, the background object is translated as a shader plugged into the options.background parameter (in Cinema 4D, this is the Environment > Background parameter in the Render Settings).
In an ASS file, it looks like this:
options
{
background "c4d|Background"
}
image_plane
{
name c4d|Background
color c4d|Arnold_Shader_Network|checkerboard
lenx 1
leny 1
ox 0
oy 0
}
The image_plane node is a shader, and if you were to check its code, you’d see that it handles camera rays only; for any other ray type (like refraction), the image_plane shader returns black.
shader_evaluate
{
if (!(sg->Rt & AI_RAY_CAMERA))
{
sg->out.RGBA = AI_RGBA_BLACK;
return;
}
There’s an Arnold error that recommends setting the load_at_init parameter, but people don’t always know where to find that in their favorite Arnold plugin.
ERROR| [proc] c4d|Arnold_Procedural: bounds supplied to procedural node are not large enough to contain the actual underlying geometry. Replace given bounds: (-1, -1, -1) X (1, 1, 1), with: (-9.4028616, -9.43616867, -9.21633244) X (9.3304739, 9.43616867, 9.21633244). Setting the procedural's load_at_init parameter to true would also fix this.
The load_at_init parameter controls whether the procedural (standin) is loaded during scene intialization (before rendering starts), or during rendering (when a ray hits the procedural bounding box).
By default, load_at_init is false, which means that procedural loading is deferred until render time.
And so, in MtoA, C4DtoA, and SItoA, the load_at_init parameter is exposed as Defer Standin Load, which is enabled by default. In HtoA, you have a Load At Init parameter on for the Arnold Procedural node.
Arnold takes care of writing the built-in AOVs like N, P, Pref, A, and the all-important beauty. But it’s shaders that write to AOVs like direct_diffuse. That’s why something like this is not going to give you what you might expect in the AOVs:
layer_color doesn’t write to AOVs, so you won’t see the layered result in an AOV like direct_diffuse. standard does write to the direct_diffuse AOV (and others), but in this setup, you have multiple standards and they end up overwriting each other, so you get just the last standard output in the AOVs.
It’s better practice to avoid having multiple standard nodes in a single material; instead, layer the maps that go into the standard parameters like the diffuse and specular colors.
Or you could use a node like mix, or the third-party alLayer, which support AOVs. You can tell if a node writes AOVs by looking at its Attribute Editor: there’s usually a tab or list where you can change the names of the AOV outputs.
The C4DtoA installer puts the C4DtoA plugin in the default location: the plugins folder of the Cinema 4D install.
If you want to put C4DtoA somewhere else, like a shared network location, you can use the C4D_PLUGINS_DIR environment variable to point to your custom plugin location.
For example, on Windows I moved C4DtoA to a different drive and then set my environment like this:
set C4D_PLUGINS_DIR=F:\plugins set PATH=F:/plugins/C4DtoA/arnold/bin;%PATH%
Note that I had to set PATH so C4D could find ai.dll, and that I had to use forward slashes (on Windows, C4D doesn’t like backslashes in the PATH and drops them).
On Windows, the C4DtoA installer puts a second copy of ai.dll in the C:\Program Files\MAXON\CINEMA 4D R17, so you’ll have to remove that ai.dll, and use PATH to point to the ai.dll in the C4DtoA arnold/bin folder.
C4DtoA requires R17.032
I’ve had a number of cases where people had earlier versions of C4D R17 and couldn’t use C4DtoA. That’s because C4DtoA was built against the C4D R17.032 SDK.
Here’s the beauty and the alpha in the Arnold IPR Window:
The opacity of the top plane is controlled by the Image node plugged into the Refraction > Opacity:
Of course, you need to disable Opaque on the plane:
The Arnold log is important, not just for troubleshooting and getting help from us at Solid Angle, but also for understanding what’s going on when Arnold renders your scene.
But, first things first: where’s the log? The Arnold log is output to the Cinema 4D Console:
To open the Console, click Script > Console.
You can set the verbosity level in the Render Settings > Diagnostics. By default, the verbosity level is Warnings, but by increasing it to Info, you’ll get the % done log entries. You can also send the log to a file (good for logging support cases!).
Arnold doesn’t support .mov files for textures, but with C4DtoA you can use the Bitmap shader to load image sequences like seq_0000.tx, seq_0000.tx, seq_0000.tx, …
Under the covers, C4DtoA doesn’t actually implement the Bitmap Shader. Instead, C4DtoA translates the Bitmap Shader to an Arnold Image shader
Arnold Support Corner 