Category Archives: Houdini

Woodville Walkthrough

Zur fünften Pixar Art Challenge ging es um das Thema „Woodville“ – also ein Baumdorf. Pixar stellte die Assets zur Verfügung, die traditionell aus dem Pixar Undergradu­ate Program (PUP) stammen. Inhalt, Look und Feel waren prinzipiell freigestellt. Man musste aber einen Work-in-Progress-Thread im Forum eröffnen und seinen Fortschritt bildlich und in Textform teilen.
Das Forum wurde von den Juroren begleitet und die Beiträge kommentiert. D.h. Feedback und Hilfestellungen kamen direkt von Pixar.

Die weiteren Vorgaben waren: Am Ende sollte mit Renderman gerendert werden, das gestellte Asset, modifiziert oder unverändert, musste inszeniert werden. Zusätzliche 3D-Objekte waren erlaubt, mussten aber zum Bild beitragen.
Außerdem: ein Format von 16:9 quer oder hoch (Letterboxing erlaubt), maximal 4K, nur Color Correction und Grading in der Post und natürlich kein Photobashing. Wobei Background-Bilder erlaubt waren, solange man selber das Copyright dazu hat.
Die Wertungsverteilung setzte sich aus 20 % Konzeptanteil (Hauptidee und Umsetzung), 40 % künstlerischer Anteil (Umsetzung der Hauptidee, Farbgebung und Komposition) sowie weiteren 40 % technischer Anteil (Umsetzung von Texturing, Shading, Lighting, Rendering und Compositing) zusammen. Neben der Kreativ-Challenge, Ruhm und Ehre, lockte Pixar mit lukrativen Preisen.

Da ich mich nur an Abenden und Wochenenden aktiv dransetzen konnte, begleitete die Challenge mich (und meine Familie) von Ende August bis Mitte November.

 

 

 

 

Konzept

Meist habe ich etwas im Kopf und finalisiere es dann Schritt für Schritt im späteren Prozess. Nicht wirklich Standard, nicht wirklich effizient. Aber für Dinge, die man für sich macht, war es bis jetzt meist ausreichend. Für dieses Projekt machte ich es aus Gewohnheit nicht anders, und obwohl 20 % der Wertung in die Konzeptphase gingen, bin ich das Risiko eingegangen.

Erster Schritt:
Moodboard bei Pinterest

Zunächst investierte ich einige Zeit, Mood-Bilder bei Pinterest zu suchen, was sich grundsätzlich als Inspirations- und Ideenpool für mich bewährt hat. Also habe ich eine Pinnwand erstellt und fleißig und ohne viel nachzudenken meine Vorstellungen als Bilder gesammelt. Farben und Stimmungen habe ich grob berücksichtigt, dann auf etwa 10 Bilder runtergefiltert und ein Moodboard erstellt. Im späteren Verlauf rückte ich etwas vom Moodboard ab, vor allem was die Idee der Felsen betraf, und holte mir noch mal zusätzlich Inspiration und überprüfte die Plausibilität bei den berühmten Felsformationen des Zhangjiajie National Parks in China und des Elbsandsteingebirges.

Zweiter Schritt:
Concept in Houdini

Ab diesem Zeitpunkt führte ich die Konzepterstellung bzw. das Blocking komplett in Houdini fort. Lessons Learned war hier, dass ich das so nicht mehr machen würde, sondern in Zukunft einen finalen Konzeptstand ganz klassisch vorher in 2D erstellen werde.
Es entstanden mehrere Entwürfe in Bezug auf die Story. Anfänglich probierte ich, einen Reisenden zu begleiten, der große Höhen erklimmt und in einem dubiosen Hotel ankommt oder eine düstere Mautstelle passiert. Schlussendlich kam ich ganz von der Darstellung eines Charakters ab und fand es interessanter, den Fokus mehr auf das Haus zu lenken. Jemand wohnte dort in abenteuerlichster Umgebung und war anscheinend so wichtig, dass man die Gefahren des Aufstiegs auf sich nahm, da sich ein Besuch lohnte.

Visual Storytelling

Nur ein schönes Bild zu produzieren, würde nicht reichen, was man auch im Verlauf an den Kommentaren von Leif Pedersen von Pixar zu meinen WIP-Bildern oder an denen meiner Mitstreiter bemerken konnte. Das Auge wollte geführt werden, das Asset sollte eine zentrale Rolle spielen und Komposition, Licht und alle verschiedenen Bildelemente mussten zusammen funktionieren und für den Betrachter eine Geschichte erzählen. Ich versuche in den folgenden Abschnitten darauf Bezug nehmend einige Entscheidungen zu erklären.

Kamera

Ich änderte die Perspektive einige (viele) Male im Laufe des Wettbewerbs, vor allem weil ich anfangs noch zu sehr in der Blocking-Phase war und die Umsetzung der Story am Anfang stand. Dabei stand ich vor der Herausforderung, Weite und Tiefe gleichzeitig begreifbar machen zu wollen. Ich unternahm viele Versuche, das Bild im Querformat zu realisieren, was auch immer von Leif als Wunsch geäußert wurde. Aber es war entweder zu viel unwichtiges Environment im Bild, was nichts weiter zur Story beitrug und somit Verschwendung war, oder es war andererseits keine Tiefe vorhanden, sondern nur Weite spürbar. Schlussendlich entschied ich mich daher für das Hochformat. Möglicherweise führte dies zu Punktabzügen, doch ich blieb bei der Entscheidung.

Überlegungen zur Software

Seit etwa vier Jahren beschäftige ich mich intensiv mit Houdini und versuche, es in der täglichen Arbeit so oft es geht einzusetzen. Zu Hause habe ich eine Indie-Lizenz, und somit war relativ schnell klar, dass der Großteil in Houdini passieren sollte. Blender war auch kurz auf der Liste, aber ich habe noch kaum damit gearbeitet, 2.8 war noch nicht releast und ich wollte kein Risiko eingehen. Ich behielt mir vor, es für etwaiges Sculpting oder andere unterstützenden Tätigkeiten einzusetzen, aber es blieb am Ende bei Houdini auf der 3D-Seite. Als Texturing-Tool stand Substance Painter ganz oben, weil mir das Lizenzmodell zusagte und mir Mari zu komplex für den Task vorkam. Für die Post verwendete ich Nuke in der 30-
Tage-Testversion. Hier vermisse ich (und vermutlich viele andere) immer noch die Indie-Option.

Felsen

Von Anfang an wollte ich volle Flexibilität und schnelle Iterationen gewährleisten. Für die Felsen bot sich natürlich ein prozeduraler Ansatz an, da ich eigentlich auf Sculpting verzichten wollte und schon relativ genaue Vorstellungen im Kopf hatte. Einige technischen Ansätze basierten auf Saber Jlassis Vortrag auf der Siggraph 2017 und Hugo Beyers Rock-Butte-Tutorial bei Gumroad (siehe Links am Ende).
So ging ich dabei vor: Erst mal die grobe Form durch eine Ramp steuern, die dann anschließend mit rein zufällig platzierten Boxen, Spheres und Tubes aufgefüllt wurde. Immer mit der Option, eigene Geome­trie manuell hinzufügen zu können, um z.B. bestimmte Plateaus oder Einschnitte zu erzeugen.

Als Nächstes löschte ich einige Elemente manuell (wäre aber auch problemlos automatisch machbar) nach einem Voronoi-Fracturing der Geometrie. So entstanden Einschnitte im Fels. Dann konvertierte ich das Ganze zum ersten Mal in VDB.

 

Ein wenig Reshaping und Smoothing, und nun ging es zum eigentlich spannenden Teil.


Mehrere aufeinanderfolgende Noise VOPS erzeugten den eigentlichen Fels-Look. Man kann diese im Prinzip stacken, so oft man will, um den gewünschten Look zu erzeugen, allerdings kann es relativ rechenintensiv werden, je nachdem wie man es ausreizt bzw. die Operationen wiederholt. Wenn man die Parameter auf den VOP Node promotet, hat man sie alle bequem zur Hand. Nach ein wenig Herumprobieren bekommt man recht schnell ein Gefühl für sein Tool und kommt auch zügig zum Ergebnis. Und jetzt erst mal cachen.

Der letzte Schritt war das Erzeugen der horizontalen und vertikalen Felsblöcke. Hier nutzte ich wieder den Voronoi-Fracture, aber diesmal, um Schnittblöcke zu erzeugen, einmal über die gesamte Geo und dann ein zweites Mal in einem Loop über jeden vorher erzeugten Block.

Dann wurde dieses Ergebnis mit dem VDB Fracture an das von oben reinkommende VDB übertragen und zurück zu Polys konvertiert. Nun noch die Kanten hervorgehoben, ein wenig die Geometrie aufgeräumt und wieder in ein VDB konvertiert, ein schnelles Reshaping, wieder zurück zu Polys konvertiert und ein letztes Mal „reduced“. Fertig sind die Felsen. Die vorderen Felsen habe ich nach einem zweiten Cashen „subdivided“, die im Mittelgrund stehenden so belassen und die entfernteren sogar noch weiter „reduced“, um möglichst viel an Speicher zu sparen.

Hängebrücken-Asset

Schon relativ am Anfang war mir klar, dass Hängebrücken eine markante Rolle in der Geschichte einnehmen würden. Ich merkte schnell, dass ich durch das anfangs häufige Versetzen der Felsen auf ein Asset angewiesen war, das all dies nervenschonend mitmachte.
Ich wollte ein Tool, was simpel zu bedienen war. Nun gibt es Einlassungen zu Hängebrücken wie Sand am Meer im Internet, dennoch wollte ich etwas Eigenes. Hier nun ein kurzer Überblick: Man benötigt nur drei Kurven, um eine Brücke zu bauen. Die Hauptkurve beschreibt den Weg selbst, und zwei weitere oben dienen als Unterstützungskurven, die die horizontalen und vertikalen Tragseile erzeugen.

Das Asset hat einen Preview-Mode, um nur das Kurvenskelett anzuzeigen, dann ist es deutlich schneller. Im Grunde baute ich einen Kurvenkäfig, der im Anschluss gemesht wird.

Ich wollte die Seile als echtes Mesh, somit habe ich mir die Mathematik der Kreise im Kreis näher angeschaut und das in einem Vex-Wrangle zusammengeschrieben.

Die Holzplanken waren prinzipiell voll prozedural, hatten am Ende aber relativ lange Cooking-Zeiten. Das war mir persönlich zu lang, und man sah die Unterschiede eigentlich nicht. So habe ich einfach 25 verschiedene Planken gecacht und diese dann zufällig verteilt. Nur das Feature Plank Randomness geht dann nicht, da sie ja nicht prozedural erstellt werden. Am Ende kamen noch Fake-Knoten (die man schöner hätte machen können), Kabelschuhe und Löcher in den Planken dazu.

Man hätte es natürlich immer weiter ausbauen und verfeinern können, aber für meine Zwecke der Challenge war das vollkommen ausreichend. Wer mehr wissen will: Am Ende des Artikels findet ihr alles zu den UVs und Hängebrücken zum Download. Und wer in München auf einem Houdini-Stammtisch ist, dem kann ich es direkt zeigen – so wie das UV-Tool, zu dem wir dann gleich kommen.

Environment Layout

In einem separaten Houdini-File habe ich meine statischen Assets aufbereitet. Zum einen die Bäume, das Moos und andere Gewächse, die ich gekauft habe, sowie auch den ebenfalls gekauften Ballon. Dort wurden die Geometrien bei Bedarf entkernt und auf denselben Scale und auf Null gebracht, Materialnamen als „shop_materialpath“ oder ein Name-Attribut erstellt und das Ganze dann als Alembic exportiert. Das Terrain besteht zum einen aus Height Fields, die ich relativ klassisch angewendet habe, sprich Height Field erstellt und verschiedene Height Field Noises gelayert. Das Kamera-Frustum habe ich als Cutout benutzt (ob es allerdings speichertechnisch was gebracht hat, konnte ich nicht prüfen), anschließend mit dem Height Field Erode Node Details hinzugefügt und das Ganze dann gecacht.

Dann einige Masken zusammengerechnet und auch die später aufgestellten Felsen abmaskiert. Diese Maske steuert das Scattering der Bäume – sie ging in einen Height Field Scatter Node, der von verschiedenen Alembics gespeist wurde. Die einzelnen File Nodes bekamen unterschiedliche Class-Attribute, um die Zufälligkeit zu gewährleisten. Insgesamt habe ich knapp 180.000 Bäume verteilt.

Die Felsen habe ich im Verlauf tatsächlich mehrmals umpositioniert (wirklich sehr oft). Als ich dann zufrieden war, wollte ich zusätzlich noch Vegetation auf den Felsen verteilen. Auch hier sollte alles wieder möglichst speichereffizient sein. Zunächst holte ich mir den jeweiligen Felsen und generierte dann UVs von der Kamera ausgehend. Daraufhin löschte ich in einem Vex-Wrangle zunächst alles, was außerhalb des Kamera Frustums lag (UVs wurden ja aus der Kameraperspektive erstellt). Im nächsten Wrangle löschte ich zusätzlich alle Faces mittels der Intersect-Funktion, die nach einem ersten Ray Hit noch existierten. Jetzt hatte ich erst mal nur das, was ich tatsächlich im Bild sehe.

Für das eigentliche Verteilen der Vegetation entfernte ich jetzt noch alles, was zum einen nicht nach oben zeigt und zum anderen nicht eine bestimmte Fläche einnimmt. Beiden Strängen wies ich ein Density-Attribut zu, welches den Scatter Node steuerte. Die erzeugten Punkte bekamen noch einen zufälligen Orient-Wert. Nun prüfte ich in einem anderen Vex-Wrangle, ob sich diese Vektoren in einem bestimmten Radius trafen, und dünnte so weiter aus. Bei manchen Felsen löschte ich abhängig von einer Ramp, die von oben nach unten wirkte. Auf diese Punkte kopierte ich dann wieder Alembic Files, wie oben beim Terrain.

Haus-Asset

Das Hero-Element, wenn man es so nennen will, wurde von Pixar bereitgestellt, allerdings ohne Texturen, mit mehr Geometrie, als ich eigentlich brauchte, und vor allem (schmerzlicherweise) ohne UVs. Also war zunächst Housekeeping angesagt.

Ich hatte wenig Lust auf UVs – dieses Problem schob ich als Task nach hinten – was dazu führte, dass ich relativ lange WIP-Bilder ohne Texturen postete, was sicherlich das Publikum da draußen gewaltig langweilte. Aber zurück zum Thema.
Erst mal wurde alles nicht Benötigte gelöscht. Jetzt kamen die UVs: Sie sollten einerseits materialbezogen (bzw. bauteilbezogen) zusammengefasst werden, zum anderen zueinander im gleichen Scale und vor allem aber mehr oder weniger gerade ausgerichtet sein.

Mein Glück war, dass eine einigermaßen saubere Namensstruktur und Hierarchie im Alembic bestand. Das konnte ich mir zunutze machen. Meine aufgeräumte Geometrie bestand aus 63.496 Poly Soups, bei denen ich UVs erstellen hätte müssen.
No fun job.
Also kam alles in ein For Loop, in dem ich zunächst alles in eine Group packte. Dann wurde mit dem Bound Node die Ausrichtung erfasst (Oriented Bounding Box). Der Bound Node gibt einem das Xform-Attribut zurück, das im nächsten Schritt im Transform-by-Attribut invertiert wurde. So hatte ich die Geometrie am Nullpunkt und recht gut gerade gestellt, jedenfalls ausreichend für meine Zwecke. Dann konvertierte ich noch die Poly Soups zu Polygonen, und jetzt kam der Unwrap. Anschließend wurde zurücktransformiert zum Ausgangspunkt und die enthaltene Bounding-Box-Geo gelöscht. Das dauerte auf meiner Maschine knapp 30 Sekunden. Packte man den Loop in einen Compiled Block, dauerte es gerade mal 4,6 Sekunden, um das ganze Asset mit UVs zu versehen. Nice!
Anschließend bekamen die Prims ein Name-, ein TopName- und ein LowLevel-
Attribut, indem ich einen bestimmten Teil aus dem Path-Attribut (also der Namensstruktur) herausschnitt. In einem folgenden Loop, der als Piece-Attribute
„name“ zugewiesen bekam, wurden dann die zusammengehörenden Meshes
im UV-Space gelayoutet. Das kann dann tatsächlich einige Minuten oder mehr in Anspruch nehmen. Danach bot es sich auf jeden Fall an, die Geo zu cachen.

Jetzt kamen noch die Materialien auf mich zu. Zuerst baute ich mir den „shop_materialpath“ mittels eines weiteren Loops aus Groups, die als ihren Namen die beiden vorher generierten TopName- und Name-Attribute beinhalteten. Die fügte ich dann in einem Wrangle zusammen. Ich musste anschließend 94 Shader erstellen. Hierfür musste Python herhalten, und ein Kollege half mir beim coden. Das Skript erstellte die Shader und verknüpfte im Anschluss die Pfade der im Substance Painter erstellten Texturen mit den jeweiligen File Nodes. Der Rest bestand dann noch im Exportieren der einzelnen Geometrien für Substance Painter sowie diversen Material Overrides und spätes Clean-up an Dingen, die mir anfangs nicht auffielen.

Wege-Asset

Bis zu diesem Punkt war ich schon ganz zufrieden mit den Ergebnissen. Aber Leif machte eine durchaus richtige Anmerkung bezüglich des Visual Storytellings, nämlich dass in der unteren Hälfte des Bildes eigentlich nicht viel Story stattfand. Ich hatte schon das gleiche Problem beim Finden des Kamerawinkels beim Querformat. Bei einem Bier mit einem Kollegen und Freund kam die Idee, dass es außer den Hängebrücken noch einen anderen Weg geben müsste. Einen noch viel beschwerlicheren und gefährlicheren. Der Spiralweg war geboren.
Zunächst wurde der Hero-Fels „reduced“ und in ein VDB und zurückkonvertiert. Mithilfe des SideFx Labs Tools „sop_spiral“ und einem Ray Node projizierte ich eine Spirale an den Fels.
Nach Bereinigung des Ray-Ergebnisses mithilfe der Ray Hit Group und Hinzufügen von Normals wurden die Aussparungen für die kurzen Hängebrückenelemente mit mehreren Carve Nodes erzeugt.

In den nächsten beiden Loops wurden die Prims neu unterteilt und dann mit dem Skin Node zu einem Weg verbunden, um dann im dritten Loop die einzelnen Bretter zu erzeugen. Alles eigentlich recht straightforward. Anschließend folgte wieder das automatische UV-Tool. Von oben ging ein separater Strang zum Erzeugen der Geländer ab. Diese waren recht simpel gehalten. Die untere Abgrenzung wurde einfach von einer expandierten Kurve mit meinem aufgebohrten Sweep Tool erzeugt. Daraufhin habe ich die vertikalen Geländerpfosten an die zuvor wieder neu unterteilte Kurve kopiert. Der Pfostenquellgeometrie hatte ich noch oben einen gesonderten Punkt hinzugefügt, an dem ich später die Lichter instanziierte. Die Seile entsprangen der gleichen Kurve wie oben, die ich wieder neu unterteilte und dann mit ein wenig Vex durchhängen ließ. Zu guter Letzt verteilte ich noch Lampen oberhalb der kleinen Hängebrücken, die diese Überquerung quasi absichern sollten, stellte noch einige Hinweisschilder auf und kopierte Lampengeometrie an die Geländerpfosten.

Texturing in Painter und Shading

Ich hatte Substance Painter vorher noch nie benutzt, war aber sehr schnell vom Workflow begeistert. Es fühlte sich alles ein wenig wie Photoshop an. Das kann man jetzt mögen oder auch nicht, jedenfalls sind die Bedienung simpel und die Möglichkeiten vielfältig. Man findet sich schnell zurecht, was ich bei Mari eher etwas fürchtete.
Ich begann zunächst, die wichtigsten Bereiche wie Dachschindeln, die verschiedenen Hölzer sowie den Baumstamm zu entwickeln, und fand hier die Möglichkeit, fertige Materialien abzulegen und wiederzuverwenden, unglaublich effizient. So hatte ich das gesamte Haus-Asset in etwa 4 Stunden fertig texturiert.

Wie schon erwähnt, hatte ich ein Python-Skript, das mir die knapp 500 Texturen aus Painter mit den PxrTexture Nodes in den 94 Shadern verknüpfte. Die Shader selbst waren allesamt PxrSurface Shader, außer die Volumes.
Außerdem bewährte sich der PxrVary Node, der über ein Attribut gesteuert einzelne Parameter wie den HSV-Wert im PxrSurface, zufällig verändern kann. Man gibt nur das Weighting für die einzelnen Werte an. Ein schneller und einfacher Weg, Varianz in den Look zu bekommen, zum Beispiel bei den Holzplanken oder der Vegetation.

Wasserfall

Den Wasserfall sparte ich mir für den Schluss auf, da ich mir die Option offenhalten wollte, ihn gegebenenfalls wegzulassen, sollte ich mit anderen wichtigen Dingen nicht rechtzeitig fertig werden. Geplant war dann, das Wasserrad alternativ zuwachsen zu lassen und es so außer Betrieb zu setzen. Aber ich hatte die Zeit, und ein bisschen Atmosphäre kann ja nicht schaden.
Es gab zwei Emitter, einen, der aus einem fiktiven Rohr kam, und einen etwas weiter unten kurz oberhalb des Rades, um einfach noch etwas mehr Wasser aufzubringen. Die Normalen der Emitter-Spheres richtete ich mit simplen Vex in die gewünschte Richtung aus und gab ihnen jeweils eine Initial Velocity. Das Rohr, das Wasserrad und der Felsen wurden als VDB Collider hinzugefügt. Alles andere war eigentlich relativ straight out of the box.

Ich aktivierte Reseeding und die Droplet Detection und stellte außerdem Volume Limits im Solver ein.
Als Particle Separation hatte ich im finalen Run 0,2.
Zuerst wurden die Particles gecacht. Die Sim dauerte nicht lange, ich war recht erstaunt. Ich probierte mit niedrigeren Particle Separations herum, kam aber zum Schluss, dass ich im Verhältnis keine Besserung bemerkte.
Somit blieb ich bei den anfänglichen Werten und wandelte das Ergebnis in Geometrie mit dem Particle Fluid Surface Node. Bis auf das Voxel Scale war wieder alles Standard. Ich verkleinerte die Geo anschließend noch mit einem Peak Node um -0,01. Dann wieder cachen und fertig. Wenn echte Sanitärarbeiten mal so einfach wären!

Zusätzliche Props und Bewuchs der Brücken

Gerade in Bezug zur Geschichte fehlte noch etwas Essenzielles, insbesondere weil ich keinen erkennbaren Charakter (im Gegensatz zu meinen ersten Ideen wie oben beschrieben) einsetzen wollte. Das Uncanny Valley, meine nicht vorhandenen Skills in Bezug auf Charakter und der zeitliche Aspekt spielten hier eine große Rolle.
Da kam mir die Idee mit dem Ballon. Anfangs noch mit der Hotel- / Mautstationsidee verknüpft, wo er eher ungenutzt und verfallen am Felsen herabhängen sollte, kam mir dann der Einfall mit Tante Betty, die im Leben nicht auf die Idee käme, den beschwerlichen Aufstieg auf sich zu nehmen. Sie nutzt andere Fortbewegungsmittel und bevorzugt die bequemere Anreise.
Zum Modeling war ich ehrlich gesagt etwas zu faul und außerdem waren die Projektabende neben der Arbeit und Familie beschränkt. So entschied ich mich zum Kauf und fand einen ansehnlichen Ballon für 15 US-Dollar. Kurzerhand in meiner Prep-Szene mit Materialattributen versehen, etwas entkernt und bereinigt für den Export vorbereitet, hatte ich schnell die passende Location für ihn gefunden. Es fehlten dann noch Props, wie Koffer, das Brett vom Ballon zum Balkon, Seile und Besen (auf Stühle, Tische und andere Terrassendeko wie anfangs angedacht verzichtete ich wegen klarer Bildsprache).
Außerdem wollte ich unbedingt noch etwas mehr am Alter der Brücken arbeiten und fand ein großartiges Houdini Digital Asset bei Gumroad namens Ivy Taming, welches den Bewuchs von Efeu oder Ähnlichem spielend leicht ermöglichte.

Environment Fog / Wolken

Es brauchte noch etwas mehr Atmosphäre, also Nebel und Wolken. Für die Wolken war eine verformte Sphere die Basis, an die ich mehrere andere zufällig aussehende Spheres kopierte. Diese wandelte ich einmal in VDBs und wieder zurück, dann wiederholte ich den Vorgang mit kleineren Spheres als Lückenfüller. Das Ergebnis konvertierte ich in ein Fog VDB und ließ es ähnlich wie bei den Felsen durch mehrere Volume VOPS laufen, die verschiedene Noises auf das Volume anwendeten. So kam ich auf ein für mich ausreichendes und auch interessantes Ergebnis. Das Houdini Cloud Tool / Rig habe ich natürlich anfangs auch in Erwägung gezogen – doch was ich auch tat, es wollte mit Renderman nicht rendern. Da das Bugfixing zu lange gedauert hätte, beschloss ich, obigen Weg zu gehen. Der Nebel war im Prinzip ein großes Volume ausgehend von einer großen, flachen Box mit obiger Technik.

Lighting

Anfangs wollte ich eher eine Dämmerungs- oder Sonnenuntergangssituation leuchten. Ich probierte zunächst einige HDRs aus, empfand schlussendlich dann aber Mondlicht als die beste Lösung. Ein PxrDistantLight unterstützte die HDR als Keylight, leicht bläulich eingefärbt. Zudem kamen eine ganze Reihe PxrRectLights oder PxrDiskLights als Aufheller oder Rim Lights im Environment zum Einsatz. Besondere Stellen, die das Auge führen sollten, wie zum Beispiel Bereiche der Felsen zur Linken, die Brücken im unteren Teil des Bildes sowie der Baum im Vordergrund wurden ebenfalls gesondert beleuchtet.
Zusätzlich instanziierte ich ca. 200 kleine PxrSphereLights am Geländer des Spiralweges. Das Haus bekam Beleuchtung an den Veranden und der Wendeltreppe. Außerdem setzte ich Unterstützungslichter in Bereiche, wo Licht aus den Fenstern schien. Das Ballonfeuer erhielt auch noch ein Licht, um seine Wirkung zu erweitern.

Rendering

Es war tatsächlich mein erstes Mal mit Renderman – ich komme eigentlich aus der V-Ray-Ecke. Allerdings machte ich mir nicht allzu viele Sorgen, und es war tatsächlich auch kein Problem. Die Dokumentation war ausreichend gut und auch sonstige kleine Hürden konnte ich recht gut mithilfe diverser Foren oder kurzer Internetrecherchen lösen.
Ein größerer Bug, der mich ereilte, war, dass die Cryptomatte-Zuordnung nach einem erneuten Rendering komplett neu war. Das führte dazu, dass ich die alte Cryptomatte in Nuke behalten und einen Workaround finden musste. Ansonsten machte ich keine große Wissenschaft daraus – ich renderte den Vordergrundbaum, den Wasserfall sowie die Volumes extra. Darüber hinaus blieb es eigentlich beim Beauty mit den diversen üblichen AOVs. Ich nutzte das Checkpoint-Rendering-Feature, was sich als sehr nützlich erwies, vor allem, wenn man zwischendurch beim Batch Render mal den Zwischenstand kontrollieren wollte. Der Beauty renderte in ein wenig mehr als 4K etwa gute 11 Stunden. Klingt erst mal recht lang, allerdings muss man sagen, dass Renderman in Anbetracht der Szene sehr robust ist und mir sein Look einfach sehr gut gefällt.

Finishing

Eine Vorgabe der Challenge war, wie eingangs erwähnt, keine Retusche anzuwenden. Somit beschränkte sich die Post im kreativen Verbauen und Anpassen der AOVs. Ich nutzte Nuke und beschränkte mich im Prinzip auf Grade und Color Correct Nodes, nur am Ende kamen dann noch subtile chromatische Aberrationen und ein wenig Glow in den Lichtern dazu.

That’s it – a tough run.

Die große Hilfe

Ein großes Dankeschön gilt meiner Familie und allen Freunden und Kollegen, die wochenlang Ideen, Strategien, meine geistige und körperliche Abwesenheit und viele Feedback-Wünsche über sich ergehen lassen mussten, allen voran meiner Frau und meiner Tochter, Oliver Koch, Oliver Kortemeier, Oliver Markowski, Michael Meier, Klaus Scherwinski und Christian Schnellhammer.

Und am Schluss?

Leider hat es nicht für den Sieg gereicht, nur für eine „Honorable Mention“ – hier geht es zu allen Platzierungen: https://renderman.pixar.com/news/renderman-woodville-art-challenge-final-results. Und bei der nächsten Challenge? Das wird man sehen.

Concept by Vasylina Holod.
Model by Alex Shilt © Disney / Pixar –
RenderMan „Woodville“ Art Challenge

Procedural Rock Formations for
UE4 | Saber Jlassi | Houdini HIVE
at SIGGRAPH 2017
https://vimeo.com/228238370

Hugo Beyer und seine Houdini Tools
auf Gumroad
https://gumroad.com/hugobeyer

Das Efeu-Tool auf Gumroad
https://gumroad.com/l/ivyTaming

Und die Tools und Assets für diesen
Artikel zum Download:
http://bit.ly/woodville_assets