Scene Requirements

Although you have probably never heard of me before, I've been developing C4D scenes for quite a while now. During that time, I have customized the process in many a way - by creating layouts to optimize mouse distances, by defining defaults and template scenes, by modeling basic multi-purpose structures, and, yes, by programming plugins.

Most of this is of no consequence for users of the Collie Tools. However, I also grew fond of a few rules that are reflected by special functionality of the tools, and which might be of importance.

Scene Structure

The following tree represents my Template.c4d scene which is loaded as startup:

Template scene

The top level of each of my scenes serves as "structure" level that separates model, environment, and temporary objects. There are generally three objects on that level.

The first is a null object called "Objects" (or "Scene", or "Models", or "Elements"... the names actually don't matter). It contains all variable elements of the scene I am working with. This is, well, almost everything. The Objects will also hold all tags which are relevant for the whole set, for example a commentary that tells me what the scene was for, or what version it is.

The second is a stage object, which contains environments, backgrounds, floor, sky, all scene lights and cameras that are not object-specific, and from time to time even geometry that is supposed to form a static scene (for example, room walls).

The third, invisible null object contains all the currently unused stuff I have cut from its position, but don't want to throw away right now, or save in a different file.

On some occasions, I may add a fourth null object "Props" which holds certain models I may or may not want to include in the variations of that scene I need to render. With small scenes, it doesn't make sense to store these props in separate files. This is not often used though, and therefore not part of the template.

That template has proven its usefulness on many occasions, which is why some plugin functions make use of it.

What you need to know:

The visibility and selection methods of the Named Structures have a flag "From top". When used, these methods will only affect the first object on the top level, but not the second or third. This is because I normally don't want to change visibility and selection in the stage branch, and never want to change visibility in the temporary objects.

If you work with a different hierarchy and need the "From top" modifier (yes, it's default and used quite often), you may want to put your complete hierarchy under a dummy null object, which encapsulates your scene.

Object Names

C4D is pretty lenient with object names, allowing any character combination to form a name. That is fine for users. It is not quite so fine for programmers who need to write something like expressions that work on names. As every developer knows, names are either restricted in use of special characters, or you need a really complicated tokenizer and parser to put the names together again, or you put everything in quote marks "" and use some escape sign to mark special characters.

As you may imagine, I am a programmer.

I am used to using restricted names (for variables and function names), and I am fond of applying rules to these names for easier recognizeability.

My names generally start with a letter and use only letters, digits, and a few selected special characters (underscore, dot, angular brackets, and the at-sign). I never use space, or normal brackets, or operator characters like *+/, not even the minus sign -. (I also normally use English words for names, since I work with some people who don't speak German, but that depends on the team.)

What you need to know:

The Collie Tools currently don't restrict the use of names in objects. However, the names for named structures need to follow the pattern above, since they can be combined in expressions.

The tokenizer and parser built into the Collie Tools for these expressions are far more powerful than needed now. They can understand mathematical terms and path names as well. This feature is not used in the current version, but may get used in the future. If you use spaces and special characters in your object names then, you may not be able to use the full functionality the Tools may provide.

I always found a stricter naming system to be useful, and not as confining as it may seem at first glance.


Back to Main Manual Page