Mod Lordgit ist zurück und gibt uns noch einmal einen Einblick in die Tiefen von NXT – diesmal konzentrieren wir uns darauf, welche spannenden Entwicklungen uns in Zukunft noch erwarten.
Heute möchte ich an meinen vorigen Blog anknüpfen und über einige mögliche zukünftige Entwicklungen für NXT und die Herausforderungen reden, die uns dabei erwarten werden, sie in die Realität umzusetzen.
Das Niveau an technischen Details wird ungefähr so wie im letzten Blog sein, aber aufgrund der Anzahl der behandelten Themen, werde ich diesmal nicht ganz so teuflisch ins Detail gehen wie beim letzten Mal. Außerdem möchte ich gleich vorweg auch darauf hinweisen, dass keine dieser zukünftigen Entwicklungen in Stein gemeißelt sind.
Sobald alle Spieler RuneScape mit dem neuen Client spielen können, werden wir uns überlegen, welche dieser Entwicklungen wir bei RuneScape einführen können.
Das wäre gesagt, also los geht‘s!
Normal Mapping und erhöhte Texturauflösung
Wahrscheinlich ganz oben auf unserer Wunschliste für neue Features wäre das sogenannte Normal Mapping und hochauflösende Texturen. Diese beiden Verbesserungen zusammen würden visuell den größten Unterschied machen, nachdem NXT veröffentlicht wurde.
Durch Normal Mapping würden wir mehr geometrische Details in Form von Normalenvektoren bei Objekten erhalten, die momentan sehr flach aussehen, wenn sie beleuchtet sind. Dadurch würden wir gleichzeitig auch mehr Belichtungsdetails erhalten, vor allem mit dem neuen Belichtungsfeature, das Normalenvektoren als Input nimmt (i.e. Irradiance, Ambient Occlusion, verbesserte Spiegelungen etc.).
Beim Normal Mapping erwarten uns jedoch zwei Hauptherausforderungen. Die erste ist das massive Unterfangen, diese Hochauflösungsversionen von allen existierenden Modellen in RuneScape zu erstellen, von denen es viele gar nicht gibt! Die zweite Herausforderung wird es dann sein herauszufinden, wie wir sie vorsichtig im Spiel einbetten können, ohne das visuelle Gesamtbild zu zerstören. Dann muss man noch die erhöhte Prozessorspeicherbelastung beachten, aber dies sollte nur Spieler mit sehr alten Computern betreffen.
Die zweite Texturverbesserung würden wir dadurch erreichen, dass unsere Künstler Texturen mit höheren Auflösung verwenden können. Größtenteils können unsere Künstler momentan nur Texturen mit einer Auflösung von 128x128 herstellen, was ziemlich niedrig ist für ein modernes Spiel, vor allem, da einige von ihnen Texturen im 4.000er-Bereich nutzen! Selbst wenn wir die Auflösung bloß auf 256x256 erhöhen, hätten wir schon viel mehr Oberflächendetails, mit denen wir spielen können. Ich persönlich würde uns jedoch gerne auf eine noch bessere Auflösung bringen. Die Herausforderungen hierbei sind dieselben wie beim Normal Mapping: die Produktion von Hochauflösungstexturen, erhöhte Prozessorspeicheranforderungen und Kontinuität im Spiel.
Ein besseres Animationssystem
Schon seit einiger Zeit arbeiten wir an einem neuen Produktionsprozess für Animationen. Hierdurch werden wir endlich Programme wie beispielsweise Maya, die in der Industrie Standard sind, nutzen können, um unsere Animationen herzustellen. Das bedeutet, dass wir dann nicht mehr auf unsere alten Animationsprogramme und -prozesse angewiesen sind, die mittlerweile recht überholt und mühselig sind und ineffektive Daten produzieren können. Der neue Prozess würde ein besser integriertes und miteinander verbundenes System für die Animationen bedeuten, aber die große Herausforderung hierbei war es, eine automatische Umwandlung all unserer existierenden Animationen ins neue Format zu erreichen, was eine ziemliche Meisterleistung ist!
Diese Änderungen werden die Arbeit für unsere Animatoren drastisch erleichtern, da Animationen momentan sehr lange dauern und umständlich zu produzieren sind. Weitere Verbesserungen sind ebenfalls nötig, um die Genauigkeit der Animationen von RuneScape zu erhöhen.
Eine von diesen Verbesserungen liegt im Übergang zum quaternionbasierten Animationsprozess, der die Framedaten beim Export nicht massiv quantisiert und während des gesamten Exportprozesses aus Maya alles im Fließkommaformat beibehält. Dadurch werden einige Grafikprobleme behoben und die Animationen viel flüssiger und effizienter zu produzieren sein.
Point Light Shadows und Percentage Closer Soft Shadows
Um unser vereinheitlichtes dynamisches Licht- und Schattensystem zu komplettieren, ist die Hinzufügung von Point Light Shadows unabdinglich. Ich habe bereits davon gesprochen, was es für eine Herausforderung war, unser voll dynamisches Sonnenlicht-Schatten-System reibungslos laufen zu lassen, während die Effekte alle gut aussehen. Dies wird auch bei Point Lights nicht anders sein. Es kann vielleicht sogar noch schwerer werden, da wir Schatten von vielen Lichtquellen unterstützen müssen, weswegen wir möglicherweise auf ein Deferred Shadowing System oder eine Tile-Based Rendering Pipeline (z.B. mit Forward+) übergehen müssen.
Es gibt auch Verbesserungen, die wir beim bestehenden Shadow Map Filtering durchführen können. Im Moment nutzen wir eine Reihe an Boxfiltern beim Abfragen von Shadow Maps, um die Illusion von sanften Schattenkanten hervorzurufen, was jetzt nicht unbedingt ideal ist. Percentage Closer Soft Shadows versuchen, Contact Hardening Shadows akkurat zu rendern, die basierend auf der Verdeckungsdistanz Schatten- und Halbschattenregionen aufweisen. Dies ist jedoch nicht günstig, weswegen es mal wieder ein Fall für gute Prozessoren wird.
Eine verbesserte globale Beleuchtung
Wie ihr in meinem vorherigen Blog vielleicht bereits gesehen habt, hatte das Hinzufügen von Irradiance und Ambient Occlusion bedeutende Auswirkungen auf die Beleuchtung in RuneScape. Die Frage ist nun, wie wir das noch mehr verbessern können.
Das neue System für die globale Beleuchtung ist eine massive Verbesserung gegenüber dem Java-Client, wir können es jedoch nicht wirklich noch bedeutend mehr verbessern. Wir könnten eine Kombination von Screen Space Directionel Occlusion (SSDO) und Large-Scale Ambient Occlusion nutzen, aber die Vorteile dabei wären minimal.
Der beste Schritt nach vorne ist es, die ganze Sache wirklich auf die nächste Stufe zu bringen. Dies würden wir durch Echtzeit-Lösungen für die globale Beleuchtung, die man Voxel Cone Tracing nennt, erreichen, was quasi eine hoch angenäherte Strahlverfolgung ist, um eine einzige indirekte Lichtabprallung aus der Szene zu bekommen. Die beste Umsetzung wird momentan von Nvidia GameWorks angeboten, sie benötigt jedoch sehr gute Prozessorfeatures, weswegen nicht viele Spieler Zugang dazu hätten.
Es gibt eine weniger teure Lösung in Bezug auf die Leistungsfähigkeit des Rechners, die als Cascaded Light Propagation Volumes (LPV) bekannt ist, welche auf mehr Computern laufen würde, aber hierbei sind die Qualität und Stabilität ein Problem, vor allem über weite Distanzen. Einige Spiele, die LPV nutzen, verwenden eine Hybridmethode, wo sie auf SSDO zurückgreifen, wenn LPV am Limit angekommen ist, was auch für uns eine Option sein könnte.
Verbesserte Reflexionen und Image-Based Lighting
Reflexionen im Spiel werden genutzt, um indirekte Spiegelglanzeffekte von der Umgebung zu simulieren. Im echten Leben weist jedes Objekt das bis zu einem gewissen Grad auf. Wie viel von der Umgebung von einem Objekt reflektiert wird, hängt davon ab, wie sehr die Oberfläche dieses Objekts glänzt. Screen Space Reflections und Parallax-Corrected Cubemaps sind zwei moderne Techniken, die um die Einschränkungen von Standard Planar Reflections und manuell gesetzten Environment Probe Reflections herumkommen wollen.
Die beste Möglichkeit für uns wird wohl in den Screen Space Reflections bei Modellen liegen, die momentan Environment Mapping haben, was auch Reflexionen auf gebogenen Oberflächen zulassen würde. Darüber hinaus wäre es toll, wenn wir dies mit Parallax-Corrected Cubemaps kombinieren könnten, aber das würde die Künstler mit einbeziehen und Änderungen an unseren Prozessen voraussetzen.
Physically Based Shading
Physically Based Shading (PBS) gibt es jetzt schon recht lange beim Rendern von modernen Spielen. Es ist der Name für verbesserte Belichtungsberechnungen, die versuchen die Art, wie Licht mit Gegenstandsoberflächen interagiert, so zu simulieren, dass es physikalisch gesehen korrekter ist als andere traditionelle Belichtungsmodelle, die von Spielen verwendet werden. Hierdurch erhält man außerdem Materialien und Texturen, die unabhängig von der Belichtungsumgebung funktionieren. Viele dieser Techniken wurden von den visuellen Effekten der Filmindustrie übernommen, wurden jedoch erst realisierbar durch die Ankunft moderner Prozessoren.
Ein weiterer suboptimaler Aspekt des momentanen Belichtungsmodelles von RuneScape ist der allgemeine Mangel an Spiegelungen, oder anders gesagt, wie wenig alles glänzt. NXT wendet nun immer eine Standardmenge an Specular Lighting in der Umgebung und bei Modellen an, falls unsere Künstler keine spezifischen Daten für diese angegeben haben, was die Belichtungsqualität bereits verbessert hat. Da dies jedoch überall angewendet wird, muss es recht subtil sein, damit die Welt nicht wie glänzendes Plastik aussieht.
PBS kann bereits bis zu einem gewissen Grad programmtechnisch erreicht werden, indem eine verbesserte Bidirectional Reflectance Distribution Function (BRDF) bei den Belichtungsberechnungen für das Rendern von Modellen und Umgebungen im NXT-Client angewendet wird. Ohne die Mitarbeit der Künstler wird man alle Vorteile davon jedoch nicht sehen können. Wenn die Zeit es zulässt, werden wir die Belichtungseinstellungen bei höherer Qualität vielleicht noch verbessern, gerade jetzt, da die neuen Grafikoptionen uns hierbei mehr Flexibilität einräumen.
Verbesserte Light Attenuation/Falloff und Flächenlichter
Die momentanen Modelle mit Point Light Attenuation und Falloff, die von RuneScape verwendet werden, sind nicht intuitiv für die Künstler und der Grund für viele Belichtungsfehler, die man in Java und in geringerem Maße auch im NXT-Client sehen kann. Der Übergang auf ein Modell mit Standard Point Light Attenuation/Falloff (oder ein physikalisch basiertes Inverse Square Falloff, wie Unreal 4 es verwendet) würde die den Light Falloff viel natürlicher machen und das Leben unserer Künstler deutlich verbessern. Das Problem dabei, dies zur Realität zu machen, liegt wie bei vielen Verbesserungen darin, wie man das bestehende Point Light System aktualisiert, ohne die existierenden Belichtungsumgebungen zu zerstören.
Flächenlichter (ungerichtete Lichtquellen) würden es den Künstlern erlauben, eine größere Kontrolle über die Gebiete zu haben, die vom Licht beeinflusst werden. Beispiele hiervon sind unter anderem Lichter mit einer flachen, rechteckigen Oberfläche. Flächenlichter sind auch nützlich beim Physically Based Shading. Die Herausforderung hierbei wäre die Integration in unsere Prozesse, die Engine-Unterstützung und das Trainieren unserer Künstler, damit sie sie effektiv anwenden können.
Verbesserte Partikel- und Billboard-Belichtung
Ein weiteres Feature, das ich gerne verbessern möchte, ist der Mangel an Belichtung auf Partikeln und Billboards. Realistisches Particle Lighting ist kein besonders gut gelöstes Problem in Echtzeit, aber es gibt Lösungen, die über einfache Lambertzerstreuung hinausgehen und die Dichte von Partikeln in Schatten mit einbeziehen, um Selbstschattierung und Lichtdurchlässigkeit zu simulieren. Kombiniert mit Partikel-Schattenwerfung würde man ein viel konsistenteres Aussehen einer Szene bekommen, mit dem zusätzlichen Vorteil, dass man denselben Partikeleffekt in verschiedenen Belichtungsumgebungen nutzen könnte.
Volumetrische Beleuchtung und God Rays
Ältere Spiele haben Aspekte von volumetrischer Beleuchtung wie God Rays (Sonnenstrahlen, die durch Wolkendecken fallen) modelliert, indem sie eine Single Post Process Technique verwendet haben. Wie schön das auch aussieht, ist es noch immer nicht gänzlich überzeugend, kann zu Grafikfehlern führen und ist auf nur eine dominante Lichtquelle limitiert.
Die beste einheitliche Lösung, um natürliche Phänomene wie God Rays zu simulieren, ist eine Technik, die als Volumetric Light Scattering bekannt ist. Es ist eine umfassendere Lösung, mit der man God Rays von verschiedenen Lichtquellen simulieren kann, also nicht nur von der Sonne, die gleichzeitig alle atmosphärische Streuungsvoraussetzungen mit einbezieht. Keine dieser Techniken würde viel Beteiligung der Künstler oder der Prozesse erfordern, wodurch sie ideale Kandidaten für die Verbesserung unserer existierenden Nebel- und Lichtstreuungsmodelle sind.
Vulkan, DirectX12 und Metal - oh je!
Bei den Rendering-APIs gibt es ein paar neue Mitspieler. Diese neuen APIs sind auf niedrigerer Stufe als die momentanen OpenGL und DirectX-Formate und bei ihren Interfaces eher konsolenartig, mit dem Ziel, den Grafikprozessor-Overhead zu reduzieren, wenn man Anfragen an APIs sendet, und das Rendering mit mehreren Prozessorkernen zu ermöglichen.
Es mag euch vielleicht überraschen, wenn ich euch sage, dass keine dieser neuen APIs mit einem direkten Port von OpenGL oder D3D euch viele Vorteile einbringen würden, vorausgesetzt alle Renderingprozesse werden von einem Thread durchgeführt. Wo sie jedoch wirklich glänzen, ist die Möglichkeit, Grafikprozessor-Befehlbuffer für Renderingprozesse mit mehreren Grafikprozessorkernen zu nutzen. Aber selbst dann, wenn eure Anwendungen bereits auf den Grafikprozessor gehen, werdet ihr im Allgemeinen keine großen Leistungsverbesserungen sehen. Bei den meisten Computern, die NXT verwenden können, gehen wir hauptsächlich auf den Grafikprozessor, vor allem bei nicht ganz so guter Hardware.
Das heißt jetzt aber nicht, dass wir dies nicht unterstützen wollen. Die Wahrheit ist, dass wir es kaum erwarten können, uns zumindest in einer von diesen Möglichkeiten zu verbeißen. Alles, wo die Chance auf eine bessere Leistung besteht, ist wie Schokolade für uns Grafikentwickler! Von den Dreien wird wahrscheinlich Vulkan als Sieger hervorgehen, da mehrere Plattformen unterstützt werden. Zusätzliche Backends für DirectX12 und Metal hinzuzufügen, würde uns nicht viel Extra bringen und nur mehr Entwicklungszeit und Komplikationen für unsere Renderinglayer bedeuten.
Es wird jedoch nicht nur ein einfacher Fall des Hinzufügens eines Vulkan-Backends sein, sondern, wie ich bereits sagte, ein Rendering mit mehreren Prozessorkernen, wo die APIs richtig glänzen können, wofür wir unsere Renderingarchitektur überarbeiten müssten, damit dies möglich ist.
Verbesserter Einsatz von mehreren Prozessorkernen
Der NXT-Client nutzt zusätzliche Prozessorkerne, um Assets zu laden sowie für die Irradiance, Cache-Abläufe und Audio. Daher wurden die Ladezeiten im Spiel für die meisten von euch mit einem kraftvollen Prozessor bedeutend verringert. Dies wurde jedoch sehr fallbasiert für spezifische Systeme durchgeführt und zusätzliche Prozessorkerne werden größtenteils nicht genutzt, vor allem, wenn nichts lädt.
Wie greifen wir also auf mehr diese ruhenden Prozessorleistung zu? Was wir in der Zukunft entwickeln müssen, ist ein allgemeines Multikern-System. Mit so einem System können wir viel detailliertere parallele Verarbeitungsprozesse für Systeme verwenden, die sich hierfür eignen. Zwei Beispiele hierfür sind Animationen und Partikelaktualisierungen, die sehr prozessorlastig sein können und auch im NXT-Client noch in Einzelthreads ausgeführt werden.
Wenn wir die Unterstützung für Vulkan einführen, werden alle neuen Jobsysteme eine wichtige Rolle dabei führen, parallele Befehlsbuffer mit mehreren Prozessorkernen zur Realität zu machen. Dadurch würden wir dann sicherstellen, dass viele Prozessorkerne während des Großteils der Frames genutzt werden, wodurch wir eine massive Verbesserung bei der Prozessorleistung sehen würden.
Webbrowser-Untestützung
Den neuen Client im Browser laufen zu lassen, steht immer noch auf der Agenda, aber dies wird beim Launch aufgrund der momentanen Einschränkungen bei den Browsern noch nicht möglich sein (z.B. der Mangel an echten Threads, Unterstützung für Vector Instruction und WebGL 2.0). Die gute Nachricht ist jedoch, dass diese Features bis zu einem gewissen Grad in den Betaversionen der Browser bereits integriert sind. In der nahen Zukunft (hoffentlich bereits Ende 2016) werden diese Features allen zur Verfügung stehen. In dem Moment sollten wir auch eine Browserversion von RuneScape-NXT fertig haben, da wir bereits Betazugang zu diesen fehlenden Features haben, wodurch wir mit der Entwicklung weitermachen können, bis sie allen zur Verfügung stehen.
Größenveränderbare Interfaces
Viele von euch haben uns gefragt, ob die Interfaces von RuneScape in Zukunft auch auf Bildschirmen mit einer Auflösung von 2.000, 4.000 und 8.000 Pixeln richtig funktionieren werden. Im Moment funktionieren sie auf diesen hohen PPI-Bildschirmen nicht so gut, da alles basierend auf den exakten Pixelkoordination platziert ist.
Dies zu korrigieren, wird sehr viel Arbeit in Anspruch nehmen, und die ideale Lösung, normalisierte Einheitsplätze zu verwenden, um alles korrekt zu platzieren ist bei der Menge an Interfacekomponenten, die nach Maß entwickelt wurden, vielleicht nicht möglich. An die Sache werden wir vielleicht etwas unkonventionell herangehen müssen, um ein System zu entwickeln, dass die Interfaces basierend auf der Bildschirmauflösung skaliert.
Endanmerkung
Wir hoffen, dass NXT nur der Anfang ist. Nach der Veröffentlichung werden wir an diesen interessanten Features arbeiten können, um euch eine noch bessere und allumfassendere RuneScape-Erfahrung bieten zu können.
Vielen Dank für eure Aufmerksamkeit.
Mod Lordgit
Leitender Grafik-Programmierer