Here is a quick post to share a piece of python code that I use in nearly every C4D scene these days. It is really simple and all it does is take the current state of the objects “Visible in Editor” parameter and apply it to the same objects “Visible in Render” parameter.

I use this to hide objects that I don’t want to render. You can of course simply keyframe both parameters, but this means you only need to key the Visible in Editor parameter. Another option is to use a Display tag which will also allow you to keyframe the object visibility. So it is nothing revolutionary that I’m offering (sorry about that

The reason I use this is simply because you have a visual indicator in the Object Manager of the current state of an objects visibility, you don’t get this with the Display Tag unfortunately. Would be kinda cool if the eyeball closed to indicate visibility, similar to PS layer switches.

Anyway here’s the code, simply copy and paste this into a Python Tag and then choose File > Save Tag Preset in the Object Manager. The tag will be there for you every time you need it.

Start copying here…

import c4d
#Welcome to the world of Python

def main():

# get object tag is attached to
obj = op.GetObject()

# get visibility from editor
visibility = obj[c4d.ID_BASEOBJECT_VISIBILITY_EDITOR]

# pass editor visibility to renderer visibility
obj[c4d.ID_BASEOBJECT_VISIBILITY_RENDER] = visibility

…Stop copying here

Thanks to Patrick Goski who actually wrote this little snippet of code.

By the way if you get errors when you copy and paste this, it may be because of the formatting, so make sure you don’t use tabs and that it looks like this..

I recently completed a tutorial for the Maxon’s You Tube channel. It goes into quite a bit of detail, so for that reason it is split into 4 parts.

Something you might be interested in?

I’ve copied some of the blurb from the You Tube page here so you get an idea of what I cover in the tutorial. If you want to check it out then please visit the Maxon You Tube channel.

In this tutorial, Tim Clapham from Luxx takes you step by step through the process of creating a Motion Graphics animation with CINEMA 4D.

You will learn how to use MoGraph elements such as the Cloner Object and how various effectors can be used to control the generated clones.

Working with Release 13, Tim covers several of the newer features such as the XRef object and the new Physical Renderer. However, throughout the process, options are presented to enable users of versions prior to Release 13 to complete the tutorial.

You can view the first section here, but why not visit Maxon’s channel and you can watch the other sections and also check out some other great videos.

Here’s another little tip for working with Cinema4D, specifically Thinking Particles. I offer up a solution to what appears to be quite a common problem with TP and hopefully this small tutorial will stop a lot of head scratching.

This time around, I show you a simple technique you can use to stop the pulsing you sometimes see with Thinking Particles when your emitter is moving too fast and you get those big lumps of particles emitted on every frame rather than a nice smooth emission..  Yes – you guessed it, this is sub-frame particle emission.

Of course this tutorial doesn’t cover many of the different ways that you can emit particles using TP but hopefully it gives you some idea of a solution that you can adapt to your own TP scenes.

 

Check out the quick tip over on the helloluxx vimeo channel.

If you ever wanted to work with high and low resolution models in Cinema4D then this tip should come in handy.

Using the Instance Object combined with a simple Xpresso setup, this shows you how to create an object that allows you to work with a low polygon model and then swap this out for a high polygon version whenever you need to render or preview the final result.

This technique will keep your workflow streamlined, and allow you to perform tasks such as dynamics simulation and caching without the overhead of polygon heavy scenes. Once the caching is complete, you can switch out the object for the detailed version and render away.

Once created, this simple object will become a vital part of your Cinema4D library. You’ll never know how you worked without it!

Kudos to Kai Pederson who originally showed me this trick.

For more in depth and detailed tutorials, check out the Learn Dynamics for Cinema4D training collection. Over 10 hours of intensive training for working with Cinema4D and Dynamics. Available to purchase online here

Here is a setup that you can use when working with Thinking Particles and emitting into objects. This setup allows you to emit particles from multiple objects but only using one emitter. The principle is as follows…

You basically iterate through a list of objects. Then pass these objects into the volume position node, the result being that the particles are then placed into each object from the list. There is also included a simple method of enabling or disabling the objects from being included. Therefore you can control which objects have particles inside or not on a per object basis.

The great thing about a setup like this is that it is fairly simple to use and expand. It is easy to adjust the particle emitter as you are only using one emitter, yet it is quite powerful because it allows you to emit particles into an infinite number of objects. Well ok, perhaps not infinite, but you can certainly emit into hundreds if not thousands of objects with relative ease.

If you look at the screenshot above it may look like the particles are all in the same mesh, but each letter of the logo is an independent object. This means each letter can be transformed, textured and animated individually. Yet all the particles are generated with one emitter.

Anyway enough of this banter, how does it actually work?

Here is a screenshot of the Xpresso setup. The first node is the Object List node. You can find this by right clicking in the Xpresso window and choosing
New Node > Xpresso > Iterator > ObjectList

This node is really handy as it allows you to drag any objects from your scene into the Iteration List field and it will then iterate through the list. In other words it will output the object for every object in the list. It doesn’t matter where in the object manager hierarchy these objects are, so they don’t all need to exist in the same hierarchy. If you do want to add multiple objects by shift or control clicking to select your objects, remember to lock the attribute manager with the ObjectList parameters visible before you start clicking in the object manager to select your objects. If you don’t, you’ll lose the Iteration List field and will have to go back and select the ObjectList node in your Xpresso window again.

The next node along is a simple object node. Link the Instance output into the object node Object input port. If you drag one of your objects into the Xpresso window it will automatically add the Object node for you. You can see I dragged the ‘L’ object into my setup.

To emit particles we will use the most basic of all the TP generators. We would like to create particles and we are not really bothered about speed, position etc at this point in the setup. ThePBorn node is found under…
New Node > Thinking Particles > TP Generators > PBorn

Next we need to place our particles into each of the objects. To do this we can use the PVolumePosition node.
New Node > Thinking Particles > TP Helper > PVolumePosition

The PVolumePosition node allows us to specify an object volume that we would like to use with our particles. So you could link an object node output port into the PVolumePosition Object input port. However we want to iterate through our list, so we will link the ObjectList Instance output into this port instead. This in itself will not place the particles into the objects. We need to explicitly define the particles we would like to affect and what we would like to do to them. We use the PSetData node for this, which can be found under
New Node > Thinking Particles > TP Standard > PSetData

First of all you drag the Particle Birth from the PBorn node into the PSetData Particle input port. This tells the node that these are the particles we would like to affect. We then drag the PVolumePosition Position output and link it into the PSetData Position input port. Basically saying that we would like to place our particles into the positions that are defined by the PVolumePosition node.

So in a setup where you use one object, this would all work fine now. If you have been building the setup as you read through this, then press play and you will probably see all your particles being created in the first object that you placed into the ObjectList. It seems that it isn’t iterating through the list. So at this point we can employ a new trick which offers another benefit as well. We need to force the PBorn node to refresh on each frame. By default the PBorn node is on. If we link our iteration through the On port of the node it will check this port for every frame as the ObjectList iterates through each object. The trick I chose to use for this was to link the Xray checkbox into the PBorn On port. By doing this we have the added benefit of including or excluding objects from the setup depending on the state of the Xray checkbox. Of course you don’t need to use the Xray checkbox, you could add some userdata and link that to the On port.

In my setup the Object from the ObjectList is passed through the Xpresso, the Xray checkbox is evaluated, the particles are created and the same object is passed into the PVolumePosition and the particles are placed there. The objects are of course iterated through, so this happens for all the objects in the list. This is then repeated.

So as you can see a nice simple setup with a great workflow and lots of potential. Certainly saves creating an emitter for every object you’d like to place particle into. Now what you do with those particles is entirely up to you.

If you’d like to download the sample scene I created which demonstrates this then click here. It was made in 11.5, but should be fine in r11 and r12 too. Have fun!

Linear Workflow is a relatively new feature for Cinema4D. Before the introduction of Linear Workflow in C4D Release12 it was only possible through the use of third party plugins such as DeGamma by The Third Party.

This article aims to explain the concept behind Linear Workflow (LWF) and in the process look at the correct techniques, file formats and procedures when using LWF in your studio pipeline.

The information in the following post comes from an extremely informative and helpful document which was written by Philip Losch. Philip is one of the mastermind geniuses responsible for Maxon’s Cinema4D.

I’d like to thank Philip for giving me permission to use his material here.

Why LWF?

Today’s monitors are not capable of showing colors how they really are. Let’s take a look at an example:

The surprising answer is: not the right one. The left one should – depending on your monitor – be pretty close.
Why is this surprising? We’ll see that when we zoom into the image:

At the top is a regular pattern of black & white pixels. At the bottom left the grey has a value of 192 (= 75%) and at the bottom right of 128 (= 50%).

Now… shouldn’t an even mix of 0% black and 100% white pixels blend into something like the bottom right grey of 50%?
At least that’s what we were taught in math: (0% + 100%) * 1⁄2 = 50%.

Unfortunately monitors do not work that way. The do not show colors linearly. The center of 0% and 100% is not 50% on a monitor. Monitors display the incoming signal with a so called gamma curve (actually it is even more complicated, but we’ll stick with this easier idea for a moment).

From left to right is your input image color. From bottom to top the actually shown color. So if the image color is 50% gray the real color shown is only about 18%. And to have a 50% gray displayed, you need an image value of about 75% (you can see the red dotted line).

As mentioned above the reality unfortunately is even more complicated. Monitors have so called ‘color profiles’. A color profile is such a curve definition – however with a possible interaction of Red, Green and Blue components. A color profile can do anything – e.g. it can substitue red for 50% green, it can add red and green and assign it blue… As an image looks widely different on devices with different color profiles many image formats allow to embed a colorprofile that ‘records’ under which conditions an image was created.

Most images nowadays are created with a so called sRGB color profile. sRGB roughly looks like the above curve and affects Red, Green and Blue components independently.

But isn’t it a dumb idea to build monitors that don’t show colors linearly and not “how they really are”? The answer is yes and no – unfortunately our human eye sees light intensities in a nonlinear way too and is more susceptible to certain ranges of intensities.

This would not matter as much if we had displays with unlimited color resolution (floating point or ‘HDR’ displays), but monitor technology for the most part is still stuck at 8 bit color depth per channel (or sometimes 10 bit for medical displays).

So now that we know we have to make do with this existing technology, we have to look for a better solution. Actually, there is the possibility to correct this with software – this is where Linear Workflow comes in.

The main problem of renderings created without LWF: lights are overblown and colours mix badly (‘unnaturally’). While the artist can compensate for parts of it by adjusting lights, falloffs, colours etc., this is only possible to a certain extent.

How LWF works

CINEMA 4D is clever enough to offer you a “one button” solution – and by default LWF is automatically activated in new scenes.  If you are wondering where abouts you find this one button solution.  Open the project settings (Control-D or via the Edit Menu).

It helps to understand how this works internally, especially when you need to use your rendered images in other applications later. Let’s focus on the upper path in the following image (LWF on):

LWF works in three steps:

Step 1: Before rendering all so called ‘assets’ (which are any colors, bitmaps or external references) are transformed from their colorspace (or sRGB colorspace, if they do not have a colorspace assigned) into linear colorspace.

Step 2: The render engine does all its calculations in linear colorspace.

Step 3: The rendered image is transformed from linear colorspace into the colorspace that the user chose for image output. The colorspace –if the image format permits- is embedded into the image.

There is no rule without exception: if your texture or colour is in a bump channel, alpha channel, normal channel or displacement channel the ‘raw’ image data is used (so step 1 is omitted). The reason for this, is that other applications like Z-Brush expect their images to work a certain way and contain direct height information (so e.g. black equals 0m height, white equals 100m and 50% gray equals 50m). You can also think of it this way: all material channels that don’t have anything to do with direct material colors (bump and normal channels change lighting only, alpha cuts out parts of the material and displacement changes the elevation) do not undergo this first conversion step.

Here’s a concrete example of this process:

Step 1: A sphere’s texture is an 8-bit image with no color profile embedded.

As the image has no color profile C4D assumes it is using sRGB (the the most commonly used profile).

Let’s also assume the sphere’s texture is 75% blue.

C4D now transforms this color from sRGB colorspace into linear colorspace. So the value of 75% becomes 50%.

Step 2: C4D does all lighting calculations linearly (and this is why the images will be so much superior – there is no color ‘distortion’ happening anymore).

Let’s assume a pixel is 50% illuminated. So we get 50% * 50% = 25% blue.

Step 3: The calculated image is converted into output color space, which in this example shall be sRGB again.

Our 25% become roughly 56% blue after transformation by applying the sRGB curve.

So the end result for our pixel is 56%, while in traditional rendering it would have been 75% * 50% = 37%.

And so they used LWF and lived happily ever after..

Not so fast! If you thought we only had to deal with !%§!$ hardware I have to disappoint you – as we’re also unfortunately living with !%§!$ software! It will take years and years until most software can properly handle colour profiles, linear workflow etc.

Fortunately Cinema4D, AfterEffects and Photoshop (and several modern compositing applications, for example Nuke) can play nice together – as long as you choose the right settings.

Let’s go through the limitations and problems step by step.

1.) Windows and Mac OS X

The operating systems now have some support for colour profiles. While OS X does a pretty good job evaluating image profiles, Windows 7 works for some image formats, older versions of Windows do not evaluate colour profiles. To view images, it is best use C4D’s Picture Viewer – as it always supports colour profiles.  If you check the View menu, you will see there is an option to view the image with the Colour Profile or without.  Select the Information Tab, and you can see the Colour Profile assigned to the image currently being viewed.

2.) Image formats

Lots of image formats do not support embedding of color profiles. While this is no problem when you render images to sRGB colourspace (as most applications naturally assume this) it becomes a big problem especially in combination with Multipass renderings and linear workflow where the image colour profiles must be linear.

You can choose your desired output Colour Profile in the Cinema4D Render Settings – Save options.

Always try to choose a format that supports colourspace information, unless

• You render a regular image to sRGB colorspace

• You render Multipasses, but don’t have LWF activated

• You render Multipasses, but know how to adjust the settings in your compositing application

The following image formats do not support colourspace information:

BMP
DPX (8- and 16-bit)
OpenEXR (8- and 16-bit)
IFF
RLA
RPF
TGA
Quicktime xxx (xxx = any format)
AVI Movies
Quicktime Movies

3.) 32-bit images

A specialty applies when you use 32-bit images for in- or output. By definition a 32-bit image is always saved in linear colourspace.  C4D takes care of this for you automatically. If you choose 32-bit output the colour space option for the saved image is automatically disabled and linear colourspace is used.

4.) Photoshop CS 4 and higher

Photoshop reads and writes regular images without any problems. Single-File Multipass images are also handled correctly with one exception: if you render without LWF and output to 32-bit Photoshop can no longer composite the image properly. This comes from the above mentioned limitation that 32-bit image formats do not contain any colour profiles.

5.) AfterEffects CS 4 and higher

The most important setting in AfterEffects that needs to be adjusted is “Linearize Working space” in your project settings.

If you render with LWF in C4D this option needs to be enabled; if you render without LWF in C4D it needs to be disabled.

The reason for this is: Multipasses ‘outsource’ calculations to a compositing application. This only works though if the compositing application does the same mathematical calculations as the render engine, which means the colourspace they’re operating in needs to be identical.

Once you have Colour Management enabled in your After Effects projects, when you select a footage item, it will show you the Colour Profile in the top of the Project Window next to the thumbnail.  You can check here to ensure the profile is being read correctly.

Try to use 16-bit colour depth or higher to avoid the occurrence of banding – as multipasses sum up multiple layers and then have the result transformed into monitor colourspace 8-bit usually isn’t enough.

For special passes like UVW data, Normals maps etc. activate the setting “Preserve RGB” in the “Interpret Footage” dialog to use the “raw” uncorrected data (not influenced by any color profile).

So there you have it. Linear Workflow with Cinema4D and After Effects in a nutshell. Hopefully this article helps to clear up any questions you may have had regarding LWF and C4D. Once again, huge thanks to Philip Losch for originally preparing this information and allowing me to post it up on helloluxx.

In this tutorial I demonstrate a technique that allows you to create a sticky type effect with your dynamic simulations in Cinema4D.

By using the Force object in combination with Step Falloff you can create a setup where the objects stick together depending on the force applied.

Check out the tutorial below, or watch it on Vimeo.

You can download the scene file here.

A new collection of training for Cinema4D R12 will soon be available.

This teaser shows an example of the content that is covered in the tutorials.

This tutorial from demonstrates a method to create Thinking Particles from Dynamic Collisions using Cinema4D and some simple Xpresso.

Although the technique described is fairly basic, this will lay the foundation for much more complex effects that are possible by developing the principle further.

Download the scene file for this project here.

A new collection of training for Cinema4D R12 will soon be available.

This teaser shows an example of the content that is covered in the tutorials.