von Chris Maiwald (Krishty)
So soll es eigentlich nicht aussehen, ich brauchte aber einen hübschen Aufmacher für diesen Artikel
Hier möchte ich Ansätze zum Rendern des Sternenhimmels diskutieren und die Erfahrungen weitergeben, die ich beim Entwickeln meines eigenen Renderers gemacht habe. Sterne darzustellen hört sich einfach an – bis zu einem natürlichen, realistischen und optisch ansprechenden Ergebnis ist es jedoch ein langer Weg. Wenn man sich dann nicht nur normales Rendering sondern High-Quality-Rendering – rendern mit hohem Multisampling und der maximalen Bildqualität im Vordergrund – vornimmt, ist der Weg nicht nur lang sondern auch steinig.
Es handelt sich bei diesem Artikel nicht um ein Schritt-für-Schritt-Tutorial sondern um einen theoretischen Überriss. Ein Grund dafür ist, dass der Artikel mit allen Details, Erläuterungen und Quellcodes viel zu lang geworden wäre. Ein anderer Grund ist, dass solche Artikel umso schneller veralten und unbrauchbar werden, je konkreter sie sich auf bestimmte APIs und Codeteile beziehen.
Eine Demo gibt es hier.
Inhaltsverzeichnis
Der erste Teil befasst sich mit dem einfachen Rendern und mit der Suche nach geeignetem Ausgangsmaterial. Am Ende werde ich erklären, warum die bisherigen Ansätze in meinem Projekt nicht zum gewollten Ziel führten.
- 1.1 Was machen wir hier überhaupt?
- 1.2 Texturen oder Pixel?
- 1.3 Sterne sammeln
- 1.4 Sterne sind nicht genug
- 1.5 Alles umsonst?
Der zweite Teil stellt einen verbesserten, zeitgemäßen Ansatz vor und perfektioniert ihn.
- 2.1 Das Abtasttheorem
- 2.2 Pointsprites zu Hilfe
- 2.3 Dithering gegen Banding
Der dritte Teil präsentiert einige Screenshots meines Renderers und Tipps zur Implementation.
- 3.0 Ergebnisse
- 3.1 Tipps
1.1 Was machen wir hier überhaupt?
Wenn ich davon spreche, den Sternenhimmel zu rendern, beziehe ich mich ausschließlich auf die Sterne ohne Effekte wie Morgengrauen, Mondbahnen oder Sternschnuppen. Dieser Artikel erklärt das rendern des Sternenhimmels in seiner puren Form – wie er von einem hohen Berg oder im Weltraum sichtbar ist. Das macht sie für Weltraum-Shooter genauso nützlich wie für Flugsimulatoren oder First-Person-Spiele.
Sterne sind nicht nur für Weltraumspiele oder Spiele, die bei Nacht spielen, wichtig. In großen Höhen können sie am helllichten Tag sichtbar sein und die ersten Sterne schimmern schon während der Dämmerung. Gerade dann können sie eine Bereicherung sein – wenn die Sonne gerade untergeht und ein paar einzelne Sterne schwach am Abendhimmel leuchten wirkt die Szene sofort glaubwürdiger und stimmungsvoller.
Schlecht gerenderte Sterne können genau das Gegenteil bewirken. Fehlen die Sterne, sieht der Himmel zu leer und unnatürlich aus. Sind die Sterne zu groß und zu klobig oder zuviele, wirkt der Himmel erdrückend und einengend. Sind sie noch dazu so hell wie Laternen oder zu gelblich, wirkt das Ganze geradezu lächerlich dilettantisch.
Darum versuche ich hier möglichst nah an der Realität zu bleiben. Sterne können leicht farbig sein, aber auf keinen Fall zu stark (was, wie wir noch sehen werden, eine Frage des Tonemappings ist). Sie dürfen nicht größer als ein paar Pixel sein. Es muss viele schwach leuchtende und wenige stark strahlende Sterne geben und das ganze darf auf keinen Fall künstlich aussehen.
Alle vorgestellten Techniken haben gemein, dass sie auf normalisiertem Raum arbeiten. Das bedeutet, sie funktionieren nur richtig, wenn sich der Betrachter am Nullpunkt befindet und sich nicht bewegt, genau wie eine Skybox. Indem man aus der Transformationsmatrix die Einträge löscht, die für die Verschiebung zuständig sind, kann man erreichen dass die Boxen dem Betrachter überall hin folgen. Für ihn sieht es dann aus, als seien sie unendlich weit entfernt.
Abbildung 1: Ausschnitt des Nachthimmels in Valves Hit-Shooter Half-Life aus dem Jahr 1998. Man kann erkennen, dass man in die Ecke einer Cubemap blickt, auf welche die Sterne zu zu laufen scheinen. Außerdem wirken die Sterne für diese Auflösung zu groß und wenn man genau hinschaut, kann man die Handbewegung des Künstlers nachvollziehen.
1.2 Texturen oder Pixel?
Fast jedes Spiel hat seine eigene Art, Sterne darzustellen. Vor einem Jahrzehnt waren Cubemaps sehr populär (siehe Abb. 1) – das rührte daher, dass zu dieser Zeit meist die ganze Umgebung eines Levels, inklusive Bergen, Wolken, der Sonne und dem Mond, durch Cubemaps gerendert wurde und sich Sterne schnell als einzelne Pixel darauf auftragen ließen. Diese Methode hat einige Nachteile:
Zum einen reichen einzelne Pixel nicht aus um die Sterne zu rendern, weil die Pixel der Map in Richtung ihrer Ecken verzerrt werden. Um das auszugleichen, muss die Cubemap viel höher aufgelöst sein als die Anzeige, was einen recht hohen Speicherverbrauch bedeutet, der mit HDR-Daten noch steigt.
Weiterhin wirken die Sterne umso klobiger, je weiter man die Auflösung steigert – denn während alle anderen Kanten immer schärfer werden, bleiben die Sterne so unscharf wie sie die Cubemap hergibt. In auf der Quake-Engine basierenden Spielen, die vor einem Jahrzehnt für weitaus niedrigere Auflösungen ausgelegt wurden, kann man das recht deutlich erkennen.
Zuletzt können die Sterne vom Artist nur schwer frei Hand gesetzt werden weil man berücksichtigen muss, in den Ecken weniger aber dafür größere Sterne zu platzieren, damit dort keine Ballungen entstehen. Außerdem muss die Map unbedingt gefiltert werden, damit nichts verpixelt oder verwischt.
Abbildung 2: Ausschnitt des Nachthimmels in Bohemia Interactives Taktik-Shooter Operation Flashpoint aus dem Jahr 2001, einem der ersten Spiele mit einem realistischem Nachthimmel an dem man sich sogar orientieren konnte. Der Screenshot wurde Gamma-korrigiert, weil auch das Spiel gammakorrigiert arbeitet.
Das waren Gründe, mit fortschreitender Auflösung von der Cubemap abzurücken. Sterne als Punkte wurden populär – man speicherte die Position und Helligkeit der Sterne in einem Vertexbuffer und renderte jedes Vertex als einen Pixelhaufen fester, von der Perspektive unabhängiger Größe am Himmel (siehe Abb. 2). Diese Methode hat sich im Großen und Ganzen bis heute gehalten, weil sie sehr schnell und speicherschonend ist, die Sterne unabhängig von der Auflösung immer recht scharf sind und sie zudem kaum künstlerische Anforderungen stellt, sondern eine Sternliste schnell selbst generiert oder heruntergeladen werden kann. Der Grund, warum diese Entwicklung an die Auflösung gebunden war: Da die Sterne immer einen, vier oder neun Pixel groß waren, strahlten die Sterne bei niedrigen Auflösungen weitaus stärker als bei hohen. Wenn bei 640x480 Pixeln 1000 Sterne zu sehen waren, wurde es eng am Himmel und der Vorteil gegenüber Cubemaps verflüchtigte sich.
Auch in meinen Renderer hatte ich mich für Punktlisten entschieden. Eine Liste mit zufälligen Sternen war schnell generiert – und grauenhaft. Obwohl Sterne jeder Helligkeit vorhanden waren, in der Verteilung keine Muster auftauchten und die Anzahl der Sterne realistisch war, wirkte der Himmel extrem unnatürlich.
1.3 Sterne sammeln
Der Fehler war eben gerade dass die Sterne zu gleich verteilt waren, sowohl in Helligkeit als auch in Position. Vom Anblick der Sterne sind wir schwache Haufen, helle Einzelgänger und eine Konzentration entlang der Milchstraße gewohnt. Ich hatte sowieso vor, einen realistischen Sternenhimmel einzubauen, also begab ich mich direkt auf die Suche nach Sternlisten.
Meine erste Anlaufstelle war der Yale Catalog of Bright Stars. Es handelt sich um eine Datensammlung der 9110 Sterne des gesamten Himmels, die man mit bloßem Auge erkennen kann. Jedem Stern liegen Beschreibungen zur Position und zur Erscheinung bei und den Katalog gibt es als kostenlosen Download – für meine Zwecke ideal.
Schwierig ist es dann aber doch, die Daten aus dem Katalog zu verwerten. Zum einen müssen alle unwichtigen Daten heraus gefiltert werden – Name, Parallaxe, und so weiter. Das ist nicht so schwer, weil das Format dokumentiert ist (die Dokumentation findet sich auf der Download-Seite). Allerdings liegen diese Daten dann im falschen Endian vor und müssen erst geflippt werden. Außerdem sind es physikalische Daten – wer fertige Vektoren und Farben erwartet, irrt. Diese müssen nämlich aus vier Angaben rekonstruiert werden, nämlich der Deklination, der Rektaszension, der scheinbaren Helligkeit und der Spektralklasse.
Die Position eines Sterns als normalisierter dreidimensionaler Vektor ergibt sich aus seiner Deklination und seiner Rektaszension:
- Code: Alles auswählen
X = cos(Declination) * sin(RightAscension)
Y = sin(Declination)
Z = cos(Declination) * -cos(RightAscension)
Hier möchte ich noch eine Optimierungsmöglichkeit ansprechen: Anstatt Position und Farbe in 32-Bit-Floats zu speichern, kann man auch 16-Bit-Halfs verwenden – am schnellsten durch D3DXFLOAT16 und D3DXFloat32to16Array(). Bei 9110 Sternen im Katalog halbiert man die Größe des Vertex-Buffers so immerhin von 214 auf 107 KiB. Es schont Speicherplatz und kostet nichts – um Präzisionsverluste muss man sich keine Sorgen machen, Halfs können Sterne noch bis zu Auflösungen von rund 4000 Pixeln (bei 90° Blickfeld) pixelgenau auseinander halten.
Abbildung 3: Die aus einem Panorama erzeugte Cubemap mit der Milchstraße. Man beachte, wie kontrastreich sie ist – die Map wird erst im Shader abgedunkelt, um volle Bildqualität zu garantieren. Mehr dazu in der Diskussion zum Dithering.
1.4 Sterne sind nicht genug
Mit den echten Sternen sah der Himmel gleich um ein Vielfaches glaubwürdiger aus. Dennoch wirkte er seltsam steril, vor allem die Milchstraße fehlte. Des Rätsels Lösung: Wir sehen am Himmel nicht nur die sichtbaren Sterne sondern vor allem noch Sternhaufen (wie eben die Milchstraße), welche aus so vielen so schwachen Sternen bestehen, dass sie sich nur als Flecken abzeichnen und es nicht in den Bright Star Catalog schaffen. Das Universum ist zwischen den Sternen halt nicht schwarz, sondern milchig grau mit schwach erkennbaren Mustern.
Also musste ein Hintergrundbild her. Ich musste lange suchen, letztendlich habe ich aber eine Panoramaaufnahme der Milchstraße bei der NASA gefunden. Ich konvertierte sie mit einem passenden Tool – HDRShop hat eine Funktion dafür – von einer Atlastextur in eine Cubemap und habe die Farben in einem Fotoprogramm nachträglich aufgebessert. Ich weiß, dass ich mich anfangs gegen eine Cubemap entschieden hatte - die Tatsache, dass diese Map aber nur die groben Schattierungen der Milchstraße wiedergeben sollte erlaubte aber eine niedrig aufgelöste Map (128x128 Pixel Seitenlänge reichen für diesen Zweck! Siehe Abb. 3).
Diese Cubemap musste irgendwo aufgetragen werden, ich suchte mir dazu eine Kugel aus. Wer möchte, kann auch einen Würfel oder ein Tetraeder benutzen. Ich entschied mich für die Kugel weil ich mal gelesen habe, dass GPUs viele mittelgroße Dreiecke schneller verarbeiten können als ein riesiges, das sich über den ganzen Bildschirm spannt. Ich habe dahingehend keine Performance-Tests durchgeführt, darum ist diese Information ohne Gewähr. Jedenfalls ist der Shader denkbar einfach – er transformiert die Kugel und gibt die Eingangskoordinaten der Vertices an den Pixel-Shader weiter (weil der Betrachter in der Mitte ist, entspricht die Vertex-Koordinate gleichzeitig der Texturkoordinate in der Cubemap). Die Cubemap wird gesampled und mit einem Richtwert multipliziert, damit man die Helligkeit des Hintergrundbildes mit dem der Sterne abstimmen kann. Weil die Map niedrig aufgelöst ist, kann sie ohne anisotropen Filter gesampled werden.
Mit einem Fotoprogramm mussten die einzelnen Sterne aus der Cubemap entfernt werden, damit sie nicht doppelt - als Punkt aus dem Vertexbuffer und als Pixel der Cubemap - auftauchten. Ein unbearbeitetes, hochauflösendes Bild ist übrigens perfekt um sicher zu gehen, dass der Vertexbuffer deckungsgleich mit der Cubemap ist und dass man keine Seiten verwechselt hat!
Abbildung 4: Die Sterne und die Milchstraße von außerhalb der Kugel. Eigentlich ist der Himmel – wie auch hier – sehr farbenfroh, dass wir ihn nur in schwarz-weiß sehen liegt daran, dass unser Auge bei solchen geringen Helligkeit kaum Farben wahrnehmen kann.
1.5 Alles umsonst?
Nun, da Sterne und Milchstraße vollständig implementiert und ihre Farben und Leuchtstärken halbwegs realistisch umgesetzt waren, wollte ich den finalen Schritt umsetzen: Sternbewegungen mit Motion Blur. Mit der Sternbewegung kam dann allerdings die große Ernüchterung: Das Bild begann furchtbar unruhig zu werden. Obwohl die Sternbewegungen minimal sind, sind sie doch groß genug, um alle paar Zehntelsekunden einen Stern von einem Pixel auf den anderen "überschwappen" zu lassen. Weil das alle Sterne zu abwechselnd in ähnliche Richtungen tun, wabert das Bild.
Mein erster Gedanke: Antialiasing! Schnell hinzugeschaltet half es aber nicht, es verlagerte das Problem nur. Die Sterne rutschten nicht mehr von Pixel zu Pixel sondern von Subsample zu Subsample, weshalb ihre Helligkeit nun von Frame zu Frame flackerte. Bei langsamen Mausbewegungen grieselte und rauschte das Bild vor sich hin, und das trotz 8x Antialiasing… nichts half.
Testweise fügte ich Motion Blur hinzu – Sterne wurden nicht mehr als Punkte, sondern als Linien zwischen ihrer Position in diesem und dem vorherigen Frame gezeichnet – aber auch das funktionierte nicht wie gewollt. Sterne verschwanden wenn sie sich nicht bewegten. Wenn sie sich bewegten, tauchten kleine Lücken zwischen den Linien der einzelnen Frames auf. Schuld war eine kleine, aber folgenschwere Änderung der D3D-API von Version 9 auf 10, nämlich das Entfernen des Renderstates D3DRS_LASTPIXEL, der dafür sorgte, dass der letzte Pixel einer Linie immer gezeichnet wurde, auch wenn die Linie Nulllänge besaß. Ohne diesen Renderstate waren Linien von Nulllänge unsichtbar und in der Reihe des Motion Blurs fehlte der letzte Pixel.
Abbildung 5: Ausschnitt des Nachthimmels in Cryteks Ego-Shooter Crysis aus dem Jahr 2007. Man kann erkennen, dass alle Sterne mindestens zwei Pixel groß sind und hell leuchtende Sterne eine größere Halo besitzen als schwach leuchtende, die Sterne werden also definitiv als Sprites gerendert.
2.1 Das Abtasttheorem
Ursache des Flackerns und Waberns war das Nyquist-Shannon-Abtasttheorem, welches besagt, dass ein Eingangssignal mit mindestens der doppelten Frequenz abgetastet werden muss, um es exakt rekonstruieren zu können. In unserem Fall war das Eingangssignal der Stern, der vom Bildschirm abgetastet wurde um ihn in ein Bildsignal umzuwandeln. Die Frequenz, mit welcher der Bildschirm den Stern abtastete, war ein Pixel (eigentlich höher, wegen des Antialiasings, das unregelmäßige Raster machte das aber durch sein Flackern zunichte). Die Folge dieses Theorems ist: Wollen wir den Stern auf dem Bildschirm rekonstruieren, darf er nicht höherfrequent als zwei Bildschirmpixel sein. Weil Punkte nicht nur horizontal oder vertikal, sondern auch diagonal wandern können, müssen wir das sogar auf zwei Mal (Wurzel aus zwei) Pixel erweitern. Punkte müssen mindestens 2,8 Pixel im Durchmesser groß sein um nicht zu flackern! Interessanterweise ist das beim Rendern von Linien mit Antialiasing ein bekanntes Problem und der Grund dafür, dass es dafür eine separate Einstellung neben dem gewöhnlichen Multisampling gibt. Linien werden dann nämlich nach einer Methode gerendert, die das Abtasttheorem zu unterdrücken versucht.
Wie auch immer, bei dem Punkte-Problem halfen mir die Linien nicht weiter. D3D9 hatte noch eine Einstellungsmöglichkeit für die Größe von Pointsprites, die mir in dem Fall geholfen hätte, in D3D10 ist sie aber wegen der ähnlichen Funktion des Geoshaders weggefallen. Ich entschied mich also dazu, Pointsprites mit drei Pixeln Durchmesser zu rendern. Interessanterweise findet man dieselbe Methode in Crysis (siehe Abb. 5), man wird sich also auch dort mit der Thematik auseinander gesetzt haben – auch wenn die Tatsache, dass der Nordstern dort immer senkrecht am Himmel steht und die Sterne sich nicht bewegen im ersten Moment auf anderes schließen lässt
Abbildung 6: Die vergrößerte Stern-Sprite, mit Tesselierung in rot. Obwohl sie nicht größer als 3x3 Pixel auftauchen soll, ist sie 8x8 Pixel groß, damit der anisotrope Filter ein noch weicheres und regelmäßigeres Ergebnis erreicht.
2.2 Pointsprites zur Hilfe
Das Erzeugen von Pointsprites im Geoshader ist denkbar einfach. Man nimmt die Position des Vertex, verschiebt sie je einen Pixel nach links oben, rechts oben, links unten, rechts unten und erzeugt daraus je eine neue Vertex. Diese vier Vertices bilden einen Strip aus zwei Dreiecken, also einem Viereck entsprechend der Größe der Stern-Sprite (siehe Abb. 6). Der Geoshader fügt außerdem die Texturkoordinaten der Sprite und die Farbe des Sterns hinzu. Der Pixel-Shader muss nur noch die Textur an den übergebenen Koordinaten laden, in den Alphakanal der übergebenen Farbe schreiben und fertig ist die Sprite.
Wenn kein Geoshader zur Verfügung steht, kann man dessen Funktionalität im Vertex-Shader simulieren. Dazu muss man alle vier Vertices mit fertigen Texturkoordinaten und dem Sprite-Offset im Vertexbuffer speichern. Der Vertex-Shader berechnet dann die Position des Sterns und addiert das Sprite-Offset hinzu, so dass die vier Vertices an vier unterschiedliche Positionen gerendert werden. Nicht vergessen, von Punktlisten auf Triangle-Strips umzuschalten
An die Sprite-Textur habe ich besondere Anforderungen gestellt: Zum einen musste sie größer sein als der fertige Stern auf dem Bildschirm. Damit wird erreicht, dass der anisotrope Filter (16x) ein noch weicheres und regelmäßigeres Ergebnis erreicht. Wichtig: Der Filter kann nur mit Mip-Maps effektiv arbeiten, darum besitzt die Textur drei Mip-Levels. Weiterhin musste die Textur exakt punktsymmetrisch sein, dazu aber später mehr.
Es gibt zwei besondere Situationen die verdeutlichen, warum ich Alphablending benutzt habe: Einerseits kann ein Stern vor einem hellen Abschnitt der Milchstraße liegen – ohne Alphablending würde dann der schwarze Rand sichtbar werden und die Milchstraße verdecken. Andererseits könnten sich nahe beieinander liegende Sterne gegenseitig verdecken. In jedem Fall würden Artefakte auftreten, in letzterem auch Z-Flimmern weil sich alle Sterne in exakt der selben Entfernung vom Betrachter befinden, Teile der Milchstraße je nach genutztem Mesh vielleicht auch. Das Alphablending muss additiv eingestellt werden, damit Sterne ihre Umgebung ausschließlich aufhellen, nicht aber abdunkeln können. Der Vollständigkeit halber: Es gibt bei additivem Blending auch die Möglichkeit, Premultiplied Alpha einzusetzen. Für was man sich entscheidet ist für das Ergebnis egal.
Zu guter Letzt habe ich noch eingebaut, dass Sterne der scheinbaren Helligkeit -2 mag doppelt so groß werden wie Sterne von 6 mag und dass dazwischen linear interpoliert wird. Im Stillstand und bei leichter Bewegung war das Ergebnis tatsächlich sehr gut und völlig weich und flimmerfrei, aber noch unfertig, denn ich wollte ja noch Motion Blur einbauen.
Abbildung 7: Die gestreckte Stern-Sprite. Blau markiert die Bewegung des Sterns, rot seine Tesselierung. Ganz unten acht überblendete Frames von einem Stern, der sich nach rechts bewegt – die Strecke wird deutlich unterbrochen.
Motion Blur sollte Sterne, die sich schnell bewegen, strecken. Hier stieß ich aber schnell auf ein Problem: Die gestreckten Sprites mehrerer Frames passten nicht mehr aneinander und bildeten Lücken (siehe Abb. 7). Die Sprite musste also für den Motion Blur in ihrer Mitte unterbrochen und dann monoton gestreckt werden. Nach einer Modifikation spuckt der Geoshader nun sechs statt zwei Dreiecken aus und die Sprites fügen sich lückenlos aneinander (siehe Abb. 8 ). Bei all dem darf nicht vergessen werden, die Leuchtkraft des Sterns abzuschwächen, sonst wird der Himmel in Bewegung heller! Die beste Methode ist zugleich die physikalisch korrekte: Die Oberfläche der Sprite auszurechnen, durch die Normalgröße eines Sterns zu teilen – also die relative Fläche der Sprite zu berechnen – und die Helligkeit durch diese zu teilen. Man kann auch mit der Wegstrecke zwischen der aktuellen und letzten Position des Sterns rechnen, dann muss man jedoch den Sonderfall berücksichtigen, dass er sich um weniger als einen Pixel bewegen kann.
Abbildung 8: Die verbesserte, gestreckte Stern-Sprite. Blau markiert die Bewegung des Sterns, rot seine Tesselierung. Ganz unten erneut acht überblendete Frames von einem Stern, der sich nach rechts bewegt – diesmal ist die Strecke ununterbrochen.
Zuletzt muss ich noch erklären, warum ich unbedingt eine punktsymmetrische Sprite haben wollte. Auslöser ist der Motion Blur: Wie gesagt bewegen sich die Sterne extrem langsam über den Schirm. Es kann deshalb passieren, dass von Frame zu Frame eine Bewegung erkannt wird oder nicht. Der große Unterschied zwischen keiner Bewegung und einer minimalen Bewegung sind die Achsen der Sprite: Ohne Bewegung sind sie an den Bildschirmachsen ausgerichtet, mit Bewegung sind sie an der Bewegungsrichtung ausgerichtet. Je nach Bewegung flackert die Sprite also zwischen rotiert und nicht rotiert hin und her. Damit dieses Flackern nicht auffällt, muss die Sprite punktsymmetrisch sein.
Abbildung 9: Zwei Screenshots der Plejaden, links ohne und rechts mit Dithering. Unten jeweils eine 4 × größere und 6,4 × kontraststärkere Version. Dithering kann das Banding vollständig aufheben, obwohl es Pixel nur um höchstens einen Prozent (durchschnittlich halb soviel) verändert und unter Einsatzbedingungen quasi unsichtbar ist.
2.3 Dithering gegen Banding
Der Bildschirm hat nur eine begrenzte Farbtiefe. Beim Sternenhimmel grenzen wir diese Farbtiefe noch weiter ein: 95% der Pixel (nämlich alle, die zu keinem Stern gehören) werden unter einer Helligkeit von 5% liegen. Das bedeutet, dass für die Darstellung der Milchstraße gerade einmal 12 Helligkeitswerte pro Kanal zur Verfügung stehen! Man kann deshalb, ganz besonders wenn sich das Bild langsam bewegt, deutlich die Grenzen zwischen den einzelnen Farben erkennen (siehe Abb. 2, 9). Diesen Effekt nennt man Banding. In meinen Beispielen liegt es nicht an der Textur – ich habe für die Milchstraße schließlich extra eine kontraststärkere Version gewählt, die im Shader abgedunkelt und in ein Float-16-Rendertarget geschrieben wird – sondern einzig und allein an der Farbtiefe des Ausgabegeräts. Da wir die Farbtiefe nicht frei wählen können (mehr als 8 Bits pro Kanal können lediglich ATIs Profi-GPUs wie die FirePro-Serie ausgeben, dann auch nur über spezielle Anschlüsse) müssen wir das Banding von Hand bezwingen. Die beste Methode dafür ist Dithering.
Dithering fügt kleine Fehler in das Bild ein, die sich über mehrere Pixel betrachtet wieder gegenseitig aufheben. Zwar sind viele Dithering-Algorithmen für die Implementierung in Hardware geeignet, für superparallele Architekturen wie heutige GPUs bleiben allerdings nur wenige zur Auswahl. Ich habe mich für gleichverteilten, zufälligen Noise entschieden. Das ist zwar eine der am wenigsten effektiven Methoden, sie lässt sich aber recht einfach implementieren. Es ist wirklich wichtig, dass der Noise gleichverteilt ist, damit möglichst viel Bildinformation erhalten bleibt. Meinen Algorithmus könnt ihr in diesem Thread nachlesen.
In meinem Renderer habe ich Dithering mit einer Stärke von ±1/255 angewendet – das bedeutet gerade mal einen Prozent Abweichung vom ungefilterten Bild (im schlimmsten Fall, durchschnittlich nur die Hälfte), die sich außerdem über mehrere Frames ausgleichen und ab 30 fps quasi unsichtbar sind. Dafür sind absolut keine Farbabstufungen mehr sichtbar (siehe Abb. 9) – insbesondere in Bewegung wirken die Farben weniger abgehackt und das Bild bleibt dennoch gestochen scharf. Meiner Meinung nach wird das Bild durch Dithering sogar noch natürlicher und wärmer, das ist aber Geschmackssache. Weil nicht nur die Milchstraße, sondern auch alles andere was man rendert davon profitieren kann, sollte man das Dithering als Post-Process-Effect auf den Frame anwenden, als allerletztes bevor er zum Bildschirm geschickt wird.
3.0 Ergebnisse
Für diese Screenshots habe ich einen Tonemapping-Operator improvisiert, der halb-halb zwischen Farbe und Grau interpoliert (um zu simulieren, dass das Auge bei so geringer Helligkeit kaum Farben wahrnehmen kann) und anschließend die Farbkanäle RGB auf 80%, 95% und 100% skaliert (um das leichte Blau der Nacht zu simulieren).
Die Helligkeit der Sterne habe ich über 180 * 5 ^ ((-0.4 Magnitüde) – 1.4) berechnet. Im Postprocessing habe ich die Helligkeit skaliert um euch vielseitige Screenshots zeigen zu können.
Die Screenshots wurden auf einer ATI Radeon HD 4850 in 1024x768 mit 16-fachem anisotropen Filter und ohne Antialiasing aufgenommen. Der Renderer funktioniert also auch dann noch perfekt, wenn man aufgrund von Speicherbedarf oder schwacher Hardware keine hohen Multisampling-Levels zur Verfügung stehen hat.
Meine Methode ist ausschließlich GPU-basiert und stellt, abgesehen vom Geoshader, keine hohen Ansprüche: Es gibt weder komplexe Geometrie noch hoch aufgelöste Texturen. Die Framerate lag durchgängig bei 800 bis 1200 fps, ich habe mittlerweile – mit einem neuen Renderer und gemäß diesem Paper optimierten Shadern – durchgängig 1500 bis 2000 fps erreicht. Das Optimierungspotenzial ist wegen der simplen Shader zwar nicht sehr hoch, aber allein das Culling nicht sichtbarer Sterne im Geo-Shader hat 6% Performance-Schub gebracht.
Ich habe ebenfalls keinen Motion-Blur für die Milchstraße implementiert. Weil sie schwächer strahlt als die Sterne und eh sehr niederfrequent ist, habe ich das nicht als nötig erachtet. Auch hier gilt: falls du das implementierst, schick ein paar Screenshots
Screenshot 1: Blick auf die Milchstraße bei ca. 110° Blickfeld. So hoch sollte die Helligkeit in praktischen Anwendungen nicht eingestellt sein, hier demonstriert sie aber das Detailreichtum und die hohe Vielfalt an Sternen.
Screenshot 2: Blick auf den Nordstern bei ca. 90° Blickfeld. Links oben ist der Große Wagen zu sehen, rechts unten die Plejaden. Von links unten nach rechts oben schlängelt sich die Milchstraße.
Screenshot 3: Weitwinkel-Aufnahme der Milchstraße bei rund 140° Blickfeld. Die Kamera wurde von rechts oben nach links unten geschwenkt und dabei auf maximale Helligkeit eingestellt.
Screenshot 4: Weitwinkel-Aufnahme der Sterne im Zeitraffer. Im Zentrum ist der Nordstern – der Himmelsnordpol – um den sich alle Sterne im Verlauf des Tages zu drehen scheinen. Ein Viertel der Bildbreite nach links unten ist wieder der große Wagen zu sehen. Man beachte, dass sich schnell bewegende Sterne auch weniger dicht leuchten, die Leuchtstärke über den gesamten zurückgelegten Weg aber wieder stimmt.
3.1 Tipps
Wenn du einen solchen Renderer selbst implementierst, denke immer an eins: Die besten Effekte sind die, die einem nicht auffallen. Wenn man in einer klaren Nacht in den Himmel schaut kann man die Milchstraße gerade eben erkennen, in den meisten Nächten und im städtischen Gebiet sieht man aber nicht mehr als die hellsten 20 bis 200 Sterne. Es ist bei dieser Sache sehr leicht, ins Kitschige ab zu rutschen – eine strahlende, bunte Milchstraße quer über den Himmel kann super aussehen – aber auch hoffnungslos übertrieben und aufgedrängt. Gerade wenn man soviel Arbeit in sie und die Sterne gesteckt hat, neigt man dazu, sie über das gesunde Maß hinaus präsentieren zu wollen. Screenshots wie Nummer 1, 3 und 4 würde ich niemals in einem Spiel einbauen – Nummer 2 wäre das Maximum und auch nur, wenn die Szene eine sehr klare Nacht fordert.
Und vergiss nicht, dass alles im Vollbildmodus in einem dunklen Raum komplett anders wirkt, als wenn man es als Screenshot auf einer hellen Website mit weißen Streifen drumherum betrachtet!
Noch ein Wort zu den anderen Gestirnen. Wir mussten die Sterne wegen dem Abtasttheorem rund drei Pixel groß machen. Das ist gigantisch, auch wenn man es nicht merkt weil wir Menschen die Größe der Gestirne immer falsch einschätzen. Zum Vergleich: Die Sonne hat einen scheinbaren Durchmesser von 0,54°, bei einer Auflösung von 1280x1024 Pixeln wäre sie also nur 8x8 Pixel groß. Wenn man bedenkt, dass ich helle Sterne auch größer habe aussehen lassen – bis zu 6x6 Pixel – dann sieht bspw. Sirius fast so groß aus wie die Sonne! Mach die Sterne also nur größer, wenn du nicht anders kannst. Wenn du mit niedrigen Auflösungen arbeitest, schwäche die Sterne ab oder mache Notfalls die Sonne und den Mond (die beiden haben den selben scheinbaren Durchmesser) ein wenig größer (in den meisten Spielen sind sie eh übertrieben groß ). Mit steigenden Auflösungen zukünftiger Bildschirme wird dieses Problem aber verschwinden.
Außerdem soll man nach diesem ATI-Paper das Rendern der Skybox so weit wie möglich nach hinten schieben, weil es performanter ist. Wenn das für einfache Skyboxes gilt, gilt das für einen komplexeren Hintergrund wie ich ihn hier vorgestellt habe wohl erst recht.
Ich hoffe ich konnte denen, die Sterne in ihren Renderer einbauen möchten, mit diesem Artikel einen guten Einstieg in die Thematik und einen detaillierten Überblick über die vielen Fallstricke geben.
Falls es noch irgendwelche Fragen, Verbesserungsvorschläge, Lob oder Kritik gibt, scheut euch nicht es hier zu posten
Zusätzliche Stichwörter: Milky Way, Galaxy, Star Rendering, Starfield Rendering, High-Quality Rendering, Sterne rendern
