Named Structure Tools

If you have not yet read the chapters on Branch Open/Close Tools and Visibility Tools, you should do so. Named Structures work most effectively when used together with these simple "branch" commands. Named Structures is currently the most complex concept in the Collie Tools, so you might want to take your time reading this chapter.

Contents

What problem does it solve?

How does it work?

How is a Named Structure used?

Example

Visibility Control

Selection Control

Excluding Children

Named Structure Expressions

Using Wildcards

Setting and Removing NS Tags by Dialog

What problem does it solve?

Cinema 4D currently does not support layers in the object manager. Layers are a way to control the visibility of logical object groups, even if they are not "related" (physically grouped) in the object manager.

C4D allows to set the visibility of each object to visible, invisible or undefined (inherits visibility from parent in tree). As stated in the chapter on Visibility Tools, that is fine for the control of branches. And the Visibility Tools themselves add more functionality for the control of visibility on branches. So, what is the problem?

The problems start when objects are not in the same branch, but logically belong together.

The object tree determines the kinematic relationship of objects. This relationship is the most important in 3D mechanics. It can be overridden by the Kinematic Tools or other expressions, but these are special cases that should be handled with care. For most models, a hierarchy like torso - chest - shoulder - upper arm - lower arm - hand - finger still determines how the parts of the whole figure move.

But kinematic relationship is not the only grouping aspect in modeling. For example, imagine that the figure we model is a humanoid robot, which is built from a skeleton, wiring, and cover plates. For maximum effect, we want the wiring to be visible through gaps in the covers, and the skeleton to be visible under the wiring. So, all these elements are visible in the final rendering, none of it is "virtual".

To make the robot move, we need a tree that reflects the kinematic structure of the movement. Namely, the skeleton, which will determine our tree. Torso - chest - shoulder - ...

Since the wiring and the cover plates are supposed to move with the arms and legs, they are parts of the same hierarchy. The upper arm cover plate is part of the upper arm assembly, the hand cover plate is part of the hand assembly, and so on.

So far, so good... Now while we are working on our robot, we notice that the cover plates are in the way when we want to fine-tune the skeleton. How do we switch off the covers, all of them, in a single step? If we make a branch invisible, then the skeleton and the wiring also get invisible. If we switch the visibility tag on each cover manually, we will get crazy.

That is where layers come into play (supposed we have something like layers). We assign all the cover plates to a cover layer, all the wiring to the wiring layer, and the skeleton to the skeleton layer. The actual position of the element in the tree hierarchy does not matter. Each layer can now be switched on or off, to make the structure visible or invisible.

This is what layers would do. Now, Named Structures are something similar, but not quite. Why? Because layers also pose a lot of problems (which is why we don't have them yet, I guess!). What should the program do in case of conflicts between layer visibility and object visibility? Let's imagine we switch the cover layer to "visible", but the hand cover has its visibility set to "invisible". I guess the layer's settings take precedence. Of course, that means we need a layer setting "undefined" to allow the objects' settings to shine through. But what if we need to override the layer's settings? (There may be objects in that layer we don't want to see now!)

Or even better (think about that): What happens if an object is set to invisible, its layer is set to visible, and the object has a child that is set to "undefined" but which is not in that layer. Will that child inherit the current visibility of the object (since the child is not in the layer), or of the layer (since that is how the parent object really appears)!? Think about it. There are good arguments for both interpretations.

You will also quickly see that there is a need for objects to be in more layers than one at a time. Take the front wheel of a car... it is part of the steering assembly. At the same time, it might be part of the chassis, of the drive (front wheel drive ;-) and of the axis (which is probably the tree parentage). Depending on the purpose of the 3D model, all of these logical groups require a layer of their own, and the poor wheel is part of all of them. I don't want to get into the visibility problems here...

Named Structures set up logical groups, just like layers. But they avoid the visibility problems - they don't have a visibility tag of their own. They can set the visibility of their objects, but they do it by setting the objects' visibility, not overriding it. The nice thing about this method is that visibility control is simple, and you can prevent the visibility change by setting a Block tag - and it is possible to assign an object to multiple Named Structures at the same time!

What you can not do is check the visibility status of a Named Structure. For lack of a visibility tag, there is no such status.

(next page)


Back to Main Manual Page