Wer ein neues Austauschformat etablieren will, muss dessen Adaption so einfach wie möglich gestalten.Für die universelle Fixture Library steht daher der GDTF-Builder bereit. Wir zeigen die ersten Schritte zum eigenen GDTF-File.
Wie wir bereits aus dem GDTF-Beitrag aus Production Partner 1/22wissen, ist GDTF ein Format zur Datensammlung und zum Austausch von Scheinwerferparametern. Die Daten von Scheinwerfern sollen zur durchgängigen Weiterverarbeitung in beliebiger Soft- und Hardware, die zur Planung und Durchführung von Shows benötigt wird, bereitgestellt werden.
Folglich muss man das GDTF-File mit Daten über den Scheinwerfer, den wir im folgenden Fixture nennen wollen, füllen: Für das DMX-Pult braucht es die DMX-Wertetabelle, für den Beleuchtungsplan eine symbolische Darstellung des Fixtures in Auf-, Seiten- und evtl. in Frontalansicht. Für das Pre-Programming müssen die optischen Eigenschaften des Lichtstrahls und die Beeinflussung derselben mit Gobobildern, Prismen und eben allem, was den Strahl beeinflusst, abgebildet werden. Zu guter Letzt fehlt noch eine nette Ansicht auf das Fixture, um das Gerät auch bei der virtuellen Kamerafahrt durch die visualisierte Eventlocation glänzen zu lassen und Kunden zu beeindrucken. Man könnte die Integration theoretisch eines Tages so weit gehen lassen, dass man mit virtuellen Scheinwerfern eine Party im virtuellen Raum feiern kann – die Unreal Gaming Engine lässt grüßen.
Doch bevor wir die eventuellen Möglichkeiten der Bibliothek erörtern, wollen wir ein GDTF-File erstellen. Dazu rufen wir die Website https://fixturebuilder.gdtf-share.com/ auf und melden uns an. Für die Verwendung der Webseite ist im Vorfeld eine Registrierung notwendig. Die Anmeldung mit dem eigenen Klarnamen kann von Bedeutung sein, denn der Urheber eines Files wird benannt. Wenn man ein vorhandenes File aufruft und unter dem eigenen Namen verändert und abspeichert, bleibt der Urheber weiterhin ersichtlich, man selber wird jedoch zum Urheber der Variante. Einmal eingeloggt, erfolgt die Auswahl, ob man ein neues File erstellen möchte oder ein vorhandenes bearbeiten will.
Nach der Anmeldung erfolgt die Auswahl, ob man mit einem neuen File beginnen will oder eine vorhandene Datei bearbeiten möchte (Abb. 1) (Bild: Herbert Bernstädt)
Wählt man „Conventional“ als Grundlage, so befindet sich in
der Vorlage bereits ein 1-Kanal-gepatchter PAR-Scheinwerfer, den man nun so verändern kann, wie man es für seinen statischen Scheinwerfer benötigt. Ein frischer LED-PAR befindet sich erst einmal mit einer Fünffarbmischung im Patch. Die Auswahl „MovingHead“ bietet immerhin schon die passende Geometrie, damit sich ein Kopf im Bügel und dieser sich auf einem Basement drehen kann – DMX bereits angelegt. Zuletzt der „Scan“, bei dem der Spiegel bereits angelegt ist.
Bei unserer Einführung werden wir mit einem vorhandenen Fixture beginnen, dessen GDTF-File wir vom Browser einfach per Drag und Drop in das dafür vorgesehene Feld „hineinwerfen“. Natürlich könnte man auch mit einem komplett leeren File beginnen.
Eines muss man den Machern des Builders lassen: Es ist ein hervorragend gelungenes Tool zur Erstellung der GDTF-Files und Nutzer werden Schritt für Schritt durch den Prozess geführt.
Schrittweise hangelt man sich von einem Eingabefeld zum nächsten – wir fokussieren uns auf das einfachste Feld: Fixture (Abb. 2) (Bild: Herbert Bernstädt)
Wir betrachten im ersten Schritt des Anlageprozesses die Erstellung der allgemeinen Fixture-Informationen. Dementsprechend heißt der Menüpunkt auch „Fixture“. Unter „Geometry“ folgen die dreidimensionalen Körper des Scheinwerfers. Unter „PhysicalDescriptions“ finden sich die Beschreibung der Lichtquellen, Filter und Steckverbinder. Logisch, dass man unter „Wheels“ die Eigenschaften der strahlbeeinflussenden Goboräder, Animationsräder oder Prismen findet. Mit „DMX“ erfolgt dann der wichtigste Part: die Zuordnung des Fixture-DMX-Table mit den physikalischen Eigenschaften, die man zuvor definiert hat. Es hat also keinen Sinn mit DMX beginnen zu wollen, wenn vorher nicht die Grundlagen geschaffen wurden. So ist es nur konsequent, sich mit den Buttons „Next“ und „Back“ an diesen Eingabepunkten entlangzuhangeln.
Den Namen (A – Abb. 3), den man bei der Anlage des Fixtures vergibt, findet man im automatisch generierten Dateinamen des GDTF-Files wieder, diese Information ist entsprechend wichtig. Liest man in der DIN SPEC 15800 nach, was sich hinter „Namen“ verbergen soll, dann findet man als Erläuterung nur „Name of the Fixture Type“. Dieser Name ist letztlich auch der Begriff, den man z. B. im Patch eines Pultes oder auf der Share-Seite suchen würde. Folglich sollte diese Bezeichnung eindeutig sein und über evtl. vorhandene Varianten Aufschluss geben, z. B. ob es sich um eine Version mit Blendenschieber handelt. Dann sollte dies im Namen mit zum Ausdruck kommen. Ein Filename wie: Cameo@OPUS_SP5P@ Firmware_1.0_GDTF_V01.gdtf entsteht automatisch nach folgendem Schema: „Manufacturer“ @ „Name“ @ „Revision Name“. Der Revisionsname wird beim Upload bzw. Speichern abgefragt. Zum Thema „Upload“ kommen wir noch.
Doch zunächst zur „Type ID“ (B – Abb. 3). Die „Type ID“ ist eine GDTF-Identifikationsnummer für ein Fixture. Erstellt man ein neues Fixture, wird diese Nummer neu generiert und kennzeichnet damit, dass es sich um ein neues, individuelles Fixture handelt.
In der ersten Eingabeseite „Fixture“ wird das neue Element im Groben definiert, und die Bilder und Grafiken dem Fixture zugeordnet. Die alphabetische Zuordnung A-E findet sich im Kapiteltext wieder (Abb. 3) (Bild: Herbert Bernstädt)
Wenn man ein neues Fixture aus einem anderen bauen will, da womöglich sehr viele Informationen übernommen werden können, wird mit dem Laden des GDTF-Files eben diese Nummer mitgeladen. Wenn man es nun speichern, sprich uploaden würde, dann wären alle Änderungen des neu erstellten Fixtures aber nur eine Variante des vorherigen Fixtures. Damit man nun ein neues Fixture auf Grundlage eines bereits vorhandenen Gerätes als ein eigenständig, neues Element definieren kann, muss man eine neue Type ID generieren. Das geht ganz einfach mit dem „P“ rechts vom Type ID-Feld. Damit wird dem Fixture eine neu generierte ID zugewiesen, die mit dem nächsten Upload in der Datei Fuß fasst.
Umgekehrt ist es auch möglich, eine Variation mit einer anderen ID mit einem vorhanden Fixture zu verknüpfen. Im Eingabefeld „Linked GDTF“ (C – Abb. 3) gibt man dann die ID des Fixture ein, welches der Stammvater der Variantenfamilie ist.
Das Bild, welches man unter „PNG“ hochladen kann, dient in erster Linie als Übersichtsbild für das Fixture, denn nicht jeder hat sofort vor Augen, was für ein Typ von Scheinwerfer sich hinter Typenbezeichnungen wie W3 oder S3 verbirgt. Das Format .png ist auch deshalb gewählt worden, weil man hier im Gegensatz zum .jpg den Hintergrund transparent halten kann, was auch später im Patch schicker aussieht. Die Größe des Bildes soll 1024 × 1024 Pixel nicht überschreiten.
Das PNG-Bild aus dem GDTF-File dient auch als Thumbnail im Patch (Abb. 4) (Bild: Herbert Bernstädt)
Klickt man auf „SVG“, kann man eine vektorbasierende Grafik, die den Scheinwerfer in einem Beleuchtungsplan symbolisieren soll, hochladen. Zurzeit ist hier nur eine Datei in Aufsicht hochzuladen, denn die meisten Pläne werden eben der Einfachheit halber nur als Aufsichtspläne erstellt. Mit der nächsten GDTF-Builder-Version sollen auch Seiten-Schnitte und die Frontalansicht möglich sein.
Planung
Bild: Herbert Bernstädt
Eine.svg Datei zeigt hier die Seitenansicht einer Fixtures. Der rote Kasten rechts am Basement symbolisiert den Steckverbinder-Anschlussbereich. Damit wird auch auf dem Plan ersichtlich, wie herum das Fixture in die Traverse gehängt werden sollte. Der gestrichelte Kreis zeigt an, welchen Freiraum der Kopf in seiner Bewegung beansprucht (Abb. 5)
Bild: Herbert Bernstädt
Die Aufsicht ist die gängige Planungsgrundlage. Die Beschriftung erfolgt in der Legende bzw. werden die DMX-Adresse und ID am Gerät platziert. Diese Grafik wird dann via GDTF-Datei oder im MVR-Dateiformat in den Beleuchtungsplan importiert, wie man es in Abb. 7 sehen kann (Abb. 6)
Bild: Herbert Bernstädt
Im Beleuchtungsplan ist ein Fixturtyp (224) als Drahtmodell hinterlegt, während Fixture (127) vollflächig dargestellt ist, so wie der Dimmer FD1. Quelle: Best of Musical Gala 2012 gez. Frank Stähr (Abb. 7)
Weiter unten auf der Fixture-Seite findet man „Can have Children“ (D – Abb. 11). Diese Funktion wird z. B. bei einem Fresnel-Linsen-Scheinwerfer aktiviert, denn der Fresnel-Scheinwerfer wird ohne Torklappe angelegt. Die Torklappe wiederum wird auch als ein eigenes GDTF-File angelegt, ebenso die Omega-Adapter. So kann man sich im Beleuchtungsplan bzw. dem virtuellen Set mit dem Transfer-Format „My Virtual Rig“ (MVR) die Beleuchtungskörper zusammenstellen. So wird an die Fresnel-Scheinwerfer (Stufenlinsenscheinwerfer, kurz: „Stufe“) eine Torblende „befestigt“, was die Stufe mit aktivierter „Can have Children“-Funktion überhaupt erst erlaubt. Auf der anderen Seite können Omega-Adapter ein Movinglight als Kind andocken.
Mit diesem System ist es beispielsweise auch möglich, vor dem Profilscheinwerfer einen Wassereffekt-Rotator zu platzieren. Die Koppelung über Children ist deshalb interessant, weil beim Verändern der Ausrichtung der Stufe, die Torklappe dann nicht am ursprünglichen Ort im Plan verbleibt, sondern mit dem Scheinwerfer zusammen ausgerichtet wird und an der Stufe bleibt.
Mit „Leg Height“ (E – Abb. 11) sind die kleinen Gummifüßchen an den Movinglights gemeint. Jetzt fragt man sich, warum dieser Wert abgefragt wird: Die Füße haben in dem Moment Einfluss, wenn man ein Movinglight auf dem Boden platziert. Damit dann die Unterseite des Basements nicht bündig auf dem Boden aufliegt, muss die Höhe der Gummifüße einbezogen werden.
Unten auf der Eingabeseite „Fixture“ finden sich allgemeine Beschreibungen zum Scheinwerfer, aber auch wichtige Angaben wie das Gewicht, was wiederum für die Listengeneratoren interessant ist, denn damit kann man die Lasten auf den Traversen summieren (Abb. 11) (Bild: Herbert Bernstädt)
Um die Arbeit, die man bisher investiert hat abzuspeichern, findet man kein Diskettensymbol, um dann über den Explorer gefragt zu werden, wo man die Datei abspeichern kann. Nein – hier beim webbasierten Builder wird die Arbeit erst gespeichert, indem man auf „Upload“ klickt.
Mit dem Upload wird das File generiert, bzw. die Informationen gezippt und auf den GDTF-Server hochgeladen und auf den eigenen Rechner heruntergeladen. Daneben bietet die Schaltfläche „GDTF Share“ an, die hochgeladene Datei gleich auf der Share-Seite anzeigen zu lassen (Abb. 12) (Bild: Herbert Bernstädt)
Dann öffnet sich ein Fenster, in dem man „Mark As Work An Progress“ anklicken kann. Wenn man dann auf OK drückt, wird das File erstellt und auf den eigenen Rechner heruntergeladen.
Automatisch werden Hersteller- und Fixture-Namen, den wir auf der ersten Daten-Eingabeseite eingegeben haben, übernommen. Wichtig ist, hier vernünftige Versionshinweise einzutragen, da diese im Sharebereich zu dem File angezeigt werden (Abb. 13) (Bild: Herbert Bernstädt)
Nun kann man das GDTF-File zur nächsten Bearbeitung wieder im HOME-Fenster des Builders in das Hochladefeld legen, um es wieder zu bearbeiten. Verlässt man das Fenster oder geht man auf den Home-Screen – das symbolisierte Haus (Abb. 14) – dann sind alle Änderungen, die man bisher eingegeben hat, verworfen bzw. verloren. Zwar ist der Fixture-Builder sehr stabil, aber wenn man komplexe Lampen baut, und eine sehr langsame Internetanbindung hat, kann es doch zu einem Abbruch kommen.
„Home“ bedeutet, dass man zur Eingangsmaske springt, wo man eine Datei in den Builder laden kann. Jedoch gehen dann alle Änderungen, die man bisher im Builder getätigt hat, verloren. Um diese zu sichern, muss man einen Upload durchführen. Die beiden Pfeile symbolisieren eine Undo- und Redo-Funktion (Abb. 14) (Bild: Herbert Bernstädt)
Gelegentliches Anlegen von Zwischenständen ist also ratsam. Ist „Mark As Work In Progress“ nicht markiert, dann wird das File in den Sharebereich für jeden sichtbar abgelegt, so dass man mit der Schaltfläche daneben „GDTF Share“ gleich nachsehen kann, wie das erstellte File im Share aufgelistet wurde.
