„3D im Internet …ja und?“ So denken sicher die meisten, die obige Überschrift lesen, und man kann es ihnen kaum verdenken. Gilt doch 3D-Grafik im WWW nach wie vor als eine Domäne der Spielefirmen. Gut, es gab vor gefühlten hundert Jahren malen einen Hype um Second Life. Doch nachdem eine ganze Reihe kleiner und großer Firmen die traurige (und vorhersagbare) Erfahrung machen durfte, dass es den Durchschnitts-Avatar eher in virtuellen SM-Clubs als in den aufwendig modellierten konzerneigenen Glitzermessestand verschlug, ist auch hier inzwischen die Ernüchterung groß. Die Kids (und nicht nur die) verzocken ihr Geld lieber bei WOW und anderen MMOGs, geschlossenen Welten, die mit dem WWW nur das Protokoll gemein haben, keinesfalls die User Experience gemein haben. Dann gab es da noch Adobes Shockwave (ich weiß, hier in der Vergangenheitsform zu schreiben, ist nicht nett, denn Shockwave wird ja eigentlich noch gepflegt. Ausschlaggebend für mein subjektives Urteil sind aber Akzeptanz und Verbreitung), das es ermöglichte, 3D-Inhalte im Browser anzuzeigen. Aber unter uns: bis auf ein paar rotierende Handys in diversen Mobile-Shops ist nicht viel bei mir hängengeblieben. Und dann gibt es noch die wunderschönen Nachtschattengewächse diverser Cutting-Edge-3D-Engines, für die es ebenfalls Web-Schnittstellen gibt. Quest3D ist so eine, oder (vergleichsweise neu) Silvermotion, eine Engine für Microsoft Silverlight. Was haben all diese Versuche gemeinsam? Richtig: Entweder handelt es sich um eine Stand-alone-API oder der Content wird nur dann im Browser angezeigt, wenn man ein bestimmtes Plugin installiert hat. 3D-Plugins im Browser sind ein zweischneidiges Schwert: Auf der einen Seite hat man eine (idealerweise) hochwertige 3D-Engine und eigentlich sollte es der moderne User auch gewohnt sein, seinen Browser permanent zu pimpen. Andererseits gibt es allerhand Belege dafür, dass die Verweildauer auf Websites um zweistellige Prozentbeträge sinkt, wenn zur Installation eines Plugins aufgefordert wird.

Brauchen wir also einen neuen Standard, der 3D-Inhalte ohne Plugin im Browser anzeigt? Und wenn ja: was machen wir dann damit? Diese Fragen waren Thema eines illustren Kongresses des Frauenhofer Instituts für Datenverarbeitung IGD am 17. August 2011 in Darmstadt, an dem ich die Freude hatte teilzunehmen.

Vorgestellt: der X3Dom-Standard

Natürlich fand die Veranstaltung nicht im thematisch luftleeren Raum statt: Das Institut ist Mitglied des Web3D-Konsortiums und durch Forschungsarbeiten und Projektgruppen aktiv an der Schaffung des gesuchten Standards beteiligt. Schwerpunkt der Arbeit ist hierbei 3XDOM. Bei 3XDOM handelt es sich um ein Open-Source-Framework, das die Anforderung von HTML5 nach deklarativem 3D-Content erfüllen soll. Es basiert auf WebGL, einem neuen Standard für 3D-Browser-Inhalte und wird momentan von Mozilla, Chrome und Opera unterstützt. Deklarativer Content bedeutet hier, dass alle 3D-Meshes, alle Shader, Animationen, Beleuchtungen und Kameras direkt im Code der Website stehen; es gibt keine zu installierende API, die die 3D-Ressourcen aus irgend einem Fremdformat einließt. Lediglich eine kleine Javascript-Engine, die auf allen Browsern läuft, die Sachen aufbereitet und verarbeitet , wird durch eine einzelne Codezeile aufgerufen. X3DOM-Inhalte sind also HTML- oder XHTML-Seiten und sonst nichts weiter. Erstaunlich und an sich erst einmal begrüßenswert!

Im Vorfeld des Kongresses habe ich mir eine ganze Menge X3DOM-Denos angeschaut und war zugegebenermaßen nicht allzu erbaut, denn die Darstellungsqualität der Engine lässt hier und da noch zu wünschen übrig:
• Ein Teil der Demos läuft auf bestimmten Browsern nicht stabil oder gar nicht.
• Die Engine erzeugt Hänger und Nachzieher bei schnellen Rotationen. Einem der beteiligten Entwickler zufolge liegt das am Buffering der Meshes bei großen Szenen. Allerdings fällt mir der Effekt auch in kleinen Szenen auf…
• Das Problem des Z-Fightings bei großen Modellen und „weiter Sicht“ tritt auch bei X3Dom auf. Ebenso Moiré –Effekte.
• Bisher gibt es kein Anti-Aliasing.
• Mehrfach-Texturierungen, Alpha-Maps und maskierte Maps habe ich bisher nicht gesehen.
• Um -für Games relevante- Sachen wie Rigged Characters, Innverse Cinematics oder gar Physics hat sich bisher niemand Gedanken gemacht.
• Und überhaupt: In Sachen Animation gibt es lediglich rudimentäre Features: Objekte können bewegt und rotiert werden, das höchste der Gefühle sind „gebackene“ Vertex-Animationen.
• Die Engine Fast alle der Tech-Demos zeigen jeweils nur ein einziges Feature. Ein tragfähiges Projekt, das beweist, dass die Engine große Modelle mit dynamischen Schatten, statischen Lightmaps, dynamischen Lichtern, Animationen, Shadern usw. stemmen kann, ist nicht in Sicht. Für anspruchsvolle Projekte ist das aber unabdingbar.

Die im Foyer gezeigten Demos waren allesamt nett bis innovativ, rissen mich aber auch nicht völlig vom Hocker: Ein Automodell wurde auf einem PC gerendert und über ein Ipad „per remote“ gedreht und gezoomt. Über ein Kinekt wurden Tiefeninformationen gesnappt und in ein 3DModell konvertiert, das den erfassten Menschen als „Han-Solo-Carbonate“- Opfer (Siehe Video unten) zeigte. Ein sehr großes Modell der Frankfurter Messe zeigte die Renderperformance bei großen Modellen, usw. ? Trotzdem gelang es den Ausrichtern des Kongresses ebenso wie den anderen Beteiligten, mich für das Thema zu interessieren und auch zu sensibilisieren. Denn einen Standard zu entwickeln bedeutet viel mehr als nur Renderperformance zu erzeugen. Einige spannende Einsichten boten hierbei die Referenten mit ihren Vorträgen.

X3DOM als Container für Dokumente

Beginnen wir mit Dr. Johannes Behr vom IGD. Er befasst sich in seiner Arbeit vor allem mit der Frage, wie sich 3D in Dokumente integrieren lässt. Grundlage seiner Forschung ist die Annahme, dass die Dokumentation dreidimensionaler Inhalte in Zukunft immer mehr Bedeutung einfordern wird. Was mich zuerst etwas skeptisch werden ließ, bin ich es doch als 3D-Grafiker bisher gewohnt, das mir selbst meine eigenen Arbeiten -weil technisch veraltet und für potenzielle Kunden uninteressant- nach einigen Jahren herzlich egal sind und nur noch nostalgischen Wert besitzen. Doch das muss nicht überall so sein: Doktorarbeiten von Architekten und Ingenieuren bestehen heute schon zum Großteil aus 3D-Content, in Zukunft wird sich dieser Trend weiter verstärken. Diese Arbeiten wollen auf Jahrzehnte archiviert sein. Sie müssen gehostet und indiziert werden, auffind- und durchsuchbar sein und vor allem müssen sie laufen. Auch in 30 Jahren noch. Für mich, der von seine ersten 3D-Arbeiten aus den späten 90ern nur noch kleinformatige Renderings besitzt, ein ernüchternder Gedanke. Ein weiterer interessanter Punkt ist die Pflege von geschichtlichem Kulturerbe in digitaler Form. Wo heute noch Kataloge, Atlanten und Papierberge dominieren, kratz bereits die Digitalisierung an der Tür. Schon jetzt gehört es für Archäologen zum guten Ton, mit aufwändigen digitalen Rekonstruktionen der Fundstätten zu glänzen. Historisch und kulturell relevante Gebäude wie Kirchen, Schlösser und Steinzeithöhlen werden dreidimensional erfasst und „digital konserviert“. Hier besteht nicht nur großer Bedarf nach Internet-Kompatibilität, sondern auch nach einem Dokumentenformat, dass mehr ist als nur eine 3D-Szene. Indizierung und Kontextierung sind hier die Stichworte: Wissenschaftliche Arbeit verlangt nach Erläuterungen, Verweisen und Fußnoten im 3D-Dokument. Ein weiterer Punkt auf Behrs Agenda war die Erfassung von wirklich großen Datenmengen bei umfassend angelegten Vermessungsprojekten, Stichwort Street View & Co. ? ?Angesichts der Tatsache, dass man unmöglich alle Straßen dieser Welt mit einem Laser abtasten und als Mesh vorhalten kann, behalf man sich bisher teilweise mit dem Nachmodellieren von Sehenswürdigkeiten per Hand… was aber auch keine Lösung ist.
Wie also scannt man ganze Straßenzüge und kommt zu einer dreidimensionalen Virtualisierung, die ohne Superrechner auskommt. Die Antwort ist simpel: Indem man hunderte, tausende Fotos algorithmisch analysieren und einen Rechner oder „die Cloud“ low-poly-Meshs generieren lässt. Schon heute gibt es billige Software für jedermann, die aus einer Anzahl von Fotos 3D-Inhalte generiert. Was passiert, wenn man diese Technik verbessert und sie dann auf Flickr oder Streetview loslässt? Das Fernziel ist nichts Geringeres als ein dreidimensionales, sich permanent selbst aktualisierendes Abbild der Welt in der wir leben.

Wohin mit den vielen Vertexten?

Mike West von Google Germany war dann nach diesem spannenden, aber wuchtigen Einstieg eher die kühle Brise des Tages. Er kam im Grunde, um Chrome zu bewerben und tat dies routiniert im gekonnten, lässigen Ami-Style mit dem Credo: Chrome loves WebGL. Neben den Facts, die ich bereits im Einstieg dieses Artikels erläutert habe, referierte er über ein anderes spannendes Thema, beginnend mit der Problemstellung: Wenn ich eine komplexe 3D-Szene mit allem, was dazu gehört, darstelle… und diese komplette Szene deklarativ im HTML-Dokument steht – wie lang wird dann mein HTML-Dokument? Die Antwort lautet schlicht: viel zu lang. Länger jedenfalls, als es Programmierern und Browsern recht sein kann. Natürlich könnte man jetzt Inhalte in weitere HTML-Dokumente auslagern, doch auch das wird irgendwann sehr unübersichtlich und wahrscheinlich auch langsam. Die Lösung verblüfft: 3D-Informationen werden als Image codiert! Sie kennt die monochromen pixeligen Briefmarken und Scann-Bildchen, die inzwischen Strichcodes ablösen? Damit lässt sich alles codieren, auch eine komplexe 3D-Szene. Der Vorteil dabei ist, dass Browser Bilder lieben. Sie sind über ein Jahrzehnt darauf optimiert worden, Bitmaps zu verarbeiten und tun dies in bestmöglicher Geschwindigkeit. Der Clou dabei: Die Grafikkarte wird GPU-und Ram-mäßig in die Verarbeitung der 3D-Ressourcen mit einbezogen. Diese wiederum liegen ordentlich verstaut auf dem Webserver bei dem –nun deutlich kompakteren- HTML-Dokument, dass nur anstatt gewaltiger 3D-Deklarationen nur noch Verweise zu Bildern enthält. Ein weiterer unterhaltsamer Umstand ist, dass man seinen 3D-Mesh nun entweder verlustfrei als PNG speichen, oder aber durch Verwendung von JPGs komprimieren kann. Ein als PJG codierter Mesh zeigt dann, abhängig von der Kompressionsrate, ebenfalls Artefakte und wird mit zunehmender Kompression immer leichter, aber auch hässlicher. Für ein echtes LOD (Level of detail) allerdings noch mehr als unbrauchbar, wie ein Blick auf die Demos offenbarte…

Das folgende Demo funktioniert nur bei Browsern, die XHTML und WebGL unterstützen!
Gezeigt wird ein großer 3D-Mesh, teilweise in Bitmaps verschlüsselt. Zum Navigieren einfach mit gedrückter Maustaste bewegen.

Vernetze 3D-Welt

Dr. Knut Manske von SAP wiederum brachte dann die freie Industrie ins Spiel. Als VisioniererVisionärer von SAP Research schien er sich eine Menge Gedanken über den Einsatz von 3D jenseits des reinen End-Consumer-Marktes gemacht zu haben. Seine Ausführungen zur Augmented Reality in Verkauf und Forschung waren nett, aber sehr allgemein. Spannend wurde es, als er ein System vorstellte, das bei SAP gegen Anfrage bereits als Produkt vermarktet wird: Auf einer Weltkarte –offensichtlich basierend auf Google Earth- sieht man die Vertriebswege eines Logistik-Konzerns, farbig codiert je nach Transportweg (Flugzeug, Straße, Schiene oder Containerschiff). Die Knotenpunkte sind Umschlagplätze, Lagerhallen, Verkaufshäuser, Verwaltungszentralen ect, wiederum farbig codiert nach ihrer kaufmännischen oder prozesshaften Effektivität. Einer der Punkte blinkt im alarmierendem Rot, da stimmt also etwas nicht. Als Manske heranzoomt, sieht man eine dreidimensionale Fabrikationsanlage und der rote Punkt wird zu einem roten Gebäude zwischen lauter gründen Anlagen. Callouts geben Hinweise auf eine Störung des Lieferbetriebes und ein weiteres Zoomen auf das fragliche Haus (wobei sich der LOD ständig erhöht und immer mehr Details sichtbar werden) öffnet schlussendlich die Großansicht einer Brauerei-Halle. Einer der großen Brau-Bottiche blinkt aufsässig und über diverse Interaktion lässt sich feststellen, was an der Maschine kaputt ist, welches Ersatzteil benötigt wird und wo der Servicebetrieb sitzt. Die komplette Produktions-und Vertriebslogistik ist hierbei in 3D abgebildet, mit dem Web verbunden und lässt sich global überwachen und im Detail optimieren. Das ist keine Zukunftsmusik sondern wird bereits vermarktet.
Die dreidimensionale Cutting Edge
Jan-Hendrick Theilen von der Volkswagen-AG ließ sich ebenfalls nicht lumpen? und wurde schnell konkret: Aus der Produktionspipeline eines Autoherstellers ist 3D-Grafik natürlich nicht mehr wegzudenken. Plastemodelle und Wände voller Risszeichnungen waren gestern. Selbst das kleinste Schräubchen wird heutzutage dreidimensional vorgedacht. Jedes einzelne Teil eines Wagens wird in einem integrierten 3D-Model nicht nur einfach gerendert, sondern besitzt spezifische Materialeigenschaften und kann in diversen Simulationen Verformungen, Temperaturschwankungen und allerlei anderen virtuellen Belastungen ausgesetzt werden. Virtuelle Crash-Tests müssen sich natürlich immer noch durch reale Tests gegenprüfen lassen, doch das Vertrauen in die Virtualität wächst kontinuierlich. Doch nicht nur die 3D-Virtualiserirung war hier Thema, sondern auch das integrierte Arbeiten. Noch arbeiten viele der Abteilungen von VW an getrennten 3D-Modellen und mit sehr unterschiedlichen Techniken. Ziel ist integriertes Arbeiten an einem einzigen virtuellen Modell, vom Design über die Produktion bis zum Marketing. Neue Arbeitsformen wie Cloud Services und die, so Manske, „Ipadisierung“ der Interaktion werden bei dieser Rundum-Integration helfen.

Fazit und offene Fragen

Diese Applikation des Frauenhofer Instituts zeigt mechanische Belastung an einem Flugzeug. Die grafischen Informationen lassen sich nach kriterien Filtern, die textur wird in Echtzeit gändert.

Grafik vs. Code?

Beim Kick-Off wirkt alles so einfach: Fähige Entwickler schreiben ein funktionierendes Programm und kreative Designer entwerfen die Oberfläche dazu. Wenn sie als Kunde, Geschäftsführer oder Entwickler bereits mit Software-Entwicklung zu tun hatten, wissen sie jedoch, dass dies zwar leicht daher gesagt, aber oftmals weitaus schwerer zu realisieren ist. In den meisten Fällen wird ein Entwickler-Team das Programm schreiben, während eine externe Grafik-Abteilung (in vielen Fällen sogar eine externe Agentur) das Design für die Oberfläche beisteuert.

Murphys Law

Diese Zusammenarbeit funktioniert erfahrungsgemäß selten reibungslos, denn Software-Entwickler und Grafikdesigner scheinen auf verschiedenen Planeten zu wohnen und sich nur ungern auf die jeweils „andere Seite“ einzulassen. Für den Grafiker ist die CI des Kunden das Maß aller Dinge. Er sieht das große Ganze und begreift sich als kreativer Visionär, dem es darum geht, dem Projekt eine unverwechselbare Marke aufzudrücken. Technische Hürden und Notwendigkeiten interessieren ihn nur am Rande. Der Entwickler wiederum ist vor allem daran interessiert, das Lastenheft umzusetzen und eine funktionierende Software abzuliefern. Die Optik und Haptik der Oberfläche ist für ihn schmückendes Beiwerk und rangiert als Zeitfresser in seiner Prioritätenliste ziemlich weit unten. Diese sehr unterschiedlichen Mentalitäten zu vereinen hat schon so manchen Projektleiter überfordert.

Zwei Welten- Die Wurzeln des Übels

Meistens arbeiten GUI-Designer mit Photoshop und liefern genau vorbereitete und abgemessene Grafikschnipsel, welche von den Entwicklern als Ressourcen in ihre Software integriert und eingepasst werden müssen. Gefällt dem Kunden etwas nicht, müssen neue Anforderungen definiert und Anfragen gestellt werden. Die ganze Ereigniskette von der Lieferung der Designs an die Entwickler bis zum Testen und Reviewen beginnt von vorne. Dieser Weg ist umständlich und zeitraubend. Nicht nur, weil anspruchsvolle Grafik „Entwicklergerecht“ zurechtgestückelt werden muss, sondern auch weil Team A von den Notwendigkeiten des Teams B nur rudimentär etwas versteht. Die Designer in ihrem Elfenbeinturm ahnen nichts von den technischen Fallstricken der Softwareproduktion, während die Entwickler kein Verständnis für die entscheidende Wirkung einer schönen und nutzerfreundlichen Oberfläche aufbringen. So bleiben nicht nur Innovation und Flexibilität auf der Strecke, auch Deadlines können wanken.

Wege aus dem Dilemma

Solche Situationen gehören in einer Software-Agentur der Vergangenheit an. Denn durch die Erfordernisse der neuen Technologien und eines beschleunigten Software-Marktes befeuert, setzen sich mehr und mehr andere Modelle der Zusammenarbeit durch. Der Trend geht zu integrierten Teams aus Designern und Entwicklern, die als eine Art Task-Force für einen begrenzten Zeitraum direkt und intensiv an einem Projekt zusammenarbeiten.

Komplexe Oberflächen wie die von "Silverdave" lassen sich nicht realisieren, wenn Grafiker und Coder einander auf Kriegsfuß stehen.

Als Beispiel für eine solche Zusammenarbeit dient hier die Client-Entwicklung bei ATE. Hier arbeiten Grafiker und Programmierer nicht nur konzeptionell und räumlich eng zusammen, sondern auf einer weit tieferen Ebene, nämlich der des Programm-Codes. Vehikel dazu sind moderne Microsoft-Technologien wie WPF und Silverlight. Diese fungieren nicht nur als Frameworks für sauberen und web-tauglichen Code, sondern durch XAML auch als Beschreibungssprache für Grafik! XAML dient nicht einfach nur zum Stylen und Layouten ähnlich HTML oder PHP, sondern ist in der Lage, komplexe Vektorgeometrie nebst Echtzeit-Effekten bis hin zu 3D über eine DirectX-Schnittstelle zu definieren. Auf der Ergebnisseite führt das im Idealfall zu einer modernen, vektorbasierten und voll skalierbaren Grafik, fit nicht nur für den Desktop, sondern auch für den Browser und alle modernen Touch-Interfaces. Auf der handwerklichen Seite bedeutet dies, dass der Grafiker etwas tut, was sonst nur Entwickler können: XAML-Code schreiben.

Neue Technologien = neue Formen der Zusammenarbeit

Mittels entsprechender Software wie die Expression-Suite arbeiten sowohl Entwickler als auch Designer z.B. über einen Team Foundation Server direkt am XAML-Code, nur eben in ihren jeweiligen Aufgaben-Bereichen. So kann der Designer die grafischen Teile einer Bedienmaske mit Expression-Blend in XAML layouten und Bedienelemente wie Menüs und Buttons entwerfen und animieren, während der Entwickler fast gleichzeitig diese Maske mit Funktionen verknüpft und an die Backend-Technologie anbindet. Diese direkte Zusammenarbeit bietet eine Menge neuer Chancen: Zum Einen schweißt sie das Team zusammen und verknüpft die Arbeit von Design und Entwicklung auf eine Weise, wie sie dem User auch später durch das fertige Produkt entgegen tritt. Zum Anderen können Änderungen sowohl in Code als auch in Grafik sofort auf ihre Wechselwirkung getestet werden, regelmäßige Usability-Tests sind kein Problem mehr. Umständliche Grafik-Vorproduktionen und Lieferungen entfallen. Die Designer können ihre Arbeit sofort im laufenden Programm überprüfen und sind wesentlich flexibler in ihrer Arbeit. Die Grafik verändert und erfindet sich selbst direkt im Entstehungsprozess der Software, teilweise im Minutentakt. Natürlich sind mit dieser Arbeitsweise auch Umstellungen verbunden: Dem Designer fällt in einer solchen Konstellation deutlich mehr Verantwortung zu, denn er hat nun direkten Zugriff auf den Code. Grundkenntnisse in Sachen Projektmanagement und Codeverwaltung sind nicht von Nachteil, und durch regelmäßiges Briefing muss gewährleistet sein, dass Kompetenzen klar verteilt werden. Der Designer kann sich nicht mehr als abgehobener Vorgeber oder Zulieferer eines fertigen Designs betrachten, sondern ist nun unmittelbarer Einflussträger und Gestalter im laufenden Prozess. Das spart Nerven, Zeit und schlussendlich Geld, wovon der Kunde profitiert. Dass am Ende auch noch State-of-the-art-Technik verwendet wurde, wird sicher niemanden stören…

Warum gibt es so wenig echte 3D-Interfaces in “normaler” Software?

Das liegt zum Ersten daran, dass 3D-Grafik nach wie vor auf der Hardwareseite ressourcen-fressender als eine 2D-GUI ist.

Zum Zweiten sind die Ausgabegeräte, also die Bildschirme, trotz des aktuellen 3D-View-Hypes immer noch üblicherweise 2D-Maschinen und stellen die “echte” 3D-Grafik des Rechners nur als Pseudo-3D in einem 2D-Bild dar. Dies ist ein wichtiger Punkt, wenn es um GUIs geht! Denn wenn man argumentiert, daß 3D- von der stilistischen Anmutung her den Sehgewohnheiten und Interaktionserwartungen des Menschen eher entspricht als ein 2D-Panel, dann bedeutet dies, daß auf der Ausgabeseite noch ein großer Nachholbedarf besteht.

Und zum Dritten ist die Gestaltung von 3D-Grafik und die Entwicklung echter 3D-Aplikationen nach wie vor technisch hoch anspruchsvoll und nur etwas für echte Könner auf ihrem jeweiligen Gebiet.

Auf der Gestalterseite hat sich da in den letzten 10 Jahren viel getan: Die großen Softwarepakete für Vektorenschubser (z.B.: Maya, 3DS-Max, Lightwave 3D, Cinema 4D oder für die Open-Source-Community: Blender) zelebrieren untereinander einen gnadenlosen Wettlauf um die Gunst der Käufer und gleichen sich dabei durch Feature-Klau immer mehr einander an. Auf der Entwickler-Ebene werden eine Menge guter Realtime-Engines vertrieben, manche als Zusatzgeschäft namhafter Game-Produzenten. Programmpakete wie Quest3D emöglichen den Import von allerlei 3D-Formaten und helfen dem Spezialisten, beeindruckende Software zu bauen. Das Wissen und die Tools sind also generell da und harren der Anwendung. Sofern man Games, Messestände, Architekturkram und andere Leuchtturm-Projekte hat.

Was (manche) Grafiker (auch noch) wollen:

Nur für den GUI-Fan, der mit “ganz normalen” .Net-Programmierern und Web-Entwicklern an handelsüblicher Software baut, ist 3D-Grafik nach wie vor etwas, dass man nicht eben mal so aus dem Hut zaubert. Wie schön, dass Microsoft langsam ein Einsehen hat und Silverlight in der 5. Version anscheinend ernsthaft 3D-fähig macht. Wir wollen keine spitzen Bemerkungen darüber verlieren, wie lange der Erfinder-Konzern von DirectX dafür benötigt hat, sein betagtes 3D-Wissen endlich in seine gepushte Web-Plattform einfließen zu lassen… nein, wir wollen dankbar sein, dass er es nun tut und uns das folgende Video anschauen:

Das sieht doch schonmal ganz brauchbar aus. Gut, wenn die virtuelle Cam nah heran zoomt, sieht man einige Mapping-Fehler… doch wenn der Artist wirklich nur eine Woche Zeit hatte, wollen wir nicht kleinlich sein. Und was auf Anhieb sehr gefällt: Die Verschmelzung des 2D-Panels mit der 3D-Grafik wirkt rund und gelungen. Da ich bereits viel mit Expression Blend gemacht habe und die 3D-WPF-Tools kenne, könnte ich mir vorstellen, dass man hier schnell zu brauchbaren Ergebnissen kommt. Das Demo ist auf jeden Fall ein Schritt in die richtige Richtung.

Trotzdem: Dieses Video stellt den 3D-Grafiker in mir vor einige Fragen:

Wie viele Lichtquellen stellt die Engine dar?

Im Demo sehe ich nur eine. In wieweit wird die Grafikkarte diesbezüglich ausgereizt …und überhaupt:

Wie viel vom Featureset der Grafikkarten wird unterstützt?

Ich gehe davon auf, daß Silverlight 5 in Sachen 3D, genau wie DirectX, auf den Rendering-Möglichkeiten der Grafik-Hardware aufsetzt. Aber in welchem Maße? Wie *genau* steht es mit Lighting, Mapping, Hardware-Shadern, Fur-Sumulation usw? Oder wie sieht das Speicher-Handling von Texturen aus?

Wie steht’s mit Schatten?

Shadow-Maps sind schon mal Fehlanzeige, aber ich sehe auch keine Realtime-Selfshadows. Schade!

Wie unabhängig sind Viewports, Lichtquellen und Objekte zueinander und vom Koordinatensystem?

Sofort störend fällt auf, daß sich die Lichtquelle immer synchron zur Kamara mitbewegt und dann getrennt “nachschwenkt”. Es fällt mir schwer, dies als vom Artist gewollt zu betrachten. Es suggeriert sogar die Vermutungen, daß Lichtquelle und Vieport aus technischen Gründen verzahnt sind nach der Viewport-Rotation die Position der Lichtquelle korrigiert wird. Ein Problem der räumlichen Bezugssysteme? Das wäre nicht schön.

Kann Silverlight 5 Damping und Easing für 3D-Storyboards?

Die Kamerabewegungen des Demos wirken teils etwas steif und hölzern. Da sie direkt mit der Vieport-Navigation entstehen, sind sie sicherlich generisch und nicht als fester Path importiert. Gute Realtime-Plattformen wie Quest3D haben für solche Fälle zahlreiche Funktionen, die 3D-Animationen glätten und mit allerlei generischen Effekten (z.B. Nachfedern) veredeln können. Für ein gutes 3D-GUI braucht man butterweiche und natürliche Animationen, keine harten Roboter-Flüge. Bitter wäre es, wenn die Entwickler des Demos die Regeln für die Kameraschwenks “hart coden” mussten und ihr eigenes Überblendungssystem geschrieben haben. Dann dürften selbst auch solche einfachen Anwendungen wie die gezeigte für viele Hersteller ein Problem werden.

Kann Silverlight 5 LOD?

Jede bessere 3D-Engine versteht es heutzutage, Objekte abhängig vom Abstand zur Camera in unterschiedlichen Detailstufen zu zeichnen. Bei generisch erzeugten Objekten wird hierfür oft das Wire Mesh in Echtzeit modifiziert, bei Handmade-Objekten (der Normalfall) gibt es einen Set mit verschieden stark detaillierten Varianten des gleichen Gegenstands, die beim Heranzoomen ineinander überblendet werden. Wichtig ist dieses Feature bei großen Szenerien mit viel Geometrie und vielen einzelnen Charakter-Figuren, z.B. bei Architekturpräsentationen.

Materialeigenschaften und Texture-Blendung-Modes?

Das Demo zeigt, wie einzelne Objekte ausgeblendet werden, was aber wahrscheinlich unabhängig vom Shading “von oben” über die Renderpipeline funktioniert. DirectX unterstützt jedoch eine Vielzahl von Verrechnungsmodi, mit denen sich etliche Varianten der Transparenz darstellen lassen. Wird es diese ähnlich auch bei Silverlight geben? Auch spannend: Wie funktioniert Transparenz über Maskierung? Und wie steht es mit Materialeigenschaften, die unabhängig sind von der Textur, z.B. Luminocity?

Unerstützt Silverlight 5 Character-Rigging?

Zugegeben, das ist eine harte Frage, denn selbst hochpreisige Plattformen haben Probleme damit, die Unmenge an komplexen und filligran verwobenen Daten eines 3D-Pakets wie 3DS Max so zu importieren und so zu berechnen, daß man am Ende einen hüpfenden Velociraptor und keinen implodierten, zuckenden Vektorhaufen begutachten darf. Trotzdem: das pumpende Herz ist eine reine Vertex-Morph-Animation, abgespielt als Ping-Pong-Loop. Das lockt keinen 3D-Animator hinterm Ofen hervor. Ein 3D-Animator will in der Software seiner Wahl seine Schöpfungen mit Riggings versehen, mit deren Hilfe sodann Motion Sets erstellen und das Ganze schlussendlich ohne Stress in der Realtime-Engine importieren. Und zwar ohne die Animationen vorher “baken”, also zu einer unflexiblen Vertex-Animation herunterbrechen zu müssen. Dafür wäre freilich notwendig, daß Microsofts Silverlight 5 die Rigging-Daten bekannter Object-Formate, z.B. ‘.x’  interpretieren kann…

Mein Faszit:

Alles in Allem sieht das Demo vielversprechend aus, haut mich aber auch nicht vom sprichwörtlichen Hocker. Silverlight 5 kann texturierte 3D-Objekte laden, rudimentär beleuchten, Vertex-Morphing betreiben und dabei Viewports und Lichtquellen bewegen. Das ist aber nur das ganz kleine Einmaleins des Realtime-3D und gilt heutzutage längst nicht mehr als Hexenwerk. Für echte 3D-Anwendungen braucht es noch einiges mehr. Ich hoffe, da kommt noch was und bin gespannt!

Was liegt da näher als ein Musikvideo? Und, Ta-Daaaa, hier ist es!

„Ein Ding im Spiegel“ ist ein Song vom – im Dezember 2010 erscheinenden- neuen Album der Avantgarde-Metalband ADVERSUS und war von Anfang an als eine Mischung aus 3D-Geschiche und Realfilm gedacht. Die Idee, dieses kurzweilige Stück Düstermusik zu vertonen hatte ich schon länger, doch ging der Umsetzung eine ausführliche und tiefgehende Planungsphase voraus, denn ich fungierte nicht nur als 3D-Operator, sondern auch als Regisseur und Postproducer.
In der frühen Planungsphase wurde erst einmal der Look des Videos festgelegt. Da es sich bei ADVERSUS um eine Band aus dem Metal/Gothicsektor handelt und es in diesem Lied um einen geheimnisvollen Spiegel geht, war von Anfang an klar, daß eine düstere, aber auch romantisch-geheimnisvolle Bildsprache angebracht wäre. Die Ästhetik solle altertümlich, klaustrophobisch und ein „verstaubt“ wirken, wie auf einem schlecht aufgeräumten Speicher.  Für die 3D-Animationen entschloss ich mich für einen „Weird Fantasy“-Look im Stil von #9 oder den Tim-Burton-Filmen, wobei ich bei den Charakteren nicht zu „real“ werden wollte. Sie waren als Puppen gedacht und sollten etwas Marionettenhaftes haben. Auch die (ungeschlagenen!) Videos der amerikanischen Band Tool waren eine Inspirationsquelle.

Die Produktion des 3D-Anteils nahm ungefähr 6 Monate in Anspruch, da es sich hier um ein „immer-wieder-mal“ Projekt handelt, waren die Arbeitsblocks gestückelt und ist eine exakte Angabe des Zeitaufwands leider unmöglich. Alle Backgrounds, Charakters, Rigs und Animationen wurden in Lightwave erstellt. Modelling, Animation und Rendering lief über eine Software. Neben den üblichen FW- und IK-Animationen kamen auch diverse Dynamics und Partikeleffekte zum Einsatz. Gerendert wurde auf einem handelsüblichen PC in 1024×756.

Die Realfilmaufnahmen wurden an einem einzigen Tag im Zeughaus Willy John, einer obskuren Mischung aus Kunstausstellung und Trödelmarkt in Leipzig gedreht. Während der 3D-Job für mich eher Routine war, stellte mich dieser einzige Drehtag vor neue Herausforderungen, denn immerhin waren wir ein Team von 14 Leuten und es gab eine Menge zu tun. Ohne langfristige und akkurate Drehplanung nebst ausführlichem Drehplan ist auch eine Vergleichsweise kleine Low-Budget-Produktion wie diese undurchführbar. Finanzierung, Aufstellung des Teams, Aufgabenverteilung, Equipment-Beschaffung, Tramsportlogistik, Übernachtungen, Catering Dreh- und Lichtplan, Maske, sowie ein streng eingehaltenes Arbeits-timing fallen leider  nicht vom Himmel und ich habe eine ganze Menge gelernt. Es hat aber alles reibungslos geklappt und neben den Renderings hatte ich dann auch genug gutes Realfilm-Material zur Verfügung. Gedreht wurde mit zwei Sony DSRs auf DV-Video in 16/9. Für viele Aufnahmen kam außerdem ein Steadycam-Gestell von Merlin zum Einsatz.

Bearbeitet und geschnitten wurde „Ein Ding im Spiegel“ auf den Adobe-Geschwistern After Effects und Premiere, was ungefähr 3 Wochen meiner Freizeit in Anspruch nahm. Der angestrebte Vintage-Look machte viele Tests nötig, bis aus zahllosen Schmutztexturen und den entsprechenden Premiere-Tools ein Affekt generiert war, den man problemlos einsetzen konnte ohne die Render-Performance zu sehr in den Keller zu ziehen. Das Video enthält einen großen Anteil an Fonts, Zierrahmen und Maskeneffekten, unter anderem auch dort wo sich die Real- und die verwunschene 3D-Welt überschneiden. Ein Musikvideo stellt an den Schnitt andere Anforderungen als ein „normaler“ erzählender Film, denn hier gilt es, nicht nur eine Geschichte zu erzählen, sondern auch im passenden Rhythmus zu schneiden. Zwei verschiedene Dramaturgien sind miteinander in Einklang zu bringen. Dank der Musik von ADVERSUS, die bereits in sich schon sehr narrativ und episch angelegt ist, war dies eine dankbare Aufgabe, deren Umsetzung besonderen Spaß gemacht hat. „Ein Ding im Spiegel“ hebt sich sowohl musikalisch als auch dramaturgisch vom Flachsinn der meisten modernen Musikvideos ab. Insgesamt finde ich die Arbeit für mein erstes Musikvideo ganz gelungen, was mir auch durch das starke Feedback bestätigt wird. Eventuell lasse ich ein etwas ausführlicheres Making-Of nachfolgen.

© David Thorne

Ein böses Branchen-Sprichwort lautet: “Der schlimmste Feind des Grafikers ist der Kunde”. Das stimmt natürlich nicht, wir Grafiker lieben unsere Kunden. Doch, ehrlich! Was uns oftmals weitaus schwerer aufs Gemüt drückt, sind Leute aus dem näheren Bekanntenkreis, die irgend ein grafisches Erzeugnis für ihre kleinkarierten privaten Zwecke benötigen. Und nun ganz plötzlich ihre unverbrüchliche Freundschaft zu uns entdecken. Egal ob Geburtstagsflyer, Wandverzierung oder Arschgeweih, nirgendwo ist mal als Gestalterich noch sicher vor derartigen Avancen; und ruck-zuck ist man verknechtet und zählt innerlich die Stundensätze, die man natürlich nicht einfordern kann. Oft reicht freilich der gutmütige Verweis auf irgendein Dau-Tool um das Übel abzuwenden, manchmal droht  jedoch der Super(g/d)au, und da muss man dann durch.

Der australische Gestalter und Blogger David Thorne hatte es mit einer Kollegin -genauer: der Sekräterin- zu tun, welche ein simples Suchplakat mit ihrer verschwundenen Katze “Missy” haben wollte. Anscheinend sogar von MS-Word überfordert wandte sie sich an den Profi, der sich über die Belästigung auf seine ganz eigene Weise bedankte…

Studenten der staatlichen Hochschule für Bildende Künste – Städelschule, der Hochschule für Musik und Darstellende Kunst in Frankfurt, der Hochschule für Gestaltung in Offenbach sowie dem Institut für Angewandte Theaterwissenschaft in Gießen zeigten ihre Arbeiten, meistens Installationen und Performances. Am 17. September hatten wir Zeit, einen Abend dort zu verbringen, doch der Einstieg in die junge Kunstwelt gestaltete sich etwas schwierig: Obwohl es bereits 21 Uhr am Abend (Sonntags!) war und der EVO-Parkplatz wie ausgestorben dalag, wies uns die Security nuschelnderweise am Eingangstor ab und wir mussten uns 15 Minuten lang einen Parkplatz suchen und weit laufen. Shame on you, EVO! Schlussendlich haben wir es dann doch geschafft und wurden durch interessante Installationen belohnt.Die Ausstellung war sehr weiträumig auf dem -schönen Industrial- und Hitek-Charme verbreitenden- Gelände verteilt und musste erlaufen werden. Dabei verlief sich das Publikum gleich im doppelten Sinne: Man traf eher selten jemand Anderes und man fand nicht immer gleich, was man suchte.

Hängengeblieben sind vor allem zwei Werke: Zum einen die “Neurosen des White Cubes. Teil Eins: Neonregister”, eine trotz des etwas überspannten Titels schöne Kombination aus Musik und Lichterspiel von Lea Letzel und Fabian Offert. Die Tasten eines E-Pianos waren über eine (anscheinend selbst egschriebene) Mac-Software mit Neonröhren gekoppelt, die auf mehreren Industrie-Türmen installiert waren. Spielte die Pianistin, flackerte es allerorten recht beeindruckend. Leider wurde der Eindruck durch einen offensichtlichen Konzeptionsfehler getrübt: Neonröhren starten nur langsam und flackernd, Das Lichterspiel wwar also nie synchron zur Musik, wirke manchmal willkürlich und ließ sich oft auch gar nicht der Akkustik zuordnen. Gelungener war die Performance “Evergreen“, die in einem der bestuhlten Hallen stattfand. Auf einer Art Bühne, die eher etwas von einer mit grünem Teppich ausgelegten Krabbelstube hatte, bastelten die Künstler “In Echtzeit” mit Hilfe von Modelleisenbahn-Zubehör und einer kurvigen Dame Landschaften, irgendwo zwischen Heimatfilm und Tatort. Vor einem Greenscreen wurde dann ein Protagonist fotografiert und in die Szenerie hineinkopiert, was man auf den überall platzierten Monitoren gut verfolgen konnte. Auf diese Art entstand eine Art spontander Comic, der umso kruder wurde, je länger die Performance dauerte. Nett!

Beschlossen wurde der Abend stilgerecht im Partyzelt mit der beklopptesten Retro-Pop-Band, die ich jemals sah, “Baby of Control“.