Szenen-Anforderungen

Ich arbeite jetzt schon eine ganze Weile mit C4D. Dabei habe ich, wie es sich gehört ;-), den Entwicklungsprozeß auf meine speziellen Anforderungen abgestimmt - durch mauswegoptimierende Layouts (Dual Screen rocks!), durch passende Defaults und Template-Szenen, mittels wiederverwendbarer Strukturen, und, ja, auch durch Plugins.

Das meiste davon dürfte die User der Collie Tools nicht interessieren. Jeder hat so seine speziellen Wünsche und Bedürfnisse. Aber ich habe mich auch an einige wenige Regeln gewöhnt, die in der speziellen Funktionalität der Tools ihren Niederschlag finden, und die für Sie wichtig sein könnten.

Szenen-Struktur

Der folgende Objektbaum repräsentiert meine Szene Template.c4d, die beim Startup geladen wird (lesen Sie das Cinema-Handbuch, falls Sie nicht wissen, was ich meine):

Template scene

Die oberste Ebene jeder meiner Szenen dient als struktureller Level, der Modell, Umgebung und temporäre Objekte trennt. Entsprechend gibt es normalerweise drei Objekte auf dieser Ebene. (Und nein, ich habe nicht vergessen, den Screenshot zu übersetzen. Ich benutze gewöhnlich englische Bezeichnungen in den Modellen, so auch im Template. Es arbeitet sich einfach besser mit nicht-deutschprachigen Kollegen zusammen, wenn alle das Modell lesen können ;-)

Das erste ist ein Nullobjekt namens "Objects" (oder "Scene", oder "Models", oder "Elements"... die Benennung ist nicht so wichtig). Es enthält alle variablen Elemente der Szene, an der ich arbeite. Das ist so ziemlich der ganze Inhalt... Das Objects ist außerdem Träger aller Tags, die für die gesamte Szene relevant sind, zum Beispiel Kommentartags, die mir später mitteilen, wozu die Szene gedacht war oder welche Version dieser Szene hier vorliegt. Glauben Sie es oder nicht, eine geschickte Versionierung ist ziemlich nützlich und nicht allzu mühevoll. Wenn Sie sich je durch fünfundzwanzig Varianten eines Modells wühlen mußten, auf der Suche nach dem Original, werden Sie nur nicken. Deshalb ist das Kommentartag auch gleich im Template mit enthalten.

Das zweite ist ein Stage-Objekt ("Bühne"), das Umgebung, Hintergrund, Boden, Himmel, die Szenenbeleuchtung und allgemeine Kameras enthält, also alles, was nicht an dynamische Objekte gebunden ist, und hin und wieder auch Geometrie, die eine statische Gruppe bildet (beispielsweise Zimmerwände).

Das dritte, unsichtbare Nullobjekt enthält den ganzen gegenwärtig unbenutzen Kram, den ich aus der Szene ausgeschnitten habe, den ich aber weder wegwerfen noch in eine andere Szene auslagern möchte.

Für manche Gelegenheiten füge ich auch ein viertes Nullobjekt "Props" ("Requisiten") hinzu, das Teile der Szene beinhaltet, die ich in manchen Renderings einfügen möchte, in anderen aber nicht. Bei kleinen Szenen lohnt es sich nicht, diese Requisiten in separaten Dateien abzulegen oder komplette Varianten der Szene mit und ohne Requisiten zu speichern. (Es lebe der Dateienwirrwarr...) Ich benutze diese Option jedoch nicht häufig und habe sie nie im Template integriert.

Das Template hat seine Nützlichkeit bei vielen Gelegenheiten beweisen können, weshalb auch die Plugins einen gewissen Gebrauch davon machen.

Was Sie wissen sollten:

Die Sichtbarkeits- und Selektionsmethoden der Benannten Strukturen haben ein Flag "Von Anfang Hierarchie". Wenn man es benutzt, beeinflussen diese Methoden jedoch nur das erste Objekt der obersten Ebene (und dessen Unterelemente), nicht aber das zweite oder dritte. Das liegt daran, daß ich normalerweise die Sichtbarkeit und Selektion im "Stage"-Zweig nicht ändern möchte, und garantiert keine Sichtbarkeitsänderungen in dem Zweig der temporären Objekte haben will.

Falls Sie mit einer anderen Hierarchie arbeiten und das Flag "Von Anfang Hierarchie" benutzen wollen (es ist defaultmäßig angewählt und wird in der praktischen Arbeit häufig gebraucht), können Sie Ihre gesamte Hierarchie unter ein Dummy-Nullobjekt eingliedern, das Ihre Szenenstruktur kapselt. Dann beeinflussen die Werkzeuge Ihre gesamte Szene. (Ich empfehle allerdings eine Untergliederung wie die obige - es hat sich einfach bewährt.)

Objekt-Namen

C4D ist recht großzügig, was Objekt-Namen angeht - es erlaubt praktisch jede Buchstabenkombination, um daraus einen Namen zusammenzusetzen. (Namen erscheinen ja in Eingabefeldern und nicht in Freitext-Form - warum sollte man sie also beschränken!) Das ist hübsch für Benutzer. Es ist weniger hübsch für Programmierer, die so etwas wie Ausdrücke schreiben wollen, die auf Objekt-Namen operieren. Wie es jedem Entwickler von Programmiersprachen her vertraut ist (ja, auch COFFEE), sind Namen normalerweise entweder in der Zeichenwahl beschränkt, oder man benötigt in seiner Sprache richtig komplizierte Tokenizer und Parser, um die Namen aus einem Ausdruck herauszufischen, oder man setzt alle Namen in Anführungszeichen und benutzt ein Escapezeichen für Sonderbuchstaben.

Wie Sie sich denken können, bin ich Programmierer ;-)

Ich bin es gewohnt, zeichenbeschränkte Namen (für Variablen und Funktionsnamen) zu benutzen, und ich mag es, eine regelbasierte Systematik in meinen Namen zu verwenden, um sie leichter zuordnen zu können.

Meine Namen beginnen normalerweise mit einem Buchstaben und benutzen nur Buchstaben, Ziffern und ein paar ausgewählte Sonderzeichen (Unterstrich, Punkt, eckige Klammern, und das at-Zeichen @). Ich benutze grundsätzlich keine Leerzeichen, gewöhnliche Klammern oder mathematische Operatoren wie *+/, nicht einmal das Minus-Zeichen -. (Außerdem verwende ich englische Benennungen, siehe oben.)

Was Sie wissen sollten:

Die Collie Tools beschränken die Namenswahl in Objekten nicht. (Ich wette, Sie hatten jetzt das Gegenteil erwartet...) In Namen für Benannte Strukturen ist es jedoch erforderlich, daß Sie die obigen Regeln beachten, da diese Namen in Ausdrücken zusammengesetzt werden können.

Der Tokenizer und der Parser (das sind Programmteile, die Ausdrücke zerlegen und auswerten), die zur Zeit in den Collie Tools eingebaut sind, sind erheblich mächtiger, als es für den aktuellen Stand der Tools eigentlich erforderlich wäre. Sie können selbst mathematische Ausdrücke und Pfadnamen "verstehen". Dieses Feature wird in der aktuellen Version nicht benutzt, könnte aber in einer späteren zum Einsatz kommen. (Die "verlorenen" Tools haben damit gearbeitet...) Falls Sie darauf bestehen, Leerzeichen und Sonderzeichen in Ihren Objektnamen zu verwenden, ist es möglich, daß Sie später mit erweiterten Features Probleme bekommen. (Ob Ihnen das wichtig ist, ist eine andere Frage ;-)

Ich persönlich habe ein strikteres Benennungssystem immer mehr als Unterstützung empfunden denn als Einschränkung.


Zurück zur Handbuch-Hauptseite