Vollständiges Transkript

Dave: Hallo, hier ist Dave Baszucki, ich bin Gründer und CEO von Roblox, und ihr hört oder seht gerade „Tech Talks“. Heute sprechen wir darüber, was eine Spiel-Engine der zweiten Generation ausmacht, wie die Cloud dabei eine Rolle spielt und wie wir Nutzern helfen, sofort und in hoher Auflösung beizutreten. Wir haben hier das technische Dreamteam von Roblox versammelt.

Wir haben also Varun Mani, Sergey Makeev und Tsvetan Tsvetanov dabei, und wir werden uns intensiv mit allem rund ums Streaming beschäftigen. Ähm, wir werden über „Slim“ sprechen, wir sprechen über die Transkodierung von Assets – alles, was Roblox letztendlich in die Lage versetzt, hunderttausend Spieler zu unterstützen. Wenn wir uns die Gaming-Branche der letzten 10 oder 20 Jahre ansehen.

gibt es eine traditionelle Art und Weise, wie all diese 3D-Inhalte vor euch erscheinen, und, ähm, äh, und es gibt einige Probleme mit dieser traditionellen Methode. Denn was wir bei Roblox versuchen, ist, sofort einzusteigen. Äh, wir versuchen, die gleichen Erlebnisse sowohl auf einem Smartphone als auch auf einem riesigen PC laufen zu lassen. Äh, wir versuchen, das ohne jegliche Latenz zu erreichen, und wenn wir uns ansehen, wie traditionelle Spiele funktionieren, ist das nicht ganz dasselbe, oder?

Ich kann mich noch daran erinnern, dass sie zu meiner Zeit auf diesen sogenannten Disketten vertrieben wurden. Aber selbst heute vertreiben wir Spiele noch auf großen DVDs, glaube ich. Kann man das so sagen? 

Varun: Ja. Und ich denke, der Schlüssel dazu ist, dass alles zusammen verpackt ist. Ja. Richtig? Ob es nun eine DVD ist oder ob man heute ein Spiel herunterlädt – es kommt als ein riesiges Paket, das man nicht aufteilen kann.

Man muss also warten, bis die gesamten 4,7 Gigabyte oder in manchen Fällen sogar 10 Gigabyte vollständig heruntergeladen sind, bevor man loslegen kann. 

Sergey: Ja. Und wie Varun schon sagte, bei manchen Spielen sind das vielleicht 20 oder 40 Gigabyte, und man muss sehr lange warten, bevor man anfangen kann zu spielen. Und das zerstört irgendwie den Spielfluss, oder?

Also, weil man spielen will, hat man vielleicht ein oder zwei Stunden Zeit nach der Arbeit, man will ein Spiel spielen und muss dann 30 oder 40 Minuten warten, während es aktualisiert wird und so. Das entspricht ziemlich genau meiner Erfahrung damit. 

Dave: Ist das nicht irgendwie ähnlich wie das, was wir bei Videos und Filmen gesehen haben?

Ich kann mich an eine Zeit erinnern, als Filme auf DVDs vertrieben wurden, und dann an eine Zeit mit BitTorrent zum Beispiel. Man hat das Ganze heruntergeladen, und schließlich sind wir bei dem Punkt angelangt, wo ich zu Amazon, Netflix, Hulu oder Tubi gehe und es sofort anschauen kann. Aber ich glaube nicht, dass das im Gaming-Markt schon ganz so weit ist.

Noch nicht. Noch nicht. Ich glaube, noch nicht. 

Tsvetan: Wir sind die Einzigen, die genau darauf abzielen 

Dave: das anstreben. Also, historisch gesehen hat Roblox so funktioniert, hinter den Kulissen, ähm. Die meisten Leute bemerken das vielleicht nicht, aber wenn man auf die Startseite von Roblox geht und auf „Spielen“ klickt, kann man sofort einsteigen. Das ist eigentlich sehr unkonventionell, denn wenn ich auf einigen sehr eleganten, ähm, Gaming-Plattformen bin, habe ich schon erlebt, dass bis zu 200 Gigabyte heruntergeladen werden mussten, bevor ich spielen konnte.

Also, also machen wir das mit dem Sofortspielen bereits? Ja. 

Tsvetan: Ähm, Roblox ist, soweit ich weiß, die einzige Plattform, die dieses sofortige Beitreten und Spielen ermöglicht. Oh ja, 

Varun: Ja, entschuldige. Und das ist so ähnlich wie bei dem Videostreaming, von dem du gesprochen hast, oder? Was machst du eigentlich, wenn du einen Videostreaming-Dienst nutzt, bei dem ich nicht den ganzen Film herunterladen will, sondern nur so viel, wie gerade vor mir läuft – das nennen wir Puffern.

Ich streame den Film. Richtig? Das stimmt, aber das ist nur in einer Dimension. Denn dort gibt es nur eine Zeitdimension. Ja, das ist hier der entscheidende Unterschied. Das ist das Schwierige daran, es in Roblox zu machen, denn es ist eine vollständig interaktive 3D-Welt, in der man sowohl Instanzen als auch Assets streamen muss, was sozusagen die Grundbausteine von allem in 

Dave: Roblox A a und äh, ich würde sagen, das hat es noch schwieriger gemacht, denn auf dem traditionellen Videospielmarkt

sehe ich oft verschiedene Versionen von Spielen, zum Beispiel auf einem High-End-PC und einem Low-End-Mobilgerät. Und wie ich das interpretiere: Auf High-End-PCs, wo man Hunderte von Gigabyte herunterladen kann, gibt es diese wirklich großen, komplexen Assets, und auf Mobilgeräten ist es fast so, als würden die Entwickler, glaube ich, eine separate Version erstellen 

Sergey: in gewisser Weise.

Äh, ja. Das ist ein sehr guter Punkt, denn bei traditionellen Spielen gibt es diesen Prozess, der „Asset Cooking“ genannt wird. Da erstellen sie also eine sehr optimierte Version, etwa der Texturen, für jede Plattform. Und wenn man das aus einer eher videostreamingorientierten Perspektive betrachtet, dann ist es wie bei einer DVD.

Äh, das Video wurde nur einmal encodiert, oder? Ja. Aber auf jeder Streaming-Plattform gibt es mehrere Encodierungen für dasselbe Video, sodass es sich automatisch an dein Gerät anpasst. Und, äh, bei allen aktuellen Spielen werden die Assets sozusagen vorab vorbereitet und sehr spezifisch ausgeliefert, während es hier dreifach ist.

So können wir in der Cloud eine optimierte Version eines Assets pro Plattform generieren. Genau. 

Dave: Behalte das mal im Hinterkopf, okay? Denn vor einiger Zeit hatten wir die Vision: Wenn du ein junger Entwickler bist und deine Erfahrung erschaffst, kann sie in jeder Sprache laufen. Wir hatten die Vision, dass sie auf jedem Gerät und in verschiedenen Auflösungen auf jedem Gerät laufen kann.

Wir werden, wir werden uns damit befassen. Also, also, also der traditionelle Gaming-Markt, weißt du, als Paket oder als Download. Ähm, wir wollen diese Probleme lösen: sofortiger Zugriff, veröffentlicht für jedes Gerät, geringe Latenz und all das zusammen. Und deshalb werden wir heute über etwas sprechen, das buchstäblich 3D- und 40-Streaming heißt.

Wir werden über, ähm, Inhalte in der Cloud sprechen. Wir werden über etwas sprechen, das sich „Slim“ nennt, worüber sich meiner Meinung nach alle sehr freuen werden. Und also, ähm, um einzusteigen, Varun, zuerst eine kleine Vorstellung davon, was „Slim“ ist und was. Ähm, wir nennen es „Cloud Transco“. Ja. Und was bedeutet das alles? 

Varun: Also, wenn wir mal einen Schritt zurücktreten: Wenn man über unsere Gesamtvision nachdenkt, versuchen wir, 10 % des Gaming-Marktes zu erreichen.

Ja. Das erreichen wir, indem wir den Entwicklern völlige Freiheit bei dem geben, was sie erschaffen. Ähm, und wenn man darüber nachdenkt, wie wir wachsen, gibt es sozusagen zwei Dimensionen. Man kann entweder eine Plattformerweiterung vornehmen oder eine Genreerweiterung. Bei der Plattformerweiterung geht es darum, wie wir denselben Inhalt auf jeder Plattform zum Laufen bringen.

Man erstellt also etwas einmal. Roblox sorgt dafür, dass es überall funktioniert. Und bei der Genre-Erweiterung: Wir wollen, dass ihr immer beeindruckendere und immer verrücktere Dinge erschafft. 

Dave: Und wenn du sagst „überall laufen“, dann stell dir buchstäblich etwas wirklich Großes, Verrücktes und Unterhaltsames vor. Grand Theft Auto, Red Dead Redemption, High-End-Konsolen.

Läuft auf einem Android-Handy mit zwei Gigabyte und allem dazwischen. Genau. Von 

Varun: Vom PC bis hinunter zu einem 2-GB-Android-Gerät sollte es einfach funktionieren, ohne dass der Entwickler zusätzliche Arbeit investieren muss. Das ist also die Vision. Genau. Cloud, Transcoding und Slim sind nur zwei der ersten Schritte, die wir auf diesem Weg unternommen haben.

Dave: Okay, das ist also ein kleiner Vorgeschmack. Wir werden erklären, was Slim ist, und wir werden erklären – ich denke, du wirst wahrscheinlich erklären, was Transcoding ist –, aber lasst uns erst einmal alle vorstellen. Also, Sergey, ähm, du bist wieder da, kannst du uns ein wenig über deinen Hintergrund in der Engine-Optimierung erzählen? Eine der spannendsten Sachen der Welt, oder?

C++, Assemblersprache wie CmD – kannst du uns ein bisschen darüber erzählen, woran du gearbeitet hast? 

Sergey: Äh, ja, also, wie du schon erwähnt hast, ja, ich habe so ziemlich mein ganzes Leben lang an Spielen gearbeitet und mich um die Optimierung gekümmert, angefangen bei der regionalen Xbox und so weiter.

Äh, und. Weißt du, als ich zum ersten Mal von Roblox hörte, hat mich das total umgehauen – diese Idee, dass ein Spiel nur einmal erstellt wird oder, äh, nicht einmal ein Spiel. Vielleicht eher eine Erfahrung, die nur einmal erstellt wird, und dann überall läuft, auf jeder Plattform, auf jedem Gerät, ohne dass zusätzliche Benutzereingaben nötig sind.

Und das ist das extrem anspruchsvolle technische Problem. Äh, wie, äh, wie sich wohl jeder vorstellen kann, oder? Also, äh, und das erfordert eine Menge, äh, weißt du, traditioneller Optimierungen, wie CMD, Multi-Threading, sehr sorgfältige GPU-Planung, all das. Aber gleichzeitig gibt es da, weißt du, gewisse Grenzen, äh, wie weit wir auf einem einzelnen Gerät skalieren können.

Zum Glück haben wir ja immer unsere Cloud, oder? Also können wir einen Teil dieser Arbeit in unsere Cloud hochladen und diesen Geräten helfen, größere Wände effizienter zu rendern. Bis zu einem gewissen Grad, weißt du, wenn wir zum Beispiel Wände rendern können, die nicht einmal in den physischen Speicher eines Geräts passen, weil sie ja auch auf der Serverseite existieren und der Server allen Clients hilft, sie effizient zu rendern.

Dave: Ja. Und nur als Highlight: Ich denke, ein Teil des Hinweises, den wir dazu geben werden, ist, dass traditionelle Spiel-Engines typischerweise in C++ geschrieben sind und man alle Assets herunterlädt. Aber nehmen wir an, ein Spiel, das man spielen möchte, wäre die ganze Welt – zum Beispiel kann niemand die ganze Welt auf eine DVD packen.

Und worauf du also wirklich anspielst – und das sehen wir bereits bei Google Maps und ähnlichen Diensten –, Es ist einfach unmöglich, all das an einem Ort unterzubringen. Und ein Teil dessen, worüber wir sprechen werden, wenn wir von Streaming reden, ist genau dasselbe für Spiele und dann auch für andere Bereiche. Kannst du uns vielleicht erzählen, wie du zu Roblox gekommen bist, was dein Hintergrund ist und vielleicht einen kleinen Einblick geben, was Cloud-Transcoding ist?

Also, 

Tsvetan: Ähm, bevor ich zu Roblox kam, habe ich meine berufliche Erfahrung in zwei Bereichen gesammelt. Der eine ist 3D-Design- und Simulationssoftware für Architektur, Bauwesen und Maschinenbau. Und der zweite war groß angelegtes verteiltes Rechnen, was... Ich kann mein Wissen aus beiden Bereichen bei Roblox anwenden, denn genau darum geht es bei Roblox.

Dave: Ja. Lass uns zum Streaming auf Roblox übergehen und darüber sprechen. Also, wir wissen ja, was Videostreaming ist. Das Streamen eines Videos ist so eine Art linearer Vorgang, oder? Man braucht einfach nur ein Einzelbild. Ein Bild nach dem anderen senden wir dann nacheinander. Kannst du uns erklären, was Streaming in 3D in Echtzeit bedeuten könnte? 

Varun: Wenn man sich mal ansieht, woraus fast alles in einem Roblox-Spiel heute besteht: aus Instanzen oder Assets, richtig?

Instanzen, sozusagen die Struktur der Welt. Und dann ist ein Asset das, was diese Instanz für den eigentlichen Inhalt antreibt. Ähm, wenn man über Streaming nachdenkt, geht es darum, Instanzen zu streamen und auch diese Assets zu streamen. Das muss man tun. Wenn man also in einem Videostream nur ein einziges Asset hat, dann ist das das Video.

In Roblox machen wir das tausende, 10.000 Mal, äh, immer und immer wieder. Wenn man also von Instant-Streaming spricht, versucht man einfach, genug von der Welt um einen herum zu streamen, und man weiß nicht, was der Spieler tun wird. Der Spieler könnte hierhin gehen, der Spieler könnte dorthin gehen. Man möchte gerade genug streamen oder gerade genug von der Welt puffern.

Und dann, in dieser Welt, die du gepuffert hast, willst du die Assets in genau der richtigen Qualität puffern. Wie Sergei bereits erwähnt hat, gibt es verschiedene Qualitätsstufen für Videos. Das Gleiche gilt für Meshes und Bilder. 

Dave: Wenn wir das also aufschlüsseln, wäre es dann richtig zu sagen, dass die Instanzen Dinge sind, die uns vielleicht bekannt sind?

Ein Auto, ein Baum, eine andere Person, ein Hügel, so etwas in der Art. Und dann sind die Assets die technischen Elemente, aus denen diese Instanzen bestehen. Sozusagen das Innere dieser 3D-Objekte. Wenn wir an einem Spiel arbeiten, haben wir so etwas wie Dreiecksblöcke, wir haben Texturblöcke, und wir sprechen also davon, welche davon wir

Die man wirklich jederzeit einblenden kann. 

Varun: Ja. Und welche Darstellung davon. Wenn du also durch die Welt läufst, ist es so, als würde das Gerät sagen: „Okay, ich will diesen Baum“ oder „Ich brauche diesen Baum“. Dieser Baum besteht aus einer Reihe von Meshes und einer Reihe von Texturen, und vielleicht in Zukunft sogar aus Animationen, Audio und so weiter.

Also trifft es dann eine Entscheidung. Okay. Basierend auf der Position dieses Baumes, seiner Bedeutung, wie viel Platz er auf dem Bildschirm einnimmt. Ich will die Textur in hoher Qualität. Ich will das Mesh in mittlerer Qualität. Und dann das Audio – vielleicht brauche ich das Audio noch nicht, also warte mit dem Audio noch. Es trifft also ständig diese Entscheidungen, 

Dave: Also ist das in gewisser Weise ein bisschen wie, wenn ich ein Kartierungsprogramm benutze, ich, ich importiere nur die kleinen Bilder, einen kleinen Ausschnitt der Karte.

Wir sprechen hier von den 3D-Versionen davon und, na ja, auch von interaktiven 3D-Komponenten. Okay. Und hinter den Kulissen gibt es hier etwas wirklich Wesentliches. Ich würde sagen, unsere Vision war schon immer: Egal, welches Gerät oder was auch immer du benutzt, wir versuchen, die richtigen Elemente so schnell wie möglich einzubinden.

Und ich, und manchmal sagen wir, wir wollen sie so schnell wie möglich einbinden, um das menschliche Erlebnis von Magie zu maximieren. So als ob man einfach nur denkt: Wow, die Welt ist für mich erschienen. Also, Sergey, wie wählen wir aus und wie sortieren wir, was geladen und was eingebunden werden soll? 

Sergey: Also, ja. Äh, Optimierung, also, äh, für die wahrgenommene, weißt du, Latenz.

Das ist sehr wichtig, denn wie Varun gerade erwähnt hat, weißt du. Wir messen ständig, weißt du, den Bildschirmbereich, wie wichtig das Objekt ist. Zum Beispiel, wenn du einen Baum aus sehr naher Entfernung siehst oder genau denselben Baum aus sehr großer Entfernung, könnten das zwei verschiedene Bäume sein, oder?

Wenn man ihn also aus der Ferne sieht, sind einem feine Texturdetails oder so etwas eigentlich egal. Also können wir immer eine Textur mit niedriger Auflösung für den Baum verwenden. Äh, du wirst nicht in der Lage sein, zu unterscheiden, ob es sich um eine Struktur mit geringem Risiko oder hohem Risiko handelt, weil sie auf deinem Bildschirm einfach sehr klein ist.

Andererseits können wir die Daten fast sofort abrufen, weil es so viel weniger Daten sind. Aber wenn man sich diesen drei Bäumen nähert, laden wir nach und nach immer mehr Daten, und es sieht detaillierter aus. Man wird den Übergang also nicht sehen können, man wird den Unterschied nicht erkennen können, aber man wird sofort, sofort in der Lage sein, damit zu interagieren.

Dave: Und ein Teil davon ist, wenn ich mein Android-Handy mit 2 GB oder meinen Gaming-PC benutze und sofort an etwas teilnehmen möchte. Auch wenn das Internet wirklich schnell ist, haben wir nicht die Bandbreite, als ob wir versuchen würden, die ganze Welt durch diese Leitung zu schieben, egal ob man 10 Megabit pro Sekunde oder 100 Megabit pro Sekunde hat, und das, was wir da durchschieben, auszugleichen.

Und, und ich, eine Art, wie ich, ich manchmal darüber nachdenke, ist ein Baum, der in meiner Nähe steht. Ähm, der kann dieselben Informationen nutzen wie hundert Bäume, die weit weg von mir stehen, und im Grunde genommen haben die hundert Bäume, die weit weg von mir stehen, vielleicht die gleiche visuelle Bedeutung wie der, der in der Nähe ist, und wir holen sie in unterschiedlicher Auflösung herein.

So wie der, der mir nahe ist, eine viel höhere Bildqualität hat als die, die weit entfernt sind. 

Sergey: Ja, äh, das ist genau richtig. Äh, und, und, äh, der wichtige Punkt, den du auch erwähnt hast, ist, dass wir nicht nur messen, wie wichtig das Objekt ist, sondern auch, wie viel, wie viel Rechenleistung wir haben.

Wie viel Speicher haben wir? Wie viel Netzwerkbandbreite, einfach alles. Also berücksichtigen wir alles, was die Benutzererfahrung beeinflusst, und dazu gehört auch die Leistung. Du weißt schon, wie viel Speicher wir haben und all das. 

Dave: Also, wir haben darüber gesprochen, dass Instanzen so etwas wie der Baum sind und die Assets das Mesh oder die Texturen.

Können Sie uns mehr darüber erzählen, wie sie sich unterscheiden und was wir hinter den Kulissen beim Asset-Streaming eigentlich machen? Okay. 

Tsvetan: Ja. Ähm, zum Beispiel beim Streaming vom Server, den Sites – was ist wichtig? Ja. Und basierend auf, äh, der Wichtigkeit, äh. G liefert diese Informationen, leitet sie an jeden Client weiter, und jeder Client erhält tatsächlich unterschiedliche, äh, Instanzen dafür, je nachdem.

Ist es sichtbar? Es ist nicht sichtbar. Nimmt es am interaktiven Bereich teil oder nicht? Was das Asset-Streaming angeht? Es ist der Client, der tatsächlich das streamt, was sich in der Welt befand. Äh, basierend auf der Qualität, die wir anstreben, wie Sergey sagte, basierend auf den Fähigkeiten des Geräts, zielen wir nur genau auf diese Darstellungen ab, basierend auf der Qualität und den Fähigkeiten des Geräts.

So läuft das bei uns im Grunde genommen. Äh, also 

Dave: sind diese Bäume weit in der Ferne hoffentlich sehr kompakt, oder? Eine niedrigere Auflösung, die nicht viel Platz beansprucht. So können wir mehr Zeit und Rechenleistung für einen Baum aufwenden, der näher an mir ist. Und so haben wir diese sogenannte Content-Pipeline oder Asset-Pipeline.

Kannst du mir ein bisschen erklären, wie diese Transcodierungs-Pipeline aussieht, wenn ich zum Beispiel ein Spieleentwickler bin? Angenommen, ich benutze Roblox Studio und baue ein richtig cooles Auto. Was passiert da hinter 

Tsvetan: den 

Dave: den Szenen? 

Tsvetan: Aufgrund der, äh, Verbesserungen an der Engine wollten wir auch die, äh, künstlerische Absicht der Designer und Spieleentwickler bewahren.

Also kamen wir auf diese Idee der Cloud-Transkodierung, die es uns ermöglicht, äh, äh, die Inhalte aus dem, äh, Creator Store zu importieren. Sie basierend auf den Entwicklergeräten, äh, Geräten und Fähigkeiten zu optimieren, die, äh, äh, der Client benötigt. Und, äh, diese Pipeline ist durchgängig. Sie ist „lazy on demand“. Das bedeutet: Wenn der Client eine bestimmte Darstellung anfordert, starten wir erst dann eine Berechnung, wenn wir diese Darstellung nicht bereits haben.

Andernfalls geben wir sie zurück, falls sie bereits vorhanden war. Wir sind also sehr effizient in Bezug auf die Bandbreite und die Rechenleistung, die wir dem Kunden bereitstellen. Also 

Dave: Wenn ich, ähm, und wir, es ist schon lange her, als wir das noch nicht hatten, oder vielleicht eigentlich erst vor kurzem, mussten wir die Detailgenauigkeit dieser Assets einschränken.

Ich meine, wir hätten wohl gesagt: Du darfst nur eine bestimmte Anzahl an Dreiecken in deinem Auto haben, und je mehr Dreiecke, desto genauer sieht dein Auto aus. Oder wir hätten gesagt: Du darfst nur eine bestimmte Anzahl an Pixeln in der Größe einer Textur haben. Was wir jetzt sagen, ist: Ich glaube, du kannst dieses Auto hochladen, ganz gleich, wie du es gebaut hast, und dann, wenn du von Transcodierung hinter den Kulissen sprichst.

Wir erstellen verschiedene Versionen dieses Autos mit immer weniger Dreiecken. 

Tsvetan: Ja, das ist richtig. Oder in Zukunft sogar noch mehr. Ja. Und äh, wir haben jetzt diese Möglichkeit, dass wir, äh, je nach den Verbesserungen der Engine und äh, der Rechenleistung, die wir haben, wir können, äh, die Darstellung der Anzahl der Dreiecke oder der Textur, der Maps oder von Audio, Video, Animation, was auch immer wir brauchen, verbessern.

Also, 

Dave: Das ist also auf Abruf, und ich glaube, das ist es, was du vorhin gesagt hast, Sergey. Früher gab es so etwas wie „Baking“, man hat sozusagen das High-End-Modell gebacken. Wir machen im Grunde genommen „Baking“ auf Abruf. Viele Versionen dieses Autos in verschiedenen Auflösungen. Die liegen alle da. Und dann ist das Auto, das ich weit in der Ferne sehe, vielleicht eine dieser Versionen mit niedrigerer Auflösung.

Und das ist, äh, ich glaube, das nennen wir Transcoding. Ja. Wie funktioniert Transcoding also? Wie nimmt man eine Million Dreiecke und verwandelt sie in tausend Dreiecke? Ich meine das, äh. 

Tsvetan: Äh, Ingest. Ja. Also, im Studio nehmen wir dieses Netz aus einer Million Dreiecken tatsächlich auf. Wir speichern es dann in unserem Backend, unserer Content-Plattform, unserem Backend-System.

Und dann führen wir auf Anfrage tatsächlich eine LOD-Verarbeitung durch, 

Dave: was für „Level of Detail“ steht. Level of Detail, das bedeutet 

Tsvetan: Je nachdem versuchen wir, so viel Qualität wie möglich für diese, äh, begrenzte Darstellung des Netzes zu erhalten. Oder der Textur. 

Dave: Also, wenn, ähm, vielleicht Varun, wenn wir darüber nachdenken, wie das geräteübergreifend funktioniert: Du bist, ähm, also du bist der Entwickler.

Du fügst dieses riesige, hochauflösende Auto ein. Ich nutze ein Low-End-Android-Gerät. Du nutzt einen High-End-Gaming-PC. Hoffentlich können wir trotzdem dasselbe Spiel spielen. Genau. Was passiert denn für uns beide? Und, 

Varun: Also, im Grunde genommen ist es so: Wenn mein Client online geht, sagt er sozusagen: „Hey, ich bin ein Low-End-Android-Gerät. Ich will genau das hier“, denn eine Sache, die wir eigentlich noch nicht erwähnt haben, ist, dass es nicht nur um den Detaillierungsgrad geht, sondern auch um eine plattformspezifische Darstellung.

Also Android, iOS – jede dieser verschiedenen Plattformen hat sehr spezifische Darstellungen, bei denen man die Texturen komprimieren und so anpassen kann, dass es viel optimaler funktioniert. Mein Android-Gerät geht also online und sagt: „Hey, ich will die Android-Version einer Low-End-Textur für diesen Baum“, und dann macht das Cloud-Transkript das für mich und speichert es im Cache, damit das nächste Android-Gerät, das online geht,

Es muss das nicht noch einmal tun, sondern kann einfach die Version senden, die ich erstellt habe. Wenn dein PC online geht, sagt er sozusagen: „Hey, ich habe alle Ressourcen der Welt. Gib mir die hochwertige Version, gib mir die unkomprimierte Version. Ich will einfach nur höchste Wiedergabetreue.“ Und dann speichert er das im Cache, was bedeutet, dass dies unendlich zukunftssicher ist.

Dave: Und auch unendlich sofort verfügbar. Ich liebe „Grand Theft Auto“, und die haben so eine neue Version, die absolut umwerfend sein wird, worauf ich mich schon sehr freue. Wenn ich ein Künstler wäre, der, ähm, ein Asset anpassen wollte. In unserem, hoffentlich zukünftigen System, würde ich es in etwa fünf Sekunden erneut hochladen.

Dein und mein Spiel würden eine neue Transkodierung davon auslösen. Und buchstäblich, weißt du, bei maximaler gleichzeitiger Nutzung, wie zum Beispiel bei „Grow a Garden“ mit 25 Millionen Spielern, könnte man in fünf bis zehn Sekunden all diese neuen Spieler haben. Die möglicherweise dieses neue Asset erhalten. Deshalb denke ich, dass es irgendwie die Zukunft ist, denn ich glaube, ein Teil der Schönheit von Grand Theft Auto liegt darin, dass sie so viel Qualität einbauen.

Sie werden es auf eine riesige DVD packen. Sie müssen sicherstellen, dass das perfekt ist, und es gibt keine Möglichkeit, das zu überarbeiten. Man muss es genau dort absolut perfekt hinbekommen. Und, und, und dann, ich, ich, ich denke, schließlich. Was die Zukunftssicherheit angeht, gibt es neben den sofortigen Änderungen noch etwas, das gut erscheint: die Speicherung der künstlerischen Absicht, weißt du, die Speicherung des ursprünglichen Kunstwerks.

Könntest du in gewisser Weise erwähnen, wie uns das helfen könnte? Äh, 

Sergey: Ja. Also, da wir versuchen, so viel wie möglich von den ursprünglichen künstlerischen Inhalten zu erfassen, speichern wir dafür die Quellversion, genau. Von allen Assets. Und wir können das, wie du dir vorstellen kannst, so machen, dass wir

Nicht nur durch Downsampling, indem wir einfachere Versionen einer Textur generieren, sondern auch durch Upsampling in der Zukunft, denn wir haben bereits die Semantik erfasst, also die ursprüngliche Absicht, sodass wir dieses Asset in der Zukunft hochskalieren können. Und zwar ohne jegliche Benutzereingabe.

Wir können es besser aussehen lassen. 

Dave: Das, und das wird ein wichtiger Hinweis sein, wenn wir in die Zukunft blicken. Ähm, also lasst uns, ähm, lasst uns dem, worüber wir gesprochen haben, eine zweite Komponente hinzufügen. Wir streamen also. Nehmen sofortige Korrekturen vor. Cloud-Transcodierung, liefern jede LOD. Und dann, was wir am Anfang angedeutet haben, werden wir das mit etwas namens Slim ergänzen.

Also, Slim ist kein Trainingsprogramm. Es ist nicht wie bei Roblox, es sind nicht die Roblox-Snacks, die uns hoffentlich alle wirklich gut fühlen lassen und klar denken lassen, äh, was ist „Slim“ im Kontext der Roblox-Engine? 

Sergey: Also, ja. Äh, also. Äh, lass mich mal einen Schritt zurückgehen und dieses Beispiel noch einmal anführen, zum Beispiel mit einem Baum, okay?

Also, wir haben, äh, du hast einen Baum, und wie ich schon sagte, wenn du vielleicht mehrere Bäume hast, äh, in der Ferne, äh, dann ist Slim das, was all diese einzelnen Bäume sozusagen in einen Wald verwandelt und optimiert, also nicht mehr einzeln betrachtet, sondern sie als etwas Größeres optimiert, das ist eine Aggregation, sozusagen von einzelnen Objekten und, äh.

Und das ist die Slim-Technologie. Sie optimiert diese Objekte immer in einem bestimmten Kontext. Nehmen wir also an, du hast ein Gebäude, okay? Und eine Reihe von, äh. Äh, Räumen in diesem Gebäude. Wenn man sich außerhalb des Gebäudes befindet, interessieren einen die Räume im Inneren nicht. Und Slim ist sich dieses Kontexts bewusst und kann in diesem Fall sehr effizient alle Innenbereiche des Gebäudes entfernen und eine sehr optimale Version dieses Assets für einen generieren.

Dave: Es gibt also drei Anwendungsfälle, über die ich nachgedacht habe, während du das hier entwickelt hast. Ein Anwendungsfall ist, dass die Leute immer komplexere Avatare erstellen. Und historisch gesehen waren wir bei Roblox sehr vorsichtig: Wie viele Kleidungsschichten kann man tragen? Wie viel Schmuck kann ich tragen, wie viel Zeug?

Aber in Zukunft könnten Avatare vielleicht viele, viele Dinge haben, sagen wir hundert. Und ich denke, unsere Entwickler sind sehr versiert, was die Leistung angeht. Sie schränken vielleicht sogar die Detailtreue der Avatare ein, weil sie so viel Leistung wollen. Komplexe Avatare, Nummer eins. Nummer zwei: Wie du erwähnt hast, stehen dort vielleicht hundert Bäume, die weit entfernt sind und mit denen niemand interagiert.

Und drittens vielleicht ein Gebäude mit Räumen im Inneren. Äh, ich denke, was wir hier versuchen werden, ist: Egal, was es ist – ein sich bewegender Avatar, ein paar Bäume oder ein Gebäude –, genau dieses System wird im Grunde zu einem einzigen Objekt, einem einzigen Mesh, einer einzigen Textur zusammengefasst, und das ist absolut umwerfend.

Äh, 

Sergey: Ja, du hast vollkommen recht. Das ist ein gutes Wort. Also, dieses System generiert dynamisch so etwas wie eine zusammengesetzte Darstellung aus mehreren Assets und bestimmt dabei die Grenzen dieser Komposition sowie den Detaillierungsgrad – und zwar dynamisch, immer im Kontext dieser Welt.

Genau wie bei zwei verschiedenen Erlebnissen, die je nach Zielgerät und je nach Kontext, in dem sie genutzt werden, unterschiedlich optimiert werden können. Äh, wir unterstützen auch dynamische Aktualisierungen für diese Inhalte. Es ist also nicht immer so, es ist keine statische Optimierung.

Wenn sich etwas im Laufe der Zeit ändert, spiegelt sich das in der schlanken Darstellung wider, da wir sie dynamisch aktualisieren können. 

Dave: Es ist fast so, als wäre ich ein Roblox-Entwickler – das ist einer der Gründe, warum mir das so gut gefällt. Und ich wollte wirklich einen riesigen Umfang und zum Beispiel sehr komplexe Avatare.

Vielleicht träume ich davon, dass ich auf jemanden in meiner Nähe zugehen kann. Die Person kann ihren Hut abnehmen oder neuen Schmuck anlegen – so funktioniert dieses System mit Objekten, die nah sind, und arbeitet möglicherweise mit normaler hoher Detailtreue. Und wenn sich der Avatar dann entfernt, wird er zu einem einzigen Objekt zusammengefasst.

Und je weiter er sich entfernt, desto höher ist der LOD. Ähm, wir scherzen schon, dass das Nonplusultra ein Avatar in weiter Ferne ist, der vielleicht aus 12 Dreiecken und einer wirklich kleinen Textur besteht. Das ist also fast genau das, wovon ein Entwickler wie ich, glaube ich, geträumt hat. Und ich denke, das ermöglicht unter anderem eine größere Welt.

Geräteübergreifend. 

Varun: Absolut. Ich meine, was Slim im Wesentlichen tut, ist, uns eine neue Achse der Skalierbarkeit zu geben. Wir haben also so viel über Cloud-Transcoding in verschiedenen Detailstufen gesprochen. Jetzt fügen wir hier eine weitere Ebene einer anderen Achse hinzu, bei der es um Compositing geht. Richtig? Und man kann sich hier ein Zwei-mal-Zwei-Raster vorstellen, und jeder Punkt darauf ist eine gültige Erfahrung.

Das stimmt. Man könnte also hohe Qualität bei geringer Komposition haben, oder hohe Qualität bei hoher Komposition, wenn man ein sehr einfaches Gerät oder ein anderes Gerät nutzt. Und all diese Punkte machen Sinn. Wenn man also von einer riesigen Welt spricht, könnte diese gesamte Welt aus 12 Dreiecken bestehen. Auch wenn man weit genug entfernt ist oder wenn es keinen Unterschied macht.

Dave: Und wenn man dann über die Benutzererfahrung nachdenkt und darüber, wie Slim zu einer besseren Benutzererfahrung führen kann. Wenn wir an LOD denken, denken wir an Cloud-Transcoding. Wenn wir an Slim denken, denken wir an Streaming im Vergleich zu Roblox heute oder vor einem Jahr – wie. Wie kann sich das auf die Benutzererfahrung auswirken? 

Tsvetan: Ja, also Slim, äh, wir haben Slim mit der Idee entwickelt, dass, äh, wir den Entwicklern ermöglichen, reichhaltigere und komplexere Welten zu erschaffen, die, äh.

Äh, sich verhalten und mit dem Endnutzer interagieren. Siemens? Äh, ja, ganz einfach. Sozusagen ohne, äh, und für den Endnutzer ist die Benutzererfahrung genau dieselbe, als hätte man den, äh, leistungsstärksten Rechner. Und, äh, Slim ist, ähm, dieses System, das heute, ähm, statische Modelle ermöglicht. Und wir sind, äh, weißt du. In Zukunft Avatare und dynamische Modelle, die, ähm, hierarchisch generiert werden, äh, damit wir, äh, das System für den Endnutzer so schnell wie möglich machen können, 

Dave: was für den Endnutzer reichhaltigere Welten auf weniger leistungsstarken Geräten bedeuten könnte.

Das könnte auf meinem Low-End-Handy sein. Ich kann mit dir auf deinem Gaming-PC spielen. Äh, Entwickler können komplexere, ähm, sich keine Gedanken über die Anzahl der Kleidungsschichten eines Avatars machen. Komplexere Fahrzeuge, ähm, kompliziert. Ähm, auch mechanische Objekte werden durch „Slim“ komprimiert, was wirklich, wirklich cool sein wird.

Und dann. Ähm, vielleicht darüber nachdenken, wie sie zusammenarbeiten. Wir haben also über Cloud-Transcoding gesprochen, äh, also das Anbieten von niedrigerem LOD. Dann haben wir über Slim gesprochen, das sind wirklich leichtgewichtige Modelle. Funktionieren sie zusammen? 

Varun: Absolut richtig. Und genau das habe ich mit dieser „Zugangs“-Sache gemeint. Alle Slim-Modelle durchlaufen also genau dieselbe Cloud-Transcoding-Pipeline.

Denn sobald man sie zusammensetzt und sobald „Slim“ basierend auf dem Kontext und dem Inhalt entschieden wird, sollte das Ergebnis so aussehen. Es durchläuft dieselbe Transcoding-Pipeline und generiert dann für alles eine Version mit niedriger Qualität, eine Version mit hoher Qualität, eine Android-Version und eine iOS-Version.

Es ist also, es ist, es ist sehr, sehr komplementär, ähm, zwischen, 

Dave: Und das ist für den Ersteller also fast wie ein doppelter Schlag: ein sehr komplizierter Avatar, der aus der Ferne in ein Slim-Modell zusammengesetzt und dann transkodiert wird. Dieser Avatar könnte wiederum aus 12 Dreiecken und einer einzigen Farbe bestehen. Und, und was 

Varun: was man sich erhoffen würde, oder was ich erwarten würde, ist sozusagen eine erste Stufe.

Alle bestehenden Erlebnisse können einfach auf immer einfacheren Geräten laufen. 

Dave: Ja. 

Varun: Aber das wirklich Spannende sind die Effekte zweiter Ordnung, oder? Die Entwickler beginnen zu erkennen: „Oh, ich kann mehr Dinge in die Welt einbringen. Oh, ich kann etwas hinzufügen.“ Nun, man denkt 

Dave: darüber nach, ähm, wenn ich ein Video produziere. Es ist fast so, als wäre die Kamera ziemlich ausgereift.

Weißt du, ich nehme meine 4K-Kamera und mache mir nie Sorgen, egal wohin ich die Kamera richte, ob ich einen Film so aufnehmen kann, wie ich es tue. Aber unsere Kreativen haben diese Kamera heute nicht. Wenn sie die Kamera zum Beispiel an die falsche Stelle richten. könnte die Welt explodieren, oder? Zu hohe Auflösung, zum Beispiel, wenn sie die Kamera auf eine Menschenmenge von 10.000 Leuten richten, ist das so, als würde man die immersive 3D-Kamera befreien, 

Varun: und den Entwicklern Freiheit zu geben.

Also können wir die Plattform erweitern und dann das Genre. Ja, 

Dave: Und ich glaube tatsächlich, dass es einen Zeitpunkt geben wird – wir wissen nur nicht wann –, an dem es eine Mischung aus Mooreschem Gesetz, Slim-3D-Rechenleistung, Streaming-KI, lokalem Upsampling und was auch immer sein wird. An dem diese Kamera vielleicht keine Einschränkung mehr darstellt, an dem man, wenn man hunderttausend Menschen in einem riesigen Stadion haben möchte, fotorealistisch mit seinen Freunden abhängen und auf einem Low-End-Gerät mit geringer Latenz streamen kann – das fühlt sich gut an.

Das wird, glaube ich, der Moment sein, an dem wir sagen können, dass die immersive 40-Kamera ausgereift ist. Die, ähm, gute oder schlechte Nachricht ist, dass es noch viel zu tun gibt. Das macht unsere Arbeit irgendwie interessant. Und ich, ich denke, ich, in Bezug auf das Thema, wie schnell wir uns auf diese ultimative drei- und vierdimensionale Kamera zubewegen, ähm, Sergei, was kommt als Nächstes für Slim und so, was würden wir danach optimieren?

Also 

Sergey: Was Slim angeht, also, ähm. Ein paar große Schritte liegen noch vor uns. Also, der allererste Schritt ist, Slim vollständig dynamisch zu machen, damit es Avatare, fahrende Fahrzeuge, Bewegungsmechanismen und all so etwas unterstützt. Aber der wichtigere Schritt danach ist, Slim hierarchisch zu gestalten, wie Barron erwähnt hat – Slim generiert nämlich so ziemlich dieselben Assets wie ganz normale Assets.

Sie durchlaufen genau dieselbe Streaming-Pipeline. Wir optimieren sie, weil jedes Slim-Modell individuelle Eigenschaften und so weiter hat. Aber was wäre, wenn wir noch einen Schritt weiter gehen könnten? Was wäre, wenn wir mehrere Slims zu einem einzigen kombinieren könnten, sozusagen zu einem Mega-Slim, und das dann immer wieder auf diese fraktalartige Weise?

Dave: Das war also Teil unserer Designfrage. Denn als du ursprünglich Slim vorgeschlagen hast, haben wir uns mit Avataren beschäftigt und hatten ein separates Projekt. Wir haben darüber nachgedacht, wie man hundert Avatare zusammenbringen könnte und wie wir hunderttausend Menschen in einem Stadion simulieren könnten. Und was wirklich faszinierend war, war dieser Tag, an dem du gesagt hast: „Weißt du was, vielleicht können wir Slim-Avatare nehmen und dann hundert davon in eine Sammlung von hundert Avataren mit genau derselben Technologie einfügen.“

Und das war so ziemlich der Punkt, an dem wir sagten: „Das haut uns um!“ – diese hierarchische Struktur? 

Sergey: Äh, ja, äh, das ist genau richtig. Und wenn man dieses Beispiel bis zum Äußersten durchdenkt, kann man sich das so vorstellen: Okay, unsere virtuelle Kamera kann den gesamten Planeten sehen. Wir sehen also den gesamten Planeten, und er ist einfach wie eine Kugel, mit der entsprechenden Textur.

Wenn die Kamera näher kommt, sieht man einzelne Kontinente, dann einzelne Städte, und dann kann man ganz hinunterzoomen, zum Beispiel zu einem Stadion voller Menschen, weil die gesamte Simulation auf dem Server läuft und der Client nicht alles wissen muss, ähm, über die ganze Welt.

Es ist klar, dass man den gesamten Planeten nicht in den Speicher eines Geräts packen kann, selbst wenn man einen leistungsstarken PC hat. Aber unsere Server sind sehr leistungsstark, und indem wir diese Art von Schlüsselrepräsentation für Slim generieren, können wir von der Planetenebene bis hinunter zur Raumebene oder sogar zur Mikrowelt gehen.

Dave: Nun, genau. Wir könnten bis hinunter zu der Uhr gehen, die du oder ich tragen, den kleinen Knopf an der Uhr betrachten und sogar noch weiter als das. Und wenn wir also darüber nachdenken, äh, Satan, wie könnte das die Arbeit der Entwickler verändern? Richtig. Wir werden hoffentlich das loswerden, dass wir uns um die Leistung eines Avatars sorgen müssen.

Ähm, gibt es noch andere Veränderungen, die wir deiner Meinung nach sehen könnten? 

Tsvetan: Meiner Meinung nach wird dies alle Einschränkungen beseitigen, die sie heute haben. Sie müssen, wie du gesagt hast, nicht darüber nachdenken, wie komplex die Welt ist, die sie erschaffen. Sie müssen nur darüber nachdenken, was sie ihren Spielern als Spieldynamik präsentieren wollen.

Sonst nichts. Alles andere wird automatisch von uns übernommen. 

Dave: Also, und, und es ist gut, etwas tiefer in diese automatischen Abläufe einzutauchen. Weißt du, im alten, traditionellen Roblox hatten wir diese Sache namens Textur-Atlas. Wir hatten tatsächlich eine Vorlage für eine Textur, und man musste sich selbst damit auseinandersetzen. Ich gehe davon aus, dass das mit einem schlanken Modell komplett automatisch abläuft.

Ähm, wie die Erzeugung dieser Textur in niedrigerer Auflösung. 

Tsvetan: Ja. Das wird automatisch ablaufen, ebenso wie die Bestimmung dieser, äh, Bausteine, die Sergei in der hierarchischen dynamischen Welt erklärt hat. 

Dave: Okay, also jetzt, ähm, jetzt werden wir uns wirklich umhauen und wir werden darüber sprechen, ähm, es ist leicht, sich etwas Einfacheres vorzustellen, oder?

Es ist fast so, als ob man sich als Künstler so etwas sehr leicht vorstellen kann. Etwas grober zu gestalten und zu verflachen, ist viel einfacher, als sich vorzustellen, dass etwas eine höhere Auflösung bekommt. Und deshalb möchte ich ein wenig in die Zukunft der KI hineinschauen, und dort wird gerade viel an KI gearbeitet, zum Beispiel daran, wie wir Videospiele und immersives Echtzeit-Streaming sowie Weltmodelle und all das generieren werden.

Ähm, und ich, ich habe immer mehr das Gefühl, dass wir feststellen werden, dass dies keine monolithische Sache ist. Das wird ein Stapel von drei, vier, fünf oder sechs Modellen sein, die alle zusammenarbeiten, einschließlich, weißt du, einer Befehlszeile, wo wir, wenn wir zusammen sind, so wie wir es mit 4D machen, einfach sagen können: „Verwandle das Washington Monument in Godzilla“, und zack, es passiert genau dort.

Ähm, und letztendlich Objekte oder Welten oder ganze Spiele generieren. Ähm, und hoffentlich in einem Multiplayer-Kontext. Also laufen wir zu viert zusammen herum und sagen: „Hey, da drüben“, und wir vier möchten ein neues Spiel entwerfen und es auf magische Weise erscheinen lassen. Es gibt noch einen zweiten Aspekt. Ähm, zusätzlich zu Command Prompt und World Gen und 3D, wovon du gesprochen hast, ähm, gibt es Upsampling und, und das, ähm, wenn ich mir manchmal das klassische „Crossroads“ vorstelle, ein 20 Jahre altes Spiel auf Roblox, dann sind dort tatsächlich genug Informationen vorhanden.

Wenn wir das klassische „Crossroads“ nehmen und, Sergey, du hast gesagt, es so aussehen lassen. Wie eine fotorealistische, mittelalterliche Version, bei der das Gameplay dasselbe sein könnte. Die, weißt du, all diese lustigen kleinen Raketenwerfer-Tools sind dieselben, aber plötzlich sieht alles ganz neu aus. Wie würde das also in diesem Zusammenhang funktionieren?

Ich weiß nicht, wer sich dazu äußern möchte. Zum Thema LOD, denn jetzt muss der LOD-Wert erhöht werden, anstatt ihn zu senken. 

Varun: Ich glaube, das ist einer der Punkte, die Sergey vorhin angesprochen hat, oder? Es geht darum, so viel wie möglich von der ursprünglichen künstlerischen Absicht zu bewahren, damit wir solche Dinge in Zukunft umsetzen können. Und mein Lieblingsbeispiel – das ist jetzt mal ein willkürliches Beispiel –, aber stell dir vor, ich verwende eine Textur, die eigentlich ein Foto ist, das jemand aufgenommen hat, und ich hätte die Blendenzahl gespeichert.

Die Größe, wenn ich die Blendenzahl gespeichert hätte, als das Bild aufgenommen wurde. Jetzt hat mein „Uprising“-Algorithmus so viel mehr Kontext. Ja. Wenn ich weiß, wo diese Textur verwendet wird, wenn ich weiß, dass sie auf einer Burg verwendet wird, wird sie dann auf dem Boden verwendet? Mein Uprising-Algorithmus kann so viel intelligenter sein, wenn es darum geht, das zu erstellen und die ursprüngliche Absicht des Schöpfers durchgehend beizubehalten – sei es auf diesem High-End-PC oder einem zukünftigen PC, der noch gar nicht erfunden wurde.

Also 

Dave: Wir haben das auf der RDC gezeigt, ich glaube, wir haben ein etwa 15-sekündiges Video gezeigt, in dem „Crossroads“ hochskaliert wurde. Ähm, können wir darüber sprechen, was tatsächlich passieren könnte? Die Assets befinden sich in der Cloud, die 3D-Objekte, die Texturen. Ähm, es wird eine zusätzliche Anweisung an unser Content-System gesendet, die besagt: „Schau mal, all diese Assets sind Teil einer, äh, mittelalterlichen Welt, die man sich viel fotorealistischer vorstellen kann.“

Dann werden all diese verschiedenen Elemente neu generiert, um der fotorealistischen Version viel näher zu kommen – durch einen, wie wir es nennen würden, 3D-UPS-Sampler oder eigentlich einen generativen 3D-Generator. Also, ähm, wer möchte sich damit beschäftigen, was zum Beispiel mit der Burg passieren könnte? 

Sergey: Ich, ich, ich denke, so wie Baron es gerade erwähnt hat, weißt du, es scheint, als würden wir so viel mehr Semantik aus dieser Welt erfassen.

Das ist nämlich extrem wichtig. Also, zum Beispiel bei diesem Kreuzungsbeispiel, richtig? Wenn man sich also das Schloss ansieht. Ähm, aus meiner Perspektive der einzelnen Assets, also einfach wie eine Reihe von Blöcken, sind das nur Kisten. Und man hat nicht genug Kontext, man kann diese Blöcke einfach nicht besser aussehen lassen.

Und die Burg ist einfach, äh, sie ist mehr als nur einzelne Blöcke. Sie ist die Summe davon. Äh, und Slim, da Slim in diesem Kontext arbeitet, ist sich Slim dieser Sache als Ganzes bewusst. Also, und jetzt weiß jede Assemblage viel mehr über, weißt du, die Burg als Ganzes, nicht über einzelne Objekte.

Also kann sie eine viel bessere Version dieses hochskalierten Schlosses erstellen, weil sie einfach versteht, dass 

Dave: und, und, und in gewisser Weise könnte man sich vorstellen, dass es ohne das bereits existierende „Crossroads“-Schloss geht. Und nur damit das allen klar ist: „Crossroads“ ist ein sehr altes, blockartig aussehendes Roblox-Spiel.

Diese Burg ist tatsächlich eine wirklich gute Hilfe für die Eingabeaufforderung. „Baue mir eine Burg.“ Das ist eine ziemlich offene Eingabeaufforderung. Wir bekommen eine zufällige Burg mit einer zufälligen Form. Aber die Burg in „Crossroads“, insbesondere ihre Abmessungen, das sind viele gute Informationen für die Eingabeaufforderung, um daraus eine wirklich hochwertige Burg zu erstellen.

Sergey: Äh, ja. Äh, das ist genau richtig. Also, weil, äh, äh, dieser, äh, dreidimensionale Teil der Burg, erstens, ist das, das wird aus Gameplay-Sicht sehr wichtig sein, oder? Man kann also nicht einfach irgendeine Burg generieren und sie so gestalten, dass sie für das Spiel funktioniert. Äh, weil. Aber wenn man alle Dimensionen erfassen kann, also die ganze Semantik in allen Kontexten, also in dem, worin das Set verwendet wurde, dann kann man es sehr effizient hochskalieren.

Und du wirst dein Spiel dadurch nicht kaputtmachen. Denn das ist eine weitere sehr wichtige Sache. Du willst kein Asset hochskalieren, das dein Spiel unspielbar machen könnte. 

Dave: Nun, ich glaube, es gibt eine Zukunft, in der man zusätzlich zu all den 3D-Informationen entweder die 3D-Informationen selbst bearbeiten oder die Eingabeaufforderung bearbeiten kann.

Beides kommt zusammen, um diese Welt zu generieren, sodass das so funktioniert. Das Fünf-Sekunden-Update, über das wir gesprochen haben, ist eine Asset-Modifikation der Zukunft. Es könnte ein Fünf-Sekunden-Prompt-Update sein und ein kleiner zusätzlicher Hinweis im Prompt. Und dann wird diese Welt bei Bedarf verzögert generiert. Und, und dann gibt es noch eine letzte Sache, ähm, wenn wir über alle Dimensionen nachdenken, wie KI zusammenwirken kann, um diese Dinge fotorealistisch zu machen, dann sind wir noch nicht am Ziel.

Da gibt es noch eine letzte Ebene, nämlich die 2D-Ebene. Was passiert auf deinem Gaming-PC? Was würde in einer Videoeinrichtung in der Cloud passieren, wo vielleicht noch höhere Auflösungen möglich sind? Also, ähm, zum Beispiel perfektes Haar auf meinem Kopf. Der beste Ort, um dieses Haar zu erstellen, könnte lokal mit einem 2D-Upsampler sein. Ich weiß, dass du an vielen Spielen gearbeitet hast, die versuchen, Haare in 3D zu erstellen.

Was denkst du, wird eines Tages alles Haar mit 2D-Upsampling gemacht werden oder wird es 3D-Haar sein? 

Sergey: Ja, auf jeden Fall. Ich glaube, wir bewegen uns in diese Richtung, weil manche Dinge eben nur im Screen-Space möglich sind – das ist effizienter. Lass es mich so sagen: Es ist effizienter, das im Screen-Space zu machen.

Zum Beispiel, wie hier, äh, wie Haare, wie das Rendering, richtig? Also, und so, oder. Viele Spiel-Engines arbeiten heute mit ML-basiertem Upsampling, also, äh, von etwa 1080p auf 4K. Aber man kann, man kann viel mehr als das machen, oder? Man kann also die Schattierung ändern, man kann, äh, das Aussehen der Dinge verändern.

Und wenn man dieses Beispiel auf die Spitze treibt, kann eine Spiel-Engine einfach, weißt du, so etwas wie semantische Informationen rendern, etwa für einen ML-Algorithmus, und dann generiert dieser ML-Algorithmus dann, weißt du, gut aussehende Haare oder gut aussehende Materialien. So wie im Sprit-Raum, die Direktive.

Dave: Super gut. Ähm, also dann, und dann, wenn wir zum Schluss kommen, vielleicht für alle C++-Programmierer da draußen, die Assembler-Programmierer, was, ähm, ich, ich wünschte, ich wäre so, das ist eines der spaßigsten Dinge der Welt. Wir machen hier etwas sehr Schwieriges, oder? Wir versuchen, ähm, all diese Technologien auf allen Geräten laufen zu lassen.

Frage zum Transcoding. Die Frage zum Transcoding lautet: Ich weiß, dass viele PCs über Optimierungen verfügen, ähm, mit SIMD-Registern und ähnlichen Dingen, damit diese Dinge schneller laufen. Haben wir bereits damit begonnen, in einem unserer Transcoder mit SIMD zu experimentieren, oder ist das eine zukünftige Optimierung? 

Tsvetan: Ähm, also zunächst einmal: Transcodierung läuft übrigens heute auch auf der Engine.

Okay. Ausgezeichnet. Gut. Wir nutzen also CMD-Optimierungen, aber wir schauen noch weiter darüber hinaus und nutzen GPUs und, äh, andere, 

Dave: Also Transpo. Okay. Transcodierung auf GPUs kommt möglicherweise. 

Tsvetan: Ja, wir prüfen das gerade. 

Dave: Okay. Was super, super spannend ist. Okay, also, ähm, tolles Update für alle, äh, äh, für diejenigen, die eine visuelle Darstellung wünschen, vielleicht RDC, eine Präsentation auf der Hauptbühne.

Ich denke, wir sollten das machen, wir hatten zu vielem davon Bildmaterial. Alles, worüber wir gesprochen haben, ist in der Pipeline. Äh, wir beobachten das genau und ich, ich, ich glaube wirklich, ähm, dass ihr alle und die verschiedenen Teams hinter euch wirklich zu dem beitragen, was ich manchmal als „Game Engine 2.0“ bezeichne, äh, was stark auf die Cloud setzt.

Stark unterstützt durch Transcoders in all dieser Technologie. Also vielen Dank an euch alle. Ich glaube, wir haben heute alle umgehauen. Ich weiß das wirklich zu schätzen. 

Tsvetan: Danke. 

Dave: Okay, also hey, hier ist Dave. Ähm, noch einmal: Tech Talks, und wir freuen uns darauf, euch beim nächsten Mal wiederzusehen. Vielen Dank an das gesamte Team. Vielen Dank.