Transcript: Python in der Visual Effects Branche

Ja, hallo liebe Hörerinnen und Hörer, herzlich willkommen beim Python-Podcast, heute ist die 31. Episode, wir machen heute Visual Effects und Python, also ein bisschen aus der Filmindustrie und wir haben natürlich neben dem Jochen, hallo Jochen, und mir den Dominik, einen wunderbaren Gast dabei, den Fabian, und ich finde, er kann sich selber vorstellen, er macht nämlich tolle Sachen, du musst erstmal erklären, was ist dein Job und wer bist du und was machst du denn?

Ja, hallo, also ich bin Fabian, ich arbeite als Pipeline-Developer oder Pipeline-TD in der Visual-Effects-Branche und genau, ich programmiere quasi Arbeitsabläufe im Hintergrund, weil die Datenmengen und das, was da passiert auf dem Bildschirm, da muss halt eine ganze Menge im Hintergrund auch geregelt werden.

Also alles in Python?

Größtenteils schon.

Und das, was du da machst, das ist irgendwie, man guckt einen Film und dann explodiert irgendwas und die Art und Weise, wie das explodiert, das baust du, oder?

Das macht quasi der Artist, der hat ein spezielles Programm, dass das kann. Ich bin aber quasi noch eine Stufe davor. Ich regele quasi, dass dieser Artist sich nicht mehr darum kümmern muss, wo er Sachen abspeichern muss, sondern quasi einfach nur sagen muss, okay, ich möchte an Haus XY arbeiten und das in die Luft jagen.

mach mir mal eine Datei auf.

Und das ist quasi mein Job, den ich da im Hintergrund mache,

dass die das alles nicht mehr nachdenken müssen,

wo sie Sachen abspeichern, wo sie Dateien hinkommen.

Also diese ganze Geschichte in der Filmindustrie,

die kann man tatsächlich also auch mit Python machen.

Und darüber werden wir heute euch ein bisschen erzählen.

Schön, dass du da bist, Fabian.

Ja, danke.

Vielleicht fangen wir doch mal mit ein bisschen Struktur an.

Ihr wisst, wir vermissen das immer ein bisschen selber.

Es gibt ein bisschen News, glaube ich.

Ja, was haben wir denn da so?

Wir haben wirklich viele

Neuigkeiten, aber

also ein Ding, was mich so ein bisschen

freut, oder ach nee, das hebe ich mir auf.

Das hebe ich mir auf für was anderes. Für die

Pigs später. Genau.

Komm, jetzt musst du spoilern, weil es gibt Leute, die hören

halt lustig. Das hat was mit der Fischshelle zu tun.

Das reicht. Mit was hat das zu tun?

Mit der Fischshelle, die kennst du auch. Oh ja,

natürlich kenne ich die lustigste gerne. Ja, und

ansonsten ist halt

noch irgendwie

Django 3.2 ist released worden.

Oh ja.

Habt ihr schon alle in Produktion?

Relativ einfach ging der Umstieg

ohne Probleme. Ja, also bei mir war das

mittler, ich glaube, das war echt das

problemloseste Django-Upgrade,

das ich bisher so hatte. Man kann sich jetzt

ein neues Setting gewöhnen, die da

die Standard-Key

oder Primary-Key-Variante

ist, die man gerne für seine ganzen Projekte hätte.

Ja, das muss man jetzt halt

konfigurieren, sozusagen.

Sonst kriegt man Warnungen.

Genau, das war alles und dann

funktioniert alles wie vorher auch und er nimmt sogar die alten

Keys und behält die, macht sie also nicht weg

und nimmt also nur die neuen Tabellen, die man einbaut.

Also es passiert nichts Schlimmes, wenn man

jetzt irgendwie upgradet, nicht, dass

dann plötzlich alle Primary Keys

doppelt so groß sind. Wir sind mittlerweile bei 3.9,

4 oder so und ich warte immer noch auf 3.10.

Ihr wisst warum. Hier kommt ja jetzt

demnächst auch bald. Ja, genau.

Ich hätte auch noch ein paar News. Einfach mal

aus meiner Branche. Autodesk

Maya ist jetzt auf

Version 2022

hochgestuft worden.

Das Besondere daran ist,

wir sind endlich auf Python 3.

Oh, wow.

Ja.

Blast from the past.

Ihr hört,

die Visual Effects-Industrie ist anscheinend

sehr weit vorne, was Software

angeht. Woran das wohl liegt,

ich habe gehört, viele arbeiten dort tatsächlich mit

Windows und die Interpreter sind alle

eingebaut in die Programme.

Ja, die sind

fast durchgängig allen Programmen

eingebaut, was natürlich

das Upgraden zwischen den Python-Versionen

relativ schwierig macht, weil

naja, die Programme sind eher

konservativ eingestellt und sagen, okay,

bevor wir den Artists da ihre

Skripte kaputt machen, fassen

wir das mal lieber nicht an.

Und naja, zwölf Jahre

später

wird es jetzt so langsam auch security-technisch

und so kritisch,

dass man Python 2 eigentlich nicht mehr so richtig

benutzen sollte.

Und ja,

jetzt ziehen wir langsam nach.

Ich würde sagen,

gut drei Viertel aller

Programme, die so gängig sind in der Industrie,

haben es inzwischen

einigermaßen geschafft auf den Sprung.

Aber es gibt immer noch so ein paar

Nachzügler. Vielleicht für alle ganz

unbedeckt. Und was ist denn Maya?

Maya ist ein

sehr geläufiges

3D-Programm aus

der Branche. Also man heißt, man kann

Modelle, Objekte

rendern, generieren, darstellen,

bauen. Genau.

All das im Grunde genommen.

Sprich, du willst

einen Charakter oder ein Haus

irgendwo in eine Szene stellen,

dann kannst du es da bauen, hübsch

ausrendern und

ja,

auch durchprogrammieren mit Python,

wenn du möchtest. Das heißt, ich kann

dann Achsen skalieren, drehen und

Bewegungsabläufe skripten

oder was macht man da mit Python?

Genau, die Python-API in Maya ist eigentlich sehr, sehr mächtig.

Du kannst im Grunde genommen wirklich alles durchskripten,

wenn du möchtest.

Alles, was du per Keyboard und Maus eingeben kannst,

kannst du genauso gut in Python einskripten.

Also wenn du wild genug bist,

kannst du wirklich ein Python-Programm schreiben von A bis Z

und am Ende hast du einen Baum.

Kein Problem.

Das wäre nett.

also da hätte man verschiedene Objekte

und könnte dann eine kleine Bibliothek bauen mit

verschiedenen Bäumen, hat man einen ganzen Wald und dann

in dem Wald, da muss natürlich noch ein Schloss und dann noch

ein Schloss mit einem Drachen.

Ja, aber

schick, weißt du, warum,

eigentlich sind wir da schon fast im Thema, wir können eigentlich

auch, können wir auch

ein paar, weißt du

oder das kannst du wahrscheinlich

ja sagen,

woran das liegt, warum hat man sich denn da

so auf Python

quasi

standardisiert, weil

ich kenne das jetzt aus anderen Bereichen,

da es wird häufig zum, damit man halt

irgendwie

so Applikationen skripten kann, also ich kenne das

zum Beispiel hier von der digitalen

Digital Audio Workstation,

die ich hier verwende, das ist Reaper,

da ist das Lua oder halt auch von

diversen anderen, so Money Money,

Online Banking ist auch Lua, also ganz oft ist es Lua,

wenn man das halt super einfach integrieren kann in C,

aber Python ist eigentlich gar nicht so super

einfach zu integrieren.

Warum wird da Python genommen?

Ich glaube,

das ist auch so ein bisschen historisch bedingt.

Die ersten Programme und

Anbindungen haben einfach mit Python

angefangen und nach und nach hat sich das quasi

etabliert. Es gibt auch genug

Beispiele von, also Lua gibt es

zum Teil, habe ich auch schon gesehen.

Aber

viele Programme, unter anderem Maya, haben

zum Beispiel auch einfach ihre Skriptsprache

selbst erfunden. In Maya

gibt es Mail, die Maya Embedded

Language.

Erinnert sehr

stark an Bash.

Oh.

Okay.

Also wer Bash mag, hat da

wahrscheinlich seine helle Freude dran.

Und

das Schöne an Python ist aber, dass

man sehr

gut eigentlich dynamisch Sachen

rappen kann mit Python.

Im Grunde genommen in Maya ist Python

nichts anderes als ein großer Wrapper

um Mel.

Sprich.

Okay, das heißt, du sprichst eigentlich direkt

per Kommandoteile mit

den verschiedenen Endpunkten dieses Programms

und

Kommandoteile ist hier übertrieben.

Also du befindest dich im Programm selbst,

aber Mel

ist Bash ähnlich, ja. Also du

arbeitest aber jetzt nicht auf der Kommandoteile.

Das heißt, die API, das Interface des Programms, ist das irgendwie

so, dass es halt Befehle entgegennimmt.

Genau. Die man dann aber

nicht eingeben möchte, sondern

die man automatisiert über Python-Skripte.

Also ich stelle mir das so vor,

Menschen, die ganz viel so 3D-Sachen machen,

die programmieren ellenlange

Skripte, ganz viel Code untereinander,

um Dinge zu automatisieren und

schöne Figuren zu rendern

oder Bäume, wo wir diese Welt

eben drüber gesprochen hatten. Entspricht das

der Realität oder wie sieht denn dein Arbeitstag

dann damit aus?

Das

die Artists an sich

die machen da eigentlich

alle Arbeit

nur über das User Interface

relativ wenige Skripten, es gibt ein paar

spezielle Jobs, da muss man ein bisschen

mehr skripten, weil es dann schon aufwendiger wird

aber mein

Arbeitsablauf ist eigentlich

eher im Hintergrund, sprich

ich überlege mir, okay

an meinem Projekt arbeiten 40 Leute

die alle auf den gleichen

Folder zugreifen

auf meinem Server.

Wie kriege ich es denn gebacken,

dass die sich nicht gegenseitig

in die Quere kommen oder sich

Files überschreiben oder

Sachen verloren gehen?

Auf so einem Videoprojekt müssen ja ganz schön viele Daten

aus dem Server liegen, oder?

Genau, um so ein paar

Eckdaten zu haben. Also für ein Projekt,

was wir neulich erst abgeschlossen haben,

was ihr auch auf Netflix gucken könnt übrigens,

nennt sich

Outside the Wire.

Ist wirklich, also

Visual Effects top,

Story, naja.

Aber da

hatten wir im Endeffekt

12 Millionen Dateien auf dem Server

und

das waren insgesamt

220 Terabyte, glaube ich.

Und naja,

es ist halt eine Menge Holz.

Ein bisschen größer als mein Heimcomputer.

Das will man erstmal durchs Netzwerk schleifen und dann natürlich auch noch die Übersicht behalten, dass du weißt, okay, ja, diese Version fand ich schön, die nächste ist vielleicht nicht so toll oder, ja, dann muss man auch noch bedenken, okay, diese Artists, die arbeiten natürlich auch noch miteinander.

Also der eine baut das Haus, der andere malt es an, der nächste lässt es explodieren. Dann musst du natürlich auch noch zusehen, okay, wie bekommst du denn die Daten von A nach B, dass jetzt nicht jeder erstmal Windows Explorer aufmacht, einen tippt, okay, wo ist denn mein Haus und wo finde ich denn das?

sondern auch das ist alles durchgeskriptet

und gestreamlined, dass du einfach

nur sagst, okay, ich möchte von

Haus, von meinem Haus

ja, diese Außenwand

in Version 6

zack, reingeladen

fertig

Guckt man da irgendwie über so

ein Editor drauf oder sowas oder ist da dann

Maya-Interface oder habe ich so

eine Sicht wie so ein CAD-Programm

auf das ich dann schauen kann oder ist das so

ein Studio-Umgebungsding

oder? Das ist

alles integriert.

Neben Python hat sich noch ein anderer

Standard relativ gut in der Branche etabliert

und das ist PySite, beziehungsweise

PyQt.

Sprich, viele

Programme unterstützen das, dass man

mit dieser Bildbibliothek

quasi arbeiten kann.

Und das Schöne an der

Sache ist, man kann somit auch

User-Interfaces komplett durchskripten.

Sprich, du kannst

direkt sagen,

okay, ich habe jetzt hier meinen

Datei lauter, wie auch

immer, programmiere das User-Interface

dafür einmal durch und wenn ich den

aufrufe in Maya

oder in

The Foundry Nuke,

sieht er halt gleich aus.

Füllt die gleichen Zwecke und da

nur im Hintergrund arbeitet

man halt vielleicht an verschiedenen Codestücken,

weil eine Datei

zu laden in Maya ist was anderes

als in Nuke.

Also auch wir benutzen quasi relativ gängige Bibliotheken.

Vielleicht musst du uns da noch so ein bisschen einführen und so ein bisschen diese ganze Infrastruktur und das ganze Ökosystem so näher bringen, dass wir so ein bisschen diese Bausteine, die es da gibt, zusammensetzen können, weil wenn ich jetzt so zugehören, ich habe keine Ahnung von diesem Videothema, dann verstehe ich jetzt noch nicht genau, wie du diese einzelnen Belästigungen liest und wie das funktioniert.

Okay, ähm, fangen, wie fangen wir da am besten an? Ähm, vielleicht so ein paar allgemeine Sachen. Sprich, dadurch, dass ja die Interpreter in den einzelnen Programmen eingebettet sind, ähm, muss man oder sollte man zumindest danach streben, dass man alles relativ gut gestreamlined hat mit verschiedenen Bibliotheken, die man auch in verschiedenen Sachen laden kann.

Das heißt, du kannst in jeder einzelnen Interpreterschicht dieselbe Interface nutzen? Oder was meinst du mit Streamline?

Genau. Man will ja quasi nicht fünfmal das gleiche Skripten, obwohl du das gleiche willst, sondern sagst, okay, ich baue mir ein User-Interface in PySite, baue das aber so, dass ich es wiederverwenden kann in anderen Programmen auch.

Hier geht es quasi nur noch darum, dass du die Business-Logic im Hintergrund austauschst, dass die Funktionalität für den Anwender aber überall gleich ist.

Das hat auch den Vorteil für jemanden, der die Programme benutzt, der hat immer das gleiche User-Erlebnis.

Sprich, ob du ein File lädst oder ein File öffnest, ist eigentlich ganz egal, ob du jetzt ein 3D- oder ein 2D-Programm aufmachst.

ja, also diese ganze

Hierarchie, wie das alles aufgebaut

ist mit den Bibliotheken, ist natürlich

wahnsinnig komplex.

Aber

Was für Jobs gibt es denn

in dem Bereich? Also wenn ich mich da

in der Industrie wiederfinden möchte,

welche Jobs gibt es denn, die Python machen?

Da es so offen ist, kann es im Grunde genommen jeder benutzen, der möchte, weshalb auch eine Menge Code quasi am Markt ist, der weniger gut ist, hätte ich mal so gesagt. Aber es gibt zum Beispiel den Job des Riggers.

Oh, ein Rigger, das ist ein Shadow-Punk, das ist ein Mensch, der seine Drohnen nach oben schickt und sie steigen lässt.

Genau, das ist jemand, der quasi virtuelle Marionetten in Charaktere baut.

Ah, okay. Also von innen werden quasi diese Dinge bewegt.

Genau, weil wenn du einen Charakter modulierst, dann steht er zwar erstmal schön im Raum,

aber dass er zum Beispiel seine Knie beugen kann oder seine Arme beugen kann,

Das muss man dem Rechner ja erstmal verklickern, weil für den ist das nur ein Datenhaufen. Da muss man ja erstmal sagen, okay, das ist die Hand, das sind die Finger, die lasst sich so und so bewegen und damit am Ende auch eine schöne Animation, also ein Animator dann das animieren kann, muss das natürlich erstmal gebaut werden.

Da das ein relativ technischer Job ist, ist da sehr viel mit Skripting eigentlich nur zu machen, weil so eine Marionette aufzubauen dauert einfach ewig, ewig lange.

Ja, du musst ja die ganzen einzelnen Gelenke wahrscheinlich...

Marionette bedeutet, dass halt so die Dinge miteinander verbunden werden. Das heißt, wenn man jetzt irgendwo den Arm hochzieht, dass dann andere Dinge mit hochgezogen werden oder so, sozusagen.

Genau. Oder zum Beispiel, dass du Muskeln hast. Du beugst den Arm, dann geht dein Bizeps eben hoch raus.

Jeder Körperstruktur kann man sich nicht richtig bücken, weil dann muss der ganze Körper, ja, verstehe.

Genau. Da hängt eine Menge dran. Kleidung ist auch nochmal ein eigenes Thema für sich. Haare ist auch nochmal ein eigenes Thema für sich.

Also sehr große Studios wie Pixar zum Beispiel haben wirklich nur Leute, die beschäftigen sich 24-7 nur mit Haaren.

Oder nur mit Kleidung.

Das klingt aber relativ spannend, das kann man für coole Sachen benutzen.

Das klingt so, als wenn man einmal diese Logik und als Modell und als Skript irgendwie kompletieren würde,

könnte man auch die ganzen externen Effekte, also sowas wie Wind und Licht und was sich da noch alles gibt,

als Umwelteinflüsse dann auf dieses Rig

oder so übertragen, dass man

halt so ein bisschen, ja, also

nicht so statisch im Raum rumsteht und

vielleicht ein oder zwei geskriptete Bewegungen

macht, sondern tatsächlich mit der Bewegung

interagiert oder in die Bewegung so eingebettet

wird. Also sozusagen, ja,

das heißt, der Job von dem ist sozusagen

vorzubestimmen,

was sich alles

noch mitändert, wenn sich irgendwas, wenn

irgendwas bewegt wird und der Animator, der

gibt dann quasi vor,

wie die Bewegung aussehen

Genau, wie weich das wird, die Bewegung

innerhalb der Umgebung.

Aber der kümmert sich dann nicht mehr darum, dass

sich quasi, keine Ahnung,

der

die Kleidung mitbewegt, wenn sich der Arm

bewegt oder so. Genau, der fängt nur die eigentliche Bewegung ein

und das, was dann da rum passiert in der

Umgebung, das müsste dann mit durch die Skripte passieren,

oder? Weil das ist ja fast Physik. Also das ist ja

das, was man durch Algorithmen irgendwie vielleicht

Also das ist eigentlich noch

mehrstufig. Im Grunde genommen hast du erst

das Rig, dann hast du den Animator, der

da eine Animation drauf macht. Da ist

aber meistens noch relativ wenig

Physik dabei. Und erst

im nächsten Schritt gibt es dann quasi Simulationsschritte,

wo du dann sagen kannst, okay,

über meine Animationen

habe ich dann nochmal ein bisschen Wind,

die dann die Klamotten noch wehen lässt

oder die Haare

oder

keine Ahnung,

Feuerexplosionen, was immer du willst, dass der Arm

abfällt, geht alles.

Genau, weil gerade

Physik-Simulationen sind

wahnsinnig ressourcenfressend.

Das heißt, du kannst

wenig interaktiv arbeiten

als Animator, wenn du die ganze Zeit

dann auf Physik-Simulationen arbeiten

im Hintergrund laufen hast.

Also das tatsächlich aus technischer Restriktion noch?

Ja,

durchaus, ja. Es ist

immer noch eine hohe Kunst,

performante Rigs zu bauen.

Weil

die Animatoren, die wollen natürlich immer

Echtzeit haben.

Also 24 Frames die Sekunde,

sollte schon sein, aber

dadurch, dass die Programme halt

so komplex sind, ist es unheimlich

einfach, sehr langsame Rigs

zu bauen. Und wenn du dann,

ich meine, du musst ja, weiß man ja

selbst, man sitzt vor einem Rechner

und wenn irgendwas so im

Sekundentakt vor sich hin ruckelt,

ist das irgendwie kein schönes Arbeiten.

Aber wenn es flüssig ist und man sich das

angucken kann im Ganzen, dann

hat man halt

am Ende auch mehr Spaß. Ich meine,

ja.

Ja, klar

Also es gibt

hundert tolle Wege, wie man das

verschnellern kann und verbessern kann

und die Industrie ist natürlich auch immer vorne mit dabei

da die neuesten Technologien

einzubauen

Ja, aber wir

schleppen halt auch eine Menge Legacy-Stuff

mit uns rum, wo viele Leute

sich sehr lange dran gewöhnt haben

und es ist auch

schwierig, das loszuwerden

Aber ich kann mir auch vorstellen, dass es einfach

an den Release-Zyklen hängt.

Ich habe jetzt keine Ahnung, wie oft

Maya oder

Houdini oder was auch immer da released wird

oder ein neuer Release hat, aber wenn die

relativ lang sind,

dann ist ja klar, dass die nicht so aktuell sein

können wie andere

Software, die man jetzt, weiß ich nicht,

irgendwelche Web-Applikationen, die man ständig deployt.

Wobei man sagen muss, Houdini

ist eine sehr

tolle Ausnahme, die bieten

Knightly Builds an. Was ist denn

Houdini? Houdini

ist eine der größten

Effektsoftwaren,

die man im Moment so haben kann.

Sprich, damit machst du

Feuer,

lässt Häuser zusammenfallen.

Es ist

unheimlich

modular

und dadurch auch

wahnsinnig komplex zu bedienen.

Also

ich kenne einige Leute,

an der Einstiegshürde einfach

gescheitert sind.

Also

gefühlt musst du dich erstmal ein Jahr einarbeiten.

Aber wenn das Ganze ein bisschen magiert, also

ein Houdini, der dann tatsächlich

die höhere Effektschiene hat, okay.

Aber

auch da ist Skripten wieder total

angesagt. Die haben sogar interne

Skripte, die sich glaube ich sogar

zu C kompilieren, so halb.

Damit das dann richtig fix wird.

Genau.

Haben aber auch wieder ihre eigene

Skript-Sprache

da wieder erfunden.

Also es gibt ja quasi ein Level-Interface,

was da drüber liegt.

Also eine API, mit der man

Houdini-Methoden

ausführen kann.

Ist auch recht interessant,

weil gerade das Python, dadurch das Python

so modular ist und auch so

sich so in verschiedensten

Arten umformen lässt, benutzt

jeder Interface.

jedes Programm Python auch

in verschiedenen Arten und Weisen.

Also

Pythonic, würde ich sagen, ist da

eigentlich nichts.

Das ist

alles

schon sehr gewagtes Zeug, was man

da macht zum Teil.

Deswegen gibt es sogar schon

Wrapper-Libraries, die das alles mehr

in die Pythonic-Richtung

drücken,

weil irgendwann die Skripte

sich halt auch gesagt haben, so, ey,

so funktioniert das nicht.

Ja, aber das ist ja auch das, was man so

in der generellen Python-Welt hat, oder?

Dass halt die mehr Leute sich das

zur Brust nehmen und

damit arbeiten, umso

schneller entdeckt irgendjemand das

wirklich tolle Higher-Level-Interface

und man kann halt irgendwie mit der einfacheren

API die gleichen oder schönere Dinge

machen.

Ich hatte neulich so ein schönes Beispiel.

Ich hatte

eine Funktion namens

GetStringParameter

oder irgendwas und

der hat mir eine Liste zurückgegeben.

Super.

Tja.

Vielleicht hätte ich mir eine TypeAnnotation geschrieben und dann war es mir klar,

dass er es in der Liste zurückgibt.

Er hat immer eine Liste zurück und

das macht dann halt irgendwie keinen Spaß.

Ja, okay.

Ja, ne, witzig.

Ja, also Datentypen und so, was das reinigt.

Ja, was wollte ich eigentlich? Ich wollte irgendwas fragen, jetzt habe ich vergessen, was ich fragen wollte. Ist das denn nur für jetzt, also ich meine diese ganzen, also Maya und, also nee, Houdini ist doch eher so auch Realfilm-Geschichte, also quasi, wenn man irgendwie tatsächlich gefilmtes Material hat und da einen Effekt machen möchte. Oder, ich habe ehrlich gesagt keine Ahnung, wie das alles zusammenhängt.

Also für mich klingt das doch alles so, als könnte man total die tollen Computerspiele damit machen.

Äh, es geht eigentlich in alle Richtungen, die du möchtest. Du kannst damit abstrakt bleiben, du kannst es in Realfilm einbetten, du kannst auch Full-CG-Sachen machen à la Toy Story. Ist, ähm, kein Problem, du musst halt nur wissen, wie du es anfasst.

Eine große Rolle dabei spielt auch immer der Renderer, sprich das Programm, was dir am Ende die schönen Bilder auf die Leinwand zaubert.

Wir benutzen zum Beispiel in der Produktion Arnold. Der ist schon sehr auf Realismus ausgelegt, was auch für unsere Firma Sinn macht, weil wir benutzen halt sehr viel Echtzeit-Footage, also Real-Footage, wo wir Sachen einbauen möchten.

Aber man kann auch sehr viel offener gehen.

Ich glaube, RenderMan zum Beispiel kann man noch sehr viel mehr mit einstellen.

Hat natürlich auch alles immer seinen Preis.

Also je offener du bist, desto langsamer wirst du im Endeffekt.

Meistens.

Dadurch, dass man, wenn man sich quasi vorschreibt,

okay, ich möchte so realistisch und physisch akkurat bleiben,

wie es nur irgendwie geht,

dann heißt das auch, okay, ich kann halt Performance an gewissen Stellen halt einfach einbauen,

weil ich weiß, okay, ich werde niemals so einen Cartoon-Character-Look brauchen.

Kann man weglassen.

Also kannst du vielleicht nochmal kurz erläutern, was du mit Performance meinst?

Also jetzt die Geschwindigkeit, die das Ganze zum Rendern braucht.

Aber ich denke mir jetzt gerade, du hast ja eh vorgefertigte Szenen,

Also du willst das ja jetzt nicht live

irgendwie augmentieren,

sondern du möchtest ja quasi

einen Videoschnipsel, den du irgendwo liegen hast,

ergänzen

und da filtern oder Sachen

drauf

spiegeln oder

also neue Dinge erschaffen mit einem Schnipsel,

den du schon hast. Und da ist auch quasi die

Zeit, die das braucht, um zu

rendern und Dinge dazu zu erfinden,

relativ

dehnbar.

Ja, aber die Ressourcen sind ja nicht endlos dehnbar.

Sprich, wir haben zum Beispiel so eine Faustregel,

dass für uns ein Frame nicht länger als eine Stunde rendern sollte.

Also ein Frame ist sowas wie ...

Wie viele Frames hat man sowas beim normalen Fernsehfilm?

Irgendwie 30 oder 60 oder sowas?

Normalerweise so 24, 25.

Natürlich gibt es da ganz tolle neue Technologien

mit 48 Frames die Sekunde.

Ich glaube, Herr der Ringe hat das

eigentlich. Aber für jede Sekunde

von diesem Film musst du halt zwei Tage

einplanen.

Ja, beziehungsweise

wir haben eine Renderfarm. Das heißt, drei Minuten

pro Jahr schaffst du dann.

Ja, es gibt da so tolle Statistiken.

Ich glaube,

ich habe mal gehört, bei den Transformer-Filmen,

da hatten sie Frames, die haben

72 Stunden gerendert.

Wow. Also

Und dann stellst du fest, ja, nee, ist kaputt.

Ja, da muss man halt dann tatsächlich an anderen Stellen skalieren.

Da muss man mehrere Parallel-Render-Inzansen haben,

weil ansonsten wirst du tatsächlich...

Du hast ja schon eine Render-Farm.

Musst du deine Render-Farm paralysieren.

Irgendwann wird es ein bisschen schwierig, klar.

Und wahrscheinlich ist es ja auch so, dass je...

Also ich meine, gut, das ist ein völlig anderer Bereich,

aber das ist halt auch beim...

Wenn man jetzt so Data-Science-Maschinen-Learning-Geschichten macht,

Da hat man auch so rechenintensive Jobs.

Also wenn man jetzt Modelle trainiert,

und zwar auch Tricks, das zu beschleunigen,

aber dann muss man halt abwarten.

Und abwarten ist auch mal ganz schlecht.

Also wenn man auf irgendwas ein paar Stunden warten muss,

dann reduziert das die Gesamtperformance enorm,

weil oft nach ein paar Stunden man sieht, das war alles Unsinn.

Man muss es halt nochmal machen.

Und die paar Stunden sind dann einfach weg.

Und wenn man lange braucht, um irgendwas zu rendern,

dann sieht man, oh Mist, meine Figur hatte die ganze Zeit die Augen zu

oder das Grinsen ist einfach schief,

dann muss man nochmal von vorn anfangen.

Ich habe keine Ahnung, ich stelle mir das so vor,

dann ist das blöd, wenn die Iterationen

zu lange sind.

Genau, also natürlich gibt es da auch wieder

Tricks und Kniffe, dass man sich so,

es gibt zum Beispiel progressives Rendering,

da

fängt der Renderer an sich schon

sehr, sehr grob an und wird dann einfach mit der Zeit

immer feiner, aber

dem Menschen ist das quasi

schon gegeben, dass du siehst, okay, ja,

wird, wird, wird, okay,

einigermaßen okay und danach, nee, hier ist das Licht

aus, alles klar, ich mach dir mal die Lampe wieder an.

Und dadurch

lassen sich Fehler auch von vornherein relativ

schnell beheben.

Das Problem ist halt nur, wenn du,

keine Ahnung, du hast deine drei, vier Sekunden,

die du da füllen musst, dann, du kannst

ja nicht jeden Frame jetzt einzeln abwarten und gucken,

ob das überall okay ist. Also

schickst es auf die Renderfarm und

musst dann halt warten

und gucken danach, ob da alles okay ist.

Das Qualitätsmanagement

ist da

auch jedem selbst überlassen.

Die Renderfarm, vielleicht kannst du noch kurz

was sagen, was eine Renderfarm ist?

Wir

haben quasi

einen Satz Rechner in unserem

Serverraum, ich glaube

sind wahrscheinlich jetzt um die 60,

die für nichts

anderes da sind, als

die schönen Bilder zu berechnen.

Sprich, wir senden denen Jobs hin

und sagen, okay, hier guck mal, hast

meine Szene.

Rechne einfach mal aus.

Und dann

gibt es so eine Renderfarm-Manager, die im

Übrigen auch alle wunderbar in Python geschrieben sind.

Gibt ein Thinkbox-Deadline.

Komplett

in Python geschrieben. Ich glaube,

nur unten an der Basis so ein paar

C-Sachen und einzelne

Programme.

Aber damit

lassen sich dann auch die Sachen komplett steuern.

Dass du sagen kannst, okay,

ich habe hier meinen Job

von 100

Frames. Bitte verteile mir

die auf meine 30 Blades

und jeder Blade bekommt

5 Frames.

Also die

einzelnen Rechner heißen Blades bei uns.

Okay, ich wollte gerade fragen, ja.

Genau. Und dann

siehst du halt dann im kleinen User-Interface

okay, mein Job muss

leider noch ein bisschen warten. Da sind noch 5 andere,

die erstmal hier meine Sachen zurecht

drücken müssen.

Und danach bin ich aber dran und dann wird das

durchgerechnet.

Das bekommt

dann nochmal so ein extra

Layer von Komplexität drauf,

wenn es dann Richtung Software-Light-Sensing geht,

weil

natürlich werden noch

Lizenzen verkauft für

die Headless-Programme,

sprich, wenn du Maya,

nee, Maya nicht, aber Houdini

im Headless-Modus rendern lassen

möchtest, dann musst du dafür aber eine

bestimmte Lizenz haben.

Davon musst du deine Render-Farm wissen und

das Rendering am Ende auch.

Es gehört aber quasi auch

zu meinem Job, das alles zu organisieren,

dass das am Ende passt.

Die IT, die kümmert sich dann im Grunde

nur noch darum, dass die Lizenzserver

aufgesetzt werden und ich bastel

dann die Programme so zusammen, dass dann am Ende

die Lizenzen auch da landen, wo sie sein sollen.

Ja, ist quasi auch Teil meines Arbeitsberufs oder Alltagslebens.

Ja, ja, ja, ne, interessant.

Und wo, also die Daten, wie werden die Daten eigentlich gespeichert?

Die landen auf einem zentralen File-Server oder habt ihr da so eine Art verteiltes Dateisystem?

Irgendwie sowas wie bei Hadoop, HDFS oder keine Ahnung?

Ne, es gibt einen zentralen Server, auf dem landen alle Daten, auf den haben eben auch alle Zugriff.

Und genau, von dem wird alles gezogen und alles hingespeichert.

Genau, ist eigentlich mit der einfachste Weg

vielleicht nicht unbedingt der sicherste,

wenn man mal Sachen verschiebt oder aus Versehen löscht oder so.

Aber das hat sich eigentlich schon sehr lange bewährt in der Industrie.

Jochen hat gerade kurz mit den Schultern gezuckt.

Also nach dem Motto, ja, passiert halt.

Nö, man kann es ja auch back-up,

wenn man es wirklich nicht verlieren will.

Es gibt auch Methoden, wie man das irgendwie sicherstellen kann.

Nee, ich überlege nur gerade,

weil ich hier zu Hause auch mal überlege,

was ich für ein Netz verlege.

Und ich bin jetzt so bei 10 Gigabit-Kabeln.

Aber tatsächlich kann ich das noch nicht wirklich nutzen,

weil die Switches sind halt irgendwie,

die haben halt Lüfter drin, die das können.

Und das ist einfach zu laut und da habe ich keine Lust drauf.

Aber das muss ja dann wirklich schnelles Netz sein.

Weißt du, womit ihr das hinbekommt?

Weil man muss ja dann, wenn man so große Datenmengen

übers Netz immer schiebt.

Das Netz ist weitestgehend mit Glasfaser überall ausgestattet.

Ich kann dir keine genauen Details nennen,

weil ich bin quasi nicht unbedingt für IT zuständig.

Ach so, nee, aber ich meine jetzt anders.

Wenn man an einem Rechner arbeitet,

dann muss da ja auch irgendwie Netz reinkommen.

das ist aber wahrscheinlich kein, also wenn man

jetzt irgendwo an einem Rechner dran sitzt, oder ist das auch,

haben die Karten mit Glasfaser hinten dran?

Ja. Achso, okay.

Gut. Ja, das geht natürlich auch.

Ich hätte jetzt eher gedacht, dass das irgendwie

Thunderbolt ist oder weiß ich nicht, irgendwie

10 Gigabit Ethernet

oder sowas, aber ja, okay. Genau, also

es ist ein Mix. Wir haben

glaube ich auch noch ein paar 10 Gigabit-Leitungen.

Das geht auch,

wenn man jetzt nicht total

alles hochfährt, aber wir hatten

schon Zeiten, wo wirklich die Renderfarm

randvoll war,

keine Ahnung, 20, 30 Leute

gleichzeitig aufs Netzwerk zu greifen

und dann beschweren sich natürlich

alle, warum ist denn alles so langsam?

Kann man im Endeffekt auch nicht so viel

machen? Es gibt natürlich noch ein paar Tricks und

Kniffe, dass die Programme zum Beispiel

die cachen sich die Dateien

einfach runter lokal

und wenn du es einmal lokal

hast, dann belastest

du natürlich das Netzwerk nicht und hast auch wesentlich

mehr Speed. So ein bisschen Peer-to-Peer

denke ich, ne?

Genau.

Das

ist eine gängige Methode. Meistens hat man

dann einfach so eine Scratch-Disk noch, die man

mit einer schnellen SSD,

die musst du natürlich alle jedes Jahr wahrscheinlich

einmal austauschen.

Aber dafür hast du eben ordentlich

Performance hintendran.

Das

ist schon sehr sinnvoll, im Endeffekt.

Ah ja, okay.

Aber dann sozusagen immer einen

File-Server, zentralen File-Server als so

Quelle der Wahrheit, was da liegt, ist dann eigentlich

das, was

sozusagen

rausgekommen ist.

Das ist schon interessant,

wie man so mit Merch-Konflikten umgeht dann an der

Stelle. Ich überlege auch

gerade, ob es da irgendwie sowas wie Git oder so

geben könnte, keine Ahnung.

Hatte ich auch alles schon mal angedacht.

Git und Git LFS

hört sich ja

das gut an, ist aber relativ

schwierig und die

Lernkurve dafür finde ich auch ziemlich hart

für jedermann.

Es gibt

aber

Unreal Engine.

Das ist auch aus der Gaming-Szene

tatsächlich. Das ist aus der Gaming-Szene,

genau. Die haben zum Beispiel eine

Git LFS-Anbindung, dass man rein theoretisch

sein Projekt komplett über Git LFS machen kann.

Macht, glaube ich, keiner.

aus genannten Gründen.

Beziehungsweise

ich kenne niemanden. Was ist denn das Problem

in dieser Learning-Kurve bei GitLFS?

Na,

man kann relativ viel

immer noch kaputt machen,

bis man quasi so in diese Arbeitsweise

reingekommen ist von, okay,

ich stage meine Sachen, dann committe ich sie,

dann pushe ich sie, okay, ich muss die aber

auch wieder runterpullen und dabei dann

eben auch aufpassen, dass

ja, meine Pre- und Post-Commit-Hooks

da alle mit Git-LFS

alles das machen, was sie sollen.

Ich glaube, schwierig wird es halt tatsächlich bei so Merch-Konflikten, weil du halt nicht

einfach den Code

nicht zusammenfügen, einfach

so und sagen, hey, die Stelle ist jetzt okay, die nicht,

sondern du kannst dich halt wahrscheinlich nur für sein Entweder-

oder unterscheiden, also entweder das Bild

vom Server oder halt mein Bild

irgendwie und das ist halt bestimmt schwierig.

Ja, ganz

genau, das

ist zusätzlich noch so.

Auch da haben aber die 3D-Programme zum Teil noch ganz gute Kniffe,

weil deren File-Formate sind meistens auf ASCII ausgelegt.

Sprich, wenn man ein bisschen findig ist, kann man die einfach selbst aufmachen

und da ein bisschen drin rumfuhrwerken und am Ende sogar seine Szene retten.

Also funktioniert manchmal, manchmal funktioniert es nicht.

Aber auch da sehr clever.

Ich überlege gerade, was halt passiert.

Also, ob

so eine Videoproduktion aus

mehreren Schichten besteht, wo es halt quasi

ein Urbild gibt, also quasi das, was eine normale

Kamera aufgenommen hat und dann die einzelnen

Effekte drübergelegt werden, einer

nach dem anderen oder ob die alle

irgendwie gemirsch werden und dann alle gleichzeitig irgendwie

ablaufen und welcher halt

dann der Layer ist,

der am nächsten an diesem Realbild dann dran ist

oder so.

Okay, gehen wir von einer normalen Produktion aus, wie wir sie gerade haben, mit echtem Footage. Sprich, du hast, keine Ahnung, Superman und hast ihn vor einem Greenscreen gedreht. Sprich, schöne grüne Leinwand und der soll jetzt erstmal schön durch den Himmel fliegen.

dann wird es wahrscheinlich der Job von dem 3D-Artist sein, dass der dir erstmal einen schönen 3D-Himmel baut.

Kann er. Noch ein paar Wolken mit rein, dass er alles schön mitmacht.

Und dann gibt es, wenn diese Layer quasi fertig sind, noch den Job des Compositors, der diese Layer zusammenfügt.

Sprich, der sieht dann zu, okay, den grünen Hintergrund, den machen wir mal weg.

Dann sehen wir noch zu, dass wir hier noch, keine Ahnung, das Cape flattert noch ein bisschen, da war noch ein Kabel dran, das geht auch noch mit da weg und ja, damit jetzt die Wolken hier auch noch so schön aussehen, muss ja eine Wolke davor und eine Wolke dahinter, dass der da schön durchfliegt.

Das ist dann eher eben dessen Job.

Und zusätzlich kommt noch dazu,

dass man dann meistens auch so farblich ein paar Sachen anpasst,

weil das, was du in 3D renderst,

ist dadurch, dass es artifiziell ist,

eigentlich sehr schwer mit Echtzeit abzugleichen.

Also was in der echten Kamera gefilmt wurde.

Ich meine, man muss sich ja nur vorstellen,

okay, ich filme das echte Leben draußen,

Und da sind ja wahnsinnig viele physikalische Sachen am Werk. Lichtbrechung, Reflektionen, Licht schimmert durch Bäume und wird absorbiert und wieder zurückgeworfen hundertmal. Und wenn wir das alles wirklich physikalisch durchrechnen würden, ja, dann würden wir auch in einem 3D-Programm auf das exakt gleiche Bild kommen, würden aber auch Ewigkeiten warten.

Sprich, man nimmt

eine Menge ab.

Absolut.

Jeder Simulationsartist,

der in den Himmel guckt und ein paar Wolken sieht,

denkt sich so, ach, ja.

Kleine Cumulus Cloud, ach,

Nächtszeit.

Genau, deswegen nimmt man eine Menge Abkürzungen

und der Compositor zieht das

dann quasi wieder zusammen und

blendet quasi die Tricks,

die da so sind, wieder zusammen.

Aber wenn ich das richtig verstehe, ist halt quasi das Einzige,

was uns daran hindert, so wirklich

so live richtig tolle Echtbilder

zu machen, so die Rechenpower, die dahinter

steckt.

Ja, im Grunde genommen schon, ja.

Ich meine, gute Software

wäre auch ganz nett dazu,

aber ja, es

ist einfach die absolute

Rechenpower, die dahinter steckt,

die man da eben braucht.

Ich meine, es gibt ja bestimmte

Programme, Unreal Engine schreibt sich

ja auch auf die Fahne, dass die da wunderbar realistisch

sind und du die tollsten Games mitmachen

kannst. Aber auch die benutzen halt

ihre eigenen Tricks und Kniffe,

dass sie halt sehr viel vorberechnen und dann

wieder benutzen. Auch die haben sich natürlich im Laufe

der Jahrzehnte jetzt schon entwickelt.

Früher war das natürlich bestimmt noch viel

aufwendiger. Gibt es da irgendwie so einen Faktor,

den man sagen kann, so ja, wenn es jetzt noch so

zehnmal schneller wäre, dann wäre es halt

irgendwie total cool oder so.

Oder wenn es jetzt noch hundertmal schneller wäre,

dann wäre es so wie in echt. Oder würdest du sagen,

ja, okay, da ist noch wirklich richtig viel zu tun?

Es entwickelt sich in sehr vielen Enden, in sehr viele verschiedene Richtungen.

Also ja, es gibt schon Möglichkeiten, wie du Sachen in Echtzeit dir anzeigen lassen kannst und so.

Es ist quasi mehr eine Art und Weise, wie du selbst arbeitest.

Kannst du damit leben, dass du gerade nur eine graue Kugel siehst?

Oder möchtest du den Fußball wirklich voll ausgeleuchtet mit allen Lichtern an und schön austexturiert?

Und genau, im Endeffekt ist es da so ein bisschen,

auf was es einen selbst darauf ankommt.

Das, was am Ende auf der Leinwand passiert,

ich meine, das ist ja dann eh fertig berechnet,

das ist ja dann eh immer flüssig und schick.

Bei Game Engines müssen natürlich noch entsprechende Leute ran,

dass das alles flüssig läuft.

Aber für die Film- und Fernsehbranche ist es ja fast irrelevant,

weil das Endprodukt wird immer gut aussehen oder sollte immer gut aussehen.

Das heißt, es geht tatsächlich darum, wie du in deinem Zwischenschritt

was für eine Visualisierung du von deiner akuten Arbeit hast,

also wie du quasi direkt eingreifen kannst

und wie gut das visualisiert ist, was du da machen willst.

Genau.

Theoretisch könntest du also immer die Pauseknopf drücken

und dann 72 Stunden rennen lassen

und dann hättest du das quasi jetzt Bild in super toll

und dann machst du halt dann da weiter.

Und dann ist es natürlich für den Zwischenschritt wieder nur,

wie du sagtest, in grauen Kugeln oder so.

Genau. Das könnte

man so machen, wie man denn willte.

Genau, und deswegen gibt es auch immer

wieder so Zwischenschritte, wo man das

macht. Animatoren zum Beispiel

machen gerne Playblasts.

Das sind wirklich nur

sehr simpel gerenderte Szenen,

wo sie quasi ihre Animationen

einmal flüssig abspielen können.

Oder einmal flüssig sehen. Nur als

Bildmaterial. Das ist dann

als, okay, du hast deinen Charakter vielleicht

als grauen Menschen,

aber es ist ja eigentlich egal,

wenn er sich an die,

keine Ahnung, ans Kinn greift,

dann, ob er nun blau oder

grün ist, ist ja nun wirklich wurscht eigentlich.

Ähm, genau.

Weil es dann die Bewegung an sich ankommt dann, ja, und die kann man

halt dann anders darstellen, da braucht man halt

den Rest nicht dazu.

Das heißt, man reduziert quasi verschiedene Dimensionen,

um sich auf das zu konzentrieren,

was man gerade modellieren möchte.

Genau.

Im Grunde genommen ist es das.

Ich meine, vielleicht

landen wir irgendwann mal in einer Welt,

wo alles sofort immer

echtzeitphysikalisch machbar ist

in allen Programmen, aber noch

sind wir nicht da. Aber ich meine,

die Rechenpower und so, die wird

doch immer besser.

Ja, klar. Ich meine, kann man sich da

nicht vielleicht auch einem der

Tricks bedienen, den

die Spiele besser aussehen lassen? Ich meine, da wird

ja jetzt inzwischen fast alles in

GPUs gerechnet. Gibt's

da eigentlich irgendwie

wird das jetzt auch beim

Rendern gemacht oder ist das alles

noch CPU oder

Es gibt schon

Hybrid-Render, die sogar beides

benutzen können, GPU und CPU.

Das

großer Ding

als immer

der Speicherplatz auf deiner Grafikkarte.

Ah, ja, ja.

Also wir haben zum Teil

Texturen, sprich,

das so wie,

keine Ahnung, wenn du eine Jacke an hast,

dann ist da eben der Jeansstoff

drauf, so wie er eben aussehen soll.

Und das sind halt auch nur Bilder.

Und die sind im Durchschnitt bei uns

4K groß, sprich

4096

mal 4096.

das

frisst dann gerne mal so

300-400 Megabyte auf deiner Grafikkarte

dann hast du von den Dingern

10 und dann ist die voll

und dann war's das

dann war's das auch wieder mit

Echtzeit

Ja, also

Neukarten, die können relativ viel von sowas machen

glaube ich

Wird auch immer besser, also ist auch wirklich

toll, was sie inzwischen damit können, aber

ja, wir haben auch massenhaft

Daten, die wir da versuchen

raufzupressen und irgendwann gibt es halt

den Cut. Okay, Grafikkarte voll.

Ich benutze wieder

die Festplatte und

trittst da erstmal

wieder schön auf die Bremse.

Ja.

Das Interessante ist auch,

irgendwer hat das mal gesagt,

die 3D-Branche

ist schon

peinlich

parallelisierbar.

Sprich, wenn man so eine 3D-Szene

hat, die ist so in sich abgeschlossen,

dass man die unheimlich gut

multithreaten und parallelisieren kann.

Weil

es ist ja quasi alles bekannt, es ist

alles da, es ist alles eingestellt, also

du kannst

jedem Core quasi sagen, okay, du fängst

da an, du fängst da an.

Ja, von der Zeit her

kann ich mir vorstellen, dass das sehr gut möglich ist.

In ein Bild zerlegen stelle ich mir

schwer vor, wenn irgendwo eine Lampe über das ganze

Bild leuchtet, dann

muss, dann hängen

die ja die Sachen voneinander ab, ne? Aber

ja, man kann

natürlich in der Zeit super, kann man

splitten, ja.

Sprich, die Renderer gehen natürlich auch

voll auf Chors ab, also

wenn du da einen Threadripper drin hast,

das merkst du definitiv.

Ah.

Ja.

Auch sehr spannend, ja.

Ja, ja, und wenn man dann halt eben beliebig viele

Rechner hat, dann ist das auch im Grunde

ja nicht so schlimm, wenn das

TPU, muss man halt einfach nur mehr Rechner nehmen.

Das ist horizontal skaliert.

Ich finde es auch spannend an der Stelle, dass

Python da auch wieder reinkommt, weil Python an sich ist ja

verschrien langsam als Skriptsprache.

Aber das ist unheimlich egal an dieser Stelle.

Weil was ich an der Sache mache, ist quasi

einfach, okay, die Leute kriegen ihre Daten an der richtigen Stelle und ob das jetzt

hundertmal schneller oder tausendmal

schneller funktioniert, ist vollkommen

egal.

Das ist

so ein wunderbarer Use Case

von, okay,

du musst die richtige Sprache benutzen

für den richtigen

Anwendungsfall.

Ich kann das alle, ich kann nicht, aber

man könnte das alles in C ausprogrammieren,

wer so wahnsinnig ist,

dann wäre es auch wahnsinnig schnell, aber es macht keinen

Unterschied.

Ne, klar. Also manchmal ist die

Geschwindigkeit, mit der man irgendetwas hinschreiben kann,

halt die viel wichtigere.

Ja, wenn Dinge halt nicht so oft

ausgeführt werden.

Ja, aber ich meine,

spielt das eigentlich bei euch irgendeine Rolle?

Man könnte ja auch Dinge dann in Python schnell machen.

Also eben im Bereich

Machine Learning und so, da wird ja auch

tatsächlich viel selbst in Python gemacht.

Und ich weiß jetzt nicht, wie es mit Bilddaten aussieht

und so, aber man könnte da ja auch,

indem man das Ganze zum Beispiel

die Bilder irgendwie in NumPy Arrays

hat oder so und dann darauf

irgendwelche Transformationen machen oder so, es müsste

dann eigentlich auch schnell sein. Oder

dass man halt irgendwie, keine Ahnung,

per

Seiten halt irgendwie

Python-Code in

oder zumindest die heißen inneren

Schleifen

und Funktionen halt sozusagen in

C zuerst übersetzt

und dann wieder als C-Modul wieder einbindet.

Denn damit könnte man es ja auch sehr schnell machen.

Wird das irgendwie verwendet oder ist das

da, wenn, ich meine, solange Python halt

zum Steuern verwendet wird, ist es ja egal

im Grunde, da brauchst du das alles nicht.

Es wird jetzt immer interessanter

mit dem Machine Learning, weil

es gibt so gewisse Schritte

in der 2D und 3D Bearbeitung,

die halt unheimlich nervig und

langweilig sind. So das beste

Beispiel ist Sachen ausschneiden.

Sprich, okay, Mann geht von A nach B,

schneid den mal aus.

Und das lässt

sich unheimlich, was halt,

Also unheimlich gut noch nicht, aber es lässt sich langsam machen mit Machine Learning.

Wir hatten da auch schon erste Ansätze, allerdings muss man da auch schon noch durch ganz schön viele Hoops springen,

bis man da ankommt, wo man hin will.

Aber so automatisiert Sachen ausschneiden, das wird echt unsere Branche nochmal ganz gut aufmischen.

Genau, im Moment hapert es noch an so der Größe der Bilder zum Beispiel.

Die meisten gehen da so auf 512x512 Pixel, verständlicherweise.

Ja gut, wenn du jetzt so ein 4K-Bild hast, dann musst du das erstmal zerlegen in, keine Ahnung, 8-12 Bilder oder so,

die du dann einzeln da durchjagst, dann hast du im Endeffekt auch nicht mehr so viel gewonnen,

weil das, was am Ende rauskommt, ist auch

naja, sagen wir mal

80% da, wo es eigentlich sein sollte.

Und man kommt dann noch an so andere Probleme,

wie zum Beispiel

ein Mann geht durchs Bild.

Ja, okay, den Mann kannst du ausschneiden.

Okay, jetzt hat der Mann aber auf einmal einen Hut auf.

Dafür ist jetzt das Machine Learning

Modell aber nicht trainiert.

Das ist nur auf Menschen ohne Hüte.

Gibt es nur in den Trainingsarten,

in den Trainingsarten waren keine Hüte drin.

Tja, das ist doof.

Okay, jetzt darfst du es erst noch

trainieren auf Hüte.

Das ist ja jetzt auch irgendwie schwierig.

Ja.

Aber ja, da gibt's auch

jetzt erste Fortschritte.

Es wird

auch noch sehr interessant

für zum Beispiel

so, keine Ahnung,

wenn du Sachen verschönern willst,

keine Ahnung, der

Tom Cruise hat einen Pickel auf der Stirn oder so

und bewegt sich durchs Bild.

Oh, und jetzt muss das aus jedem Bild raus

retuschiert werden.

Genau.

Da ist Machine Learning aber auch schon

ganz gut am Start und die

Ergebnisse sind

eigentlich sehr, sehr gut, muss man

sagen. Da

hätte vorher dann halt ein Artist

irgendwie eine Woche dran gesessen

und wenn das ein Rechner in einer Stunde

kann, dann ist das definitiv

cool.

Ja, witzig. Ja, klar.

da gibt es natürlich auch jede Menge Anwendungen dafür.

Ja.

Ja, oder da gibt es etwas, was ich

ab und zu sehe ich mal so Demos,

ich habe aber keine Ahnung, inwiefern das schon

soweit ist, dass man das benutzen

kann, dass man halt sagt, okay,

also alles, was so in die Richtung Style

kann, also diese

Generative Adversarial Networks

geht, dass man sagt, okay, man hat jetzt hier ein Bild

von, weiß ich nicht, irgendeiner Kirche oder so und das hätte

man jetzt gerne in einem anderen Stil und dann

muddelt es das Ding halt irgendwie um oder man hätte

jetzt gerne irgendwie da einen Baum

davor oder solche Sachen.

Ja, das wird dann auch sehr spannend.

Aber ist wahrscheinlich jetzt noch nicht wirklich verwendbar.

Ich stelle mir solche Dinge vor, du beschreibst eine Szene in

Worten. Ja, das gibt es auch.

Und es generiert dir dann tatsächlich

daraus dein Gedankenuniversum

oder sowas. Du könntest zum Beispiel

schreiben, ich hätte gerne eine Kirche mit so und so

vielen Fenstern und einem langen Gang und 15

reinen Bänken. Ja?

Ja, genau, das gab es schon.

So à la Holodeck,

dass du eben dann wirklich nur,

ich weiß ja nicht mehr, wie das Programm hieß,

Aber es war wirklich so, okay, ich habe einen Tisch, da sind vier Stühle dran, da sind noch eine Serialenschlüssel obendrauf.

Das wird dir dann mega, mega, mega krass interessant.

Also wenn du das dann hinbekommst mit sowas wie der Unreal Engine und dann halt das augmentiert, eine virtuelle Realität auf irgendeine Brille projizieren kannst,

die das in, weiß ich nicht, pro Auge 8K darstellt und in, bitte nicht 24, sondern in 60 FPS oder sowas dann in live.

Und dann kannst du dir deine eigene Realität

zusammenreden, weil die KI, mit der du

redest, das in mehr oder weniger

Echtzeit dann als Darstellung

bauen kann. Wow.

Ja gut, die baut das dann halt so, wie sie das

von ihren Trainingssorten her kennen, so wie du dir das

vorstellst. Ja, aber das kann man ja

dann anklären. Das ist ja dann der Trick,

dass man halt dann irgendwie selber

ein bisschen modifiziert und dann Streams baut.

Ich habe gerade noch mal geguckt, wo das herkommt.

Es gibt es von OpenAI,

gibt es so ein Ding, das nennt sich

Dolly

oder Doll-E.

Das ist auch von dem Namen her

angelehnt an Wall-E.

An diesen

Pixar-Film.

Und das macht halt eben Text zu Bildern

und so. Und das ist auch sehr, also

die Demos hier sehen super aus, aber das Problem

ist natürlich, die sind auch dann so ausgewählt,

dass das halt natürlich nicht gut funktioniert.

Genau, das Ding halt dann zu bauen, diese Komplexität

in diesen 3D-Modellen, die halt mehr sind

als irgendwie nur zwei Bilder, sondern die halt dann

tatsächlich eine ganze Szenerie mit den ganzen physikalischen

Eigenheiten dieser Rigs und

die da drin stecken und ich weiß nicht,

was da noch, also du hast jetzt gesagt, also okay, ich habe

jetzt ein 3D-Modell, das ist ja so das erste,

dann ist das mit einem Rig gefüllt und dann

wird das irgendwie texturiert

und beleuchtet irgendwie,

ja, und dann

irgendwie platziert in anderen,

mit anderen Objekten in Interaktion gesetzt

und sowas, also das sind ja schon irgendwie so

mehrere

Komplexitätsschichten übereinander, die alle für sich

schon schwierig

genug sind, ja, also um darüber nachzudenken

und also in der Realität zu platzieren, wenn ich jetzt

irgendwie die Realität mir anschaue und isolieren

möchte, dann bin ich da ja alleine

schon sehr gut beschäftigt, glaube ich.

Ja, genau.

Es nimmt halt

sehr stark, starke

Komplexität an. Je mehr du

dahin zufügst, desto

ja, mehr muss man

halt hinterher sein, das alles ordentlich aufzusplitten

und... Aber wenn das halt geht und das alles mit

Python ist, finde ich natürlich sehr cool.

Dass das wirklich möglich ist,

also sowas mit... Also es

weiß ich gar nicht, ist diese

Renderer, den es da gibt, von der

Engine ist der auch, also

von der Unreal Engine auch Python

getrieben?

Ne, also dieser Renderer

von Unreal Engine, das ist wirklich

interner C-Code, der

das da betreibt.

Unreal Engine lässt sich aber auch inzwischen

mit Python auch steuern. Also es gibt

halt tatsächlich so einen Rapper oder sowas, der halt sagt,

okay. Genau. Ich glaube auch mit Lua übrigens.

Also falls

da Ambitionen sind.

Aber Game-Engines

müssen einfach auf C-Code eigentlich

gehen, weil

das ist einfach viel zu langsam,

was du mit Python da erreichen könntest.

Das würde niemals

60 FPS

erreichen.

Also kann ich mir nicht vorstellen.

Ich meine, es gibt natürlich so Sachen wie

PyGame zum Beispiel,

mit dem man sich so sein eigenes kleines Python-Game

zusammenschreiben kann.

Ich weiß aber nicht, wie

Finder-3D-Grafik

mit drin ist.

Na, nee, das ist...

Da müsste man jetzt den Herrn Spielmann fragen, der

da ein bisschen tiefer drin ist mit seinem Steam.

Aber, ja,

es ist aber trotzdem sehr spannend, also was man damit

halt machen kann, wenn du sagst, halt, das Unreal Engine

dafür, dass man C braucht.

Was ist denn das, was die Geschwindigkeit dann

gibt? Ist das das Rechnen mit irrationalen Zahlen?

Nee, nee, nee, also

das, was Python... Also ich kann zum Beispiel

sagen, was Python langsam macht. Also Dinge, die

in Python sehr langsam sind, im Vergleich zum Beispiel

Also C ist halt sowas wie ein Funktionsaufruf

oder halt ein Methodenaufruf.

Weil ich einfach Reference-Counting machen muss, oder warum?

Nee, deswegen, weil das halt, das ist

halt richtig langsam, weil das ist halt nicht

einfach nur, irgendwie in

C, wenn das dann halt kopiert ist, das ist halt

irgendwie... Ein SM der Anweisung, springe nach.

Ja, so, genau, und dann,

ja, das ist halt in Python nicht so, da ist halt,

da passiert halt ganz, ganz viel. Der ganze Overhead,

der halt nicht steckt, also den ganzen Name spät mit

fressen muss. Ungefähr halt tausendmal so langsam.

Ja, also wenn du in C einen Funktionsaufruf

machst und machst in Python ein, dann ist ja in Python

halt so, als würdest du das in C tausendmal machen.

Also weil ich tatsächlich irgendwie diesen ganzen

Wraparound machen muss, weil ich die ganzen

Namespaces mitfressen muss, weil ich die ganzen

Variablen mitessen muss, weil ich die ganze Syntaktik

Schoko mitessen muss, oder warum?

Deswegen, weil das nicht ein Funktionsaufruf

wie in C ist, sondern das ist halt

was viel, viel komplizierteres in Python.

Weil das halt auch was viel dynamischeres ist.

Weil das halt

eine interpretierte Sprache ist. Das ist halt

nicht einfach nur das.

Also das ist halt einfach was anderes.

Und das wirst du auch nicht los.

Aber die Frage ist halt, ob du das machen musst unbedingt.

Du kannst natürlich auch einfach...

Wenn ich tausendmal schnell einen Rechner hätte, wäre das zum Beispiel schon mal zu mich egal.

Ja, gut.

Aber den Unterschied wirst du immer merken.

Aber wenn du jetzt irgendwas ausrechnest oder so,

da ist es eigentlich im Grunde nicht mehr...

Da hast du diesen Unterschied halt nicht.

Also wenn ich in NumPy, weiß ich nicht,

zum Beispiel eben zwei Matrizen multipliziere oder so,

das wird schwer, das in C genauso schnell hinzukriegen.

Und das ist in Python ja auch einfach hingeschrieben.

Da schreibst du halt dann A at B oder sowas,

wenn du A mit B multiplizierst.

Es ist halt sehr schön, einfach das hinzuschreiben

und es ist halt trotzdem schneller, als wenn du es in C machen würdest.

Außer du machst es halt wirklich, ja, aber dann,

also in C ist es halt deutlich schwerer hinzuschreiben,

weil da musst du halt dann gucken,

dass das halt...

Ja, du musst die ganze Implementierung selber bauen, muss dann auch so gut sein,

dass du halt die Implementierung so super

selbst baust, wie das halt...

Du musst halt dann auch dem Compiler sagen, jetzt hier bitte

ich weiß, was ich tue, benutze

die SIMD-Instructions und

ja,

wenn ich jetzt hier

eine Vorschleife hinschreibe, dann meine ich nicht

wirklich eine Vorschleife, das darf auch,

die Reihenfolge darf sich auch ändern und

keine Ahnung und wenn du das alles machst, dann

ist es vielleicht genauso schnell.

Aber

insofern, also für manche Sachen

ist es in Python überhaupt nicht schwer, genauso schnell

zu sein. Für andere Sachen ist es

halt, ja, ist es halt schwer.

Wobei man

da eigentlich dann auch mal

insofern drum rumkommt, als man

dann sagen kann, okay, entweder man nimmt halt so was

wie so ein Just-in-Time-Compiler, so

ein Number oder man nimmt halt

ähm

man nimmt halt

ein Subset von Python, halt

zum Beispiel so was wie Cytan, kompiliert das

nach C und dann

in ein C-Modul

und dann kopiert man das C-Modul und importiert es

wieder zurück. Und dann ist es halt

auch schnell. Also es gibt da schon

Möglichkeiten, das hinzukriegen. Die Frage ist,

naja gut, wenn man jetzt so eine Engine hat,

die irgendwie... Ja, du würdest eigentlich

das machen wie Game Engine.

Also ich glaube schon, dass man eine

Game Engine in Python schracken könnte. Das geht schon.

Die Frage ist...

Ja...

Hm, ich weiß nicht, ob das jemand schon mal

gemacht hat. Ja, wahrscheinlich nicht. Also das ist

halt immer auch der größte

Flaw, den Python

immer so hat, wenn man die Leute unterhält, dass das halt für 3D-Sachen

bis jetzt nicht so gut geeignet

gewesen ist. Weiß ich gar nicht.

Oder was meinst du mit 3D-Sachen? Ja, weil es

halt diese Bibliotheken dafür einfach nicht gibt.

Also wenn ich jetzt in C oder C++ irgendwelche

Frameworks habe, die ja vorher schon

prädestiniert sind

und dass es in Python einfach nicht den einfachen

Rapper gibt, den man so gewohnt ist, wenn man das in der

Hand hat, sondern dass es einfach viel, viel länger dauert,

wenn man das anders macht.

Also für mich wäre die Frage halt, was du genau meinst mit

was da gemacht werden soll.

Weil, wie gesagt...

Vielleicht möchte ich tatsächlich sowas haben wie eine Figur, die animiert

wird. Ja, wenn die jetzt im Raum drehen soll

oder so. Live Bilder sehen.

Genau. Ja, denke ich, kannst

du in Python wahrscheinlich ganz genau so schnell

machen wie... Oder ich würde sagen, wenn

die Zeit, die du brauchst, um das

hinzuschreiben, da bist du in Python wahrscheinlich

deutlich schneller

und bist halt wahrscheinlich auch

vom Code her schneller. Ja, aber das ist doch eine

Ne, ich glaube, ich weiß es nicht.

Mein Eindruck ist immer, es ist irgendwie

relativ schwierig, mit Python

irgendwie zur Grafikkarte zu kommen.

Das ist irgendwie so.

Also, ja, es gibt

Anbindungen so für PyOpenGL

oder sowas.

Geht bestimmt, aber

ich weiß nicht, so direkt

die Grafikkarte anzusprechen, fällt mir

jetzt persönlich nichts ein, wo man

sagen könnte, okay, das ist

dass man

sich da eine Bibliothek reinholt, wo man

denkt, okay. Ja, ich kenne es halt nur aus dem

Machine Learning Bereich, da gibt es halt

CUDA, das ist halt diese Bibliothek

oder die

von Nvidia

und damit geht das, aber ich meine,

normalerweise gibt man damit halt keine Bilder aus, sondern man

berechnet halt irgendwie

keine Ahnung, eben sowas wie Matrizenmultiplikation

oder so.

Ja, aber da geht das,

aber ja, es stimmt schon, es ist ätzend.

Man muss halt diese ganzen Bibliotheken

installieren. Vielleicht muss das jemand mal neu bauen.

Das kannst du leider.

Das ist leider nicht so einfach.

Ja, das ist auch das Problem.

Zum Beispiel auch für diese ganzen Machine Learning-Geschichten

kann man nur NVIDIA-Chips verwenden,

weil es gibt nur für NVIDIA diese Bibliotheken.

Und ich glaube,

die AMD-Chips sind halt auch ähnlich

leistungsfähig im Grunde,

aber kann man einfach nicht verwenden, weil es gibt diese Bibliotheken

nicht dafür.

Und das ist ja jetzt auch schon

Jahre sind Leute dabei, das zu versuchen

und es klappt halt nicht. Daher, ich

fürchte, das ist nicht so ganz einfach.

Es gibt dann so ein bisschen

äh, es gibt

von Intel, gibt es das irgendwie

äh,

PlateML

oder so, womit man dann auch irgendwie

das auf anderen, also

ich weiß nicht genau, also es funktioniert aber eigentlich alles

letztlich nicht wirklich. Da braucht man halt

diese Unterstützung dafür

und das gibt es halt nur für Nvidia eigentlich

in richtig gut. Und es ist

total hakelig, das zu installieren immer.

Und wenn man halt nicht aufpasst, ist es halt langsam

hinterher. Also es ist

ziemlich fies.

Also man hat da nicht wirklich Lust drauf?

Aufgrund, warum man

dann Sprachen wechselt?

Naja,

für Machine Learning gibt es ja auch keine Alternative.

Welche Sprache willst du da wechseln?

Da gibt es ja auch nichts anderes.

Nee.

Es gibt wirklich nichts anderes.

Ja, du kannst halt

C++ verwenden, aber

Yay!

Wie ist denn das?

Ja, aber wenn es um die

Ausgabe geht, ja, nee, keine Ahnung. Also ich habe

ehrlich gesagt auch, also Pygame

gibt es, ja.

Nee, ich weiß nicht, ob es da irgendwas gibt.

Aber ich denke mal,

im Grunde müsste man das machen können. Kann man eine Grafikkarte

nicht einfach irgendwas in den Hauptspeicher legen,

in den Grafikkartenspeicher legen und dann sagen,

zeig das mal an oder so, das müsste doch eigentlich gehen.

Das müssen wir ausprobieren.

Aha.

Keine Ahnung.

Viel Spaß.

Mach mal deine Grafikkarte kaputt und erzähl uns davon.

Ja.

Kann man die Grafikkarte mit sowas kaputt kriegen?

Also wenn man sie zu heiß kriegt oder sowas?

Ja.

Ja.

Mach es probieren.

Ja.

Ja, ja, ja, ja. Interessant.

Ja, aber was wäre das denn,

wenn du dir was wünschen könntest,

weiß ich nicht, was dein Leben irgendwie

einfacher machen würde,

jetzt sozusagen in

diesem

Anwendungsfall

für Python. Was ist

das, was dir da am meisten Schmerzen macht,

oder wo man am einfachsten

irgendwas verbessern könnte?

Grundsätzlich

Python 3.

Okay, das ist ja fast schon traurig.

Ja.

Ja, also

ich freue mich schon auf Pfeifen 3.10 und denke mir so,

ey, alles, was danach oder davor war,

das will ich nicht mehr benutzen. Und das ist halt erst

irgendwann, dann kommt das raus im August.

Ja, ihr glaubt gar nicht, wie sehr ich mich auf

F-Strings freue.

Ich glaube, mein Code hat immer noch nicht ein.

Also das

ist schon echt langsam haarig.

Was noch?

Was würde mich noch freuen?

Es gibt schon Ansätze, dass die ganze Industrie sich quasi standardisiert auf gewisse Bibliotheken, die dann auch nach und nach geupdatet werden, sprich, dass man sich alle einigen auf eine bestimmte Compiler-Version, bestimmte Python-Version, bestimmte andere Bibliotheken.

Und wenn sich da alle dran halten würden, das wäre super, dass man nicht so die ganze Zeit zwischen diesen Inkompatibilitäten hin und her joggen würde.

Ja, du hast gesagt, man kann nicht einfach irgendwie ein Pie-Inf installieren

und dann irgendwie seine Version pinnen,

sondern muss halt irgendwie mit den Restriktionen

jedes einzelnen Programms,

der Compiler des jeden einzelnen Programms

da arbeiten und

dann seine Skripte quasi immer

da

downgraden oder sowas, wenn man dann irgendwie auf so ein

altes Python stößt. Das hätte ich mir furchtbar vor.

Ich weiß nicht, ob ich Lust hätte, in Python 2 irgendwas zu machen.

Ja, also

nur um noch mal

so einen kleinen Ausflug zu machen.

Es war eigentlich bis jetzt immer in Maya so,

dass

dadurch, dass Python eingebettet war,

musste Python den Kompilierer benutzen,

den Maya benutzt.

Das ist aber nicht der Standard-C-Kompilierer,

den Python normalerweise benutzt, sondern

eine ältere Version.

Sprich, alle PIP-Module, die eine DLL in sich hatten, wie NumPy oder so,

haben erst mal auf Anhieb nicht funktioniert in Maya,

weil die Compiler einfach nicht miteinander kompatibel waren.

Das heißt, wenn du NumPy benutzen willst, musst du es dir erst mal mit dem anderen Compiler durchkompilieren,

bevor du es dann in Maya benutzen kannst.

Ja, okay, anstrengend.

Absolut, ja.

Und ich würde mir auch wünschen, dass die Branche mal so ein bisschen auf Python-Standards umsteigen würde, wie Pip und PyEnv und alles andere.

Weil wir sind quasi noch sehr, dadurch, dass die Python-Interpreter eingebettet sind, sehr angewiesen auf die Programme selbst.

Also wir machen sehr viel mit Environment-Variablen zum Beispiel.

typischerweise so Python-Path.

Habt ihr vielleicht schon mal gehört.

Wenn man das vorher setzt, dann

findet halt der Interpreter in den entsprechenden

Pfaden dann die Module.

Aber

ja, wir müssen uns die halt selbst

zusammenklauben und selbst dann so ein bisschen

unsere

Hard reinhacken, alles injecten und dann

läuft es. Genau. Aber habt ihr das mal

probiert? Ich meine,

ich stelle mir dann vor, genau, das Problem ist sozusagen,

dass

deine, eben sowas

wie NumPy oder so ein Paket installiert hast,

das muss halt kompatibel sein zu dem

Python-Interpreter,

der in der Software drinsteckt,