In Anbetracht dessen, dass wir uns in absehbarer Zeit mit mindestens zwei Flugsimulatoren herumschlagen dürfen, die auf dieser für Flugsimulatoren neuen Technik aufsetzen, dachte ich, dass es mal an der Zeit wäre einen kleinen Überblick in die Unterschiede und Gemeinsamkeiten der alten und neuen Rendering-Techniken zu werfen.
Ausgangslage
“Moment Mal”, mag sich so mancher denken: “Wieso mindestens zwei Simulatoren?” So mancher mag sich vielleicht an meine Meldung über die entsprechende X-Plane Ankündigung erinnern, doch dieser Technik hat man auch das eher merkwürdige Aussehen der DoveTailGames FlightSchool zu verdanken, was bei vielen etwas untergegangen ist.
Bei den bisherigen Flugzeugen liegt der Verdacht nahe, das man einfach Konvertierungen genutzt hat um ihnen ihr Aussehen zu geben. Erst die neue DA-42, die in Zusammenarbeit mit Alabeo entwickelt wurde, wird zeigen was das Rendering der FlightSchool bislang wirklich schafft. Sie scheint sich auch vom Aussehen erheblich besser in Szene zu setzen, wie ich auf einem ersten Nachtflug feststellen durfte:
Grundlagen der Computergrafik
Um zu verstehen, was die Vorteile der neuen Technik wirklich sind, ist es notwendig zu verstehen, wie die alte Technik überhaupt aussah.
In den Anfangstagen wurde noch Pixel für Pixel von der CPU berechnet und diese liefen mit gerade mal 1 MHz Taktfrequenz.
An wesentlich mehr als einfache Vektoren war da nicht zu denken.
Doch kaum wurden die Rechner etwas schneller kam man auf die Idee auch die Flächen zwischen einigen dieser Vektoren auszufüllen.
Mit dem Microsoft Flight Simulator 5 war man schließlich so weit, das man wirklich ernsthaft die Vektoren mit Texturen bespannen konnte.
Diese Bitmaps wurden zwar im Laufe der Zeit immer größer und komplexer, doch im Gegensatz zu gemalten oder gezeichneten Bildern ist es schwierig Schatten und Spiegelungen einfach in eine Textur zu zeichnen, da die Beleuchtungssituation sich jederzeit ändern kann.
Außerdem wäre es schön wenn man die eigentliche Bitmap häufiger wieder verwenden könnte. Daher kam man auf die Idee zusätzliche Effektbilder zu entwickeln. Diese stellten im wesentlichen Handlungsanweisungen für den Computer da, wie die Oberfläche auf das Umgebungslicht reagieren sollte.
Bei den Flugsimulatoren haben wir bislang die folgenden Fälle:
Specular Map: Diese legt fest, wieviel Umgebungslicht von der Oberfläche diffus reflektiert wird.
Normal Map: In welche Richtung wird das Licht zurück geworfen. Dies gibt der Textur zusätzliche Struktur. Kleine Erhebungen auf den Tragflächen oder im Rumpf werden auf diese Weise realisiert.
Dabei wird die verwendete Normal Map in der Realität mit Hilfe eines kleinen Tools aus einer anderen Map erzeugt: Einer Bump Map, welche die Erhöhungen und Vertiefungen der Oberfläche beschreibt.
Im FSX muss diese Map anschließend noch im Farbspektrum verdreht werden, damit die JPG Komprimierung die Daten nicht zu sehr beschädigt. X-Plane hingegen nutzt hier ein PNG, bei dessen Komprimierung keinerlei Informationen verloren gehen.
FSX und X-Plane speichern in dieser Datei auch gleich die Specular Map ab. Da man dafür in X-Plane einfach einen zusätzlichen Farbkanal nutzt (den Alphakanal der normalerweise Transparenzen steuert) sind die Daten in X-Plane genauer als im FSX.
Reflection Map: Wie stark wird die Umgebung reflektiert (metallisch). X-Plane unterstützt keine Reflection Map, während FSX mit ihr einen bösen Pseudo Renderer einsetzt, da ein echtes Rendering aus Zeitgründen gar nicht möglich ist.
Und das war es im wesentlichen auch schon, was bislang FSX, P3D und X-Plane an Shader Effekten einsetzen (es gibt vor allem noch verschiedene Transparenzeffekte).
Es gibt noch zahlreiche weitere Shader die zum Beispiel die Vektoren noch weiter verfeinern können und eine Vielzahl weiterer Effekte. Diese Maps sind recht einfach und konnten im wesentlichen auch schon von sehr frühen Grafikkarten mittels spezialisierten Pixeln oder Vertex-Shadern ausgeführt werden. Das war eine wesentliche Idee. Jede Map stellt einen Shader-Effekt dar und erst die Hintereinanderschaltung der einzelnen Shader ergibt das endgültige Objekt.
Probleme der klassischen Shader
Das brachte jedoch einige Probleme mit sich. So haben viele Shader auch Nebeneffekte. Andere Shader hatten dann die Aufgabe Fehler der anderen Shader zu korrigieren. Das heißt: Wenn man einen Shader änderte konnte dies Auswirkungen auf ganz andere Shader haben.
Die Shader wurden immer komplizierter, die Arbeitsweise wurde immer unübersichtlicher, doch man sah im Prinzip immer noch auf den ersten Blick, dass man ein Computerbild vor sich hatte.
Die Rückbesinnung
Schon Mitte der 90er gab es Überlegungen, ob man mit solchen einfachen Shadern wirklich auf dem richtigen Weg war.
Man fing also mit der Frage an, was bei der Beleuchtung von Körpern sich wirklich physikalisch an ihrer Oberfläche abspielt.
Die erste Frage die sich dabei stellt: Was ist überhaupt Licht.
Vereinfacht ausgedrückt ist es eine elektromagnetische Welle, wobei uns vor allem das sichtbare Licht interessiert, das sind Wellenlängen zwischen 380 und 780 Nanometern. Dieses Licht besteht allerdings nicht aus einem kontinuierlichen Strahl, sondern kleinen Paketen, sogenannten Photonen. Diese können praktisch nur mit Elektronen reagieren. Sie können entweder Elektronen aus ihren gewohnten Orbital lösen und auf ein anderes Energieniveau anheben, oder Elektronen fallen auf ein geringeres Niveau herunter und strahlen dabei die potentielle Energie in Form eines Photons ab.
Was in der Schule noch einfach klingt ist in der Realität jedoch weitaus komplizierter. In der Schule betrachtete man nur Atome, in der Realität sind jedoch Moleküle weitaus häufiger. Und dann gibt es noch eine Materialgruppe die überhaupt nicht ins Bild passt: Metalle.
Für das Physically Based Rendering teilt sich die Welt interessanterweise in zwei Welten auf: Metalle und Nichtmetalle, oder auch elektrische Leiter und Isolatoren. In Metallen liegen die Elektronen so nahe an der Oberfläche, dass sie leicht aus ihren Atom entwischen, aber auch wieder eingefangen werden können. Das ist entscheidend für die Reflektionsfähigkeit
Es ist auch tatsächlich so, dass alle Metalle 70-100% des empfangenen Lichtes reflektieren. Das besondere an dieser Reflektion von Metallen: das reflektierte Licht hat eine Farbe. Ein Beispiel dafür ist zum Beispiel Gold.
Die Isolatoren reflektieren dagegen häufig nicht mehr als 4% des empfangenen Lichtes, dieses ist jedoch immer weiß.
Wie immer bei dieser direkten Art von Reflektion gilt: Der Einfallswinkel ist immer gleich dem Ausgangswinkel, was im weiteren eine Rolle spielen wird.
Auch in Bezug auf das nicht direkt reflektierte Licht gibt es grundsätzliche Unterschiede zwischen Metallen und Nichtmetallen. Bei der diffusen Rückstrahlfähigkeit, man redet auch vom Albedo.
Bei Metallen werden derartige Lichtanteile nahezu vollständig absorbiert, das heißt diese Materialien haben ein Albedo nahe 0.
Bei Nichtmetallen bekommen wir hingegen ein wesentlich komplexeres Bild. Bestimmte Frequenzen regen das Material an und strahlen in unterschiedlichste Richtungen, auch in das Material hinein. Doch häufig genug strahlen sie dabei nicht den gleichen Typ von Licht ab, den sie empfingen, sondern sie stürzen auf dazwischen liegende Bahnen und erzeugen dabei häufig genug nicht sichtbare infrarote Strahlung, oder eine andere Farbe.
Das in alle Richtungen diffus abgestrahlte Licht ist also nicht mehr weiß, da bestimmte Frequenzbereiche absorbiert wurden.
Man kann also für jedes Material eine Farbe angeben, die sein durch Diffusion reflektiertes Licht hat. Doch dieses Licht ist nicht mehr scharf abgegrenzt sondern gestreut.
Weiter oben war schon erwähnt worden, dass beim reflektierten Licht Einfallswinkel gleich dem Ausfallwinkel ist. Doch dabei kommt noch eine andere Eigenschaft des Materials ins Spiel: Seine Oberflächenstruktur. Je nachdem wie rauh seine Oberfläche verändert sich die Verteilung des reflektierten Lichts.
Im folgenden Beispiel kann man den Unterschied recht gut sehen. Schlamm und Wasser sind nahezu identisch, wenn man von ihrer Glossness Map absieht, die in anderen Programmen auch als Microstructure bezeichnet wird.
Hier wird auch ein scheinbarer Widerspruch geklärt der vorhin bei der Reflektion eine Rolle spielte. Wir kennen alle Materialien die Licht reflektieren, aber keine Metalle sind, wie eben hier eine Wasseroberfläche. Vom Reflektionsvermögen sind der Matsch und das Wasser bei bescheidenen 5%. Doch durch die glatte Oberfläche hat Wasser beim Glossness oder Microstructure Wert 100%, der Matsch hingegen 16%.
Es erscheint nicht wirklich einleuchtend, dass das Reflektionsvermögen dabei so extrem niedrig ist. Doch dass ist der große Unterschied zur alten Technik. Dort hat man scheinbar gleich Phänomene zusammengefasst und hinterher war man nicht mehr in der Lage unter geänderten Bedingungen die Effekte auseinander zu bekommen. Man hat nicht gemessen, sondern sich auf die eigenen Augen verlassen. Hinter PBR stehen hingegen 20 Jahre Entwicklungsarbeit. Man hat versucht zu messen, was wirklich geschieht, daraus mathematische Modelle erstellt und diese versucht mit möglichst wenig Parametern zu beschreiben. Und dann kam der Kollege mit eigenen Messungen, eigenen Modellen und eigenen Beschreibungen, doch irgendwie sollte das ganze eine Einheit werden.
Wenden wir uns nun denletzten etwas abstrakt klingenden Wert zu: Fresnel. Dieser Wert beschreibt wie gut ein Material sich als Spiegel eignet. Praktisch jedes Material kann am Rand recht gut Licht reflektieren und die Umgebung spiegeln doch wenn wir uns vom Rand entfernen gibt es große Unterschiede.
Im Grunde basiert auch dieser Wert auf der Mikrostruktur und Reflektionsvermögen aber im Rahmen von Versuchen mit Materialbeschreibungen zeigte es sich, dass es sinnvoll war, diesen Wert separat anzugeben.
Zusätzliche Anforderungen
Erstens:
Der Energieerhaltungssatz muss erfüllt sein. Kein Material kann mehr Licht abgeben, als es selbst empfängt. Vor allem an dieser Anforderung zerbrachen die meisten klassischen Computergrafiken. Die Menge des direkt und indirekt reflektierten Lichts darf niemals größer sein, als die Menge des Lichts, das den Körper trifft.
Die Überprüfung dieses Wertes war in klassischen Workflows schwierig, doch unser Unterbewusstsein erkannte sofort: Da stimmt etwas nicht. Alles was diese Kugeln voneinander unterscheiden ist ihr Reflektionsvermögen.
Doch eine steigende Anzahl von Glanzpunkten erzwingt gleichzeitig, dass das diffus zurück gestrahlte Licht weniger wird .Licht das bereits reflektiert wurde, kann nun einmal nicht in das Material eindringen und von dort diffus reflektiert werden.
Zweitens :
Diese Berechnungen müssen in einem linearen Farbraum erfolgen. Das heißt das Programm muss HDR unterstützen und erst in einem späteren Schritt die realen Anpassungen unseres Auges berücksichtigen und damit der Grafik ein Gamma verleihen. Von der Mathematik her einleuchtend, doch unser Auge sieht nun einmal anders. Es nimmt keine sauber kallibrierten Messwerte auf, sondern es versucht sich auf die Lichtsituation einzustellen und danach die Unterschiede im Bild zu bewerten. Wir nehmen überhaupt nicht wahr das es nachts mit künstlichen Licht trotzdem weit dunkler ist als an einem verregneten Tag. Wir nehmen nicht wahr, wie weit sich unsere Iris geöffnet hat.
Drittens :
Auch die Verschattung der Objekte darf erst in einem weiteren Schritt erfolgen. Ambient Occlusion ist also keineswegs ein zusätzliches Feature, sondern eine Grundanforderung für PBR.
Viertens :
Das Modell beschreibt nur die Rückstrahlfähigkeit. Transparente und durchscheinende Materialien müssen anders beschreiben werden.
Von der Theorie zur Praxis
Die beschriebenen physikalischen Grundsätze waren an sich kein echtes Problem, nur wie sollte man auf dieser Grundlage eine allgemeingültige und einfache Materialbeschreibung erstellen? Wie sollten entsprechende Shader beschaffen sein? Auf diese Fragen gab es lange Zeit keine Antworten.
An der Stelle kam die normale Weiterentwicklung von Computerschaltreisen zur Hilfe. Aus diskreten, spezialisierten Vertex- und Pixelshadern wurden Multishader, damit man je nach Bedarf die Anzahl der Shader dynamisch anpassen konnte.
Für zusätzliche physikalische Berechnungen oder andere verteilte Berechnungen wurden die einzelnen Berechnungseinheiten immer größer und komplexer, während sich ihre bloße Anzahl inzwischen weniger deutlich erhöht.
Für diese mächtigen GPUs stellen auch komplexe Shader kein unlösbares Problem dar.
Dadurch kamen auch die großen Grafikkartenhersteller immer häufiger auf das Thema PBR zu sprechen. Und diese Bemühungen zeigten Früchte. Es entstanden für fast alle 3D Grafikprogramme freie Materialbibliotheken, durch die fast alle Designer zunächst von der schwierigsten Aufgabe befreit wurden: Wie beschreibe ich die Materialien, die in meinem Modell enthalten sind?Man hat jetzt Anhaltspunkte, wie im Vergleich das eigene Material aussehen könnte.
Auch die entsprechenden komplexen Shader liegen heute frei verfügbar und parametrisierbar vor. Dadurch sind diese hochaktuellen Verfahren auch für Programme mit einem überschaubaren Kundenkreis nutzbar.
Allerdings muss man auch ein paar Einschränkungen hinzufügen: Die dahinter stehenden Modelle beruhen zwar auf der realen Physik, die tatsächlich verwendeten Shader hingegen nicht. Auch diese verwenden in Wirklichkeit Specular Maps und Glossy Maps und so weiter, nur werden diese vollkommen anders verwendet und sind auch anders miteinander verschaltet. Daher dürfen in ihnen keine vorgeschalteten Highlights oder Schatten enthalten sein.
Derartige Informationen dürfen erst für die nachgeschalteten Ambient Occlusions bereit gestellt werden. Das heißt die Wiederverwendung bestehender Texturen und Modelle ist zwar möglich, sie ist aber mit einiger Handarbeit verbunden. Effekte die mühsam zusammen gebacken wurden, müssen nun sauber voneinander getrennt werden.
Durch die Parametrisierbarkeit und die unterschiedliche Verschaltung mögen zwar verschiedene Simulatoren die gleichen Shader verwenden, doch die gleichen Modelle dürften dennoch teilweise ein vollkommen anderes Aussehen erhalten. Die Portierung von einem Simulator zu einem anderen wird dadurch nicht notwendigerweise einfacher.
Wobei wir erst sehen müssen ob auch P3D diesen Schritt mitgeht. Spätestens damit wäre aber das Thema einfache Portierbarkeit vom FSX vom Tisch. Es dürfte primär davon Abhängen ob die echten Großkunden an diesen Thema ein Interesse bekunden. Da diese Techniken jedoch einfach und kostengünstig beschafft werden können, ist es nicht unwahrscheinlich.
Ein zusätzliches Problem stellt sich bei Flugsimulatoren zum Glück nur am Rand. Durchscheinende Materialien wie Papier oder Haut und echte Transparenzen wie in Glas werden durch PBR nur unzureichend beschrieben, dafür sind andere Shader von Nöten.
Um in Realzeit gerenderten Darstellungen ein glaubhafte Reflektionen zu gewährleisten, greift man sowieso auf einen Trick zurück: Man speichert einfach das zuletzt generierte Modell zwischen und nimmt dieses als Wertetabelle für das neue, noch zu berechnende Bild. Im Allgemeinen ist der Abstand der einzelnen Bilder so gering, dass wir diesen Unterschied nicht sehen.
Auch gibt es etwas übertriebene Erwartungen an die Geschwindigkeit der neuen Algorithmen. Es herrscht teilweise die Vorstellung das diese Berechnungen ohne Kosten auf der GPU stattfinden. Wenn man ehrlich ist sieht man in der DTG Flightschool wenig von den Vorteilen, während die PBR-Rendering Engine von Laminar noch viel zu langsam ist, als das man eine Auslieferung auch nur in Erwägung ziehen könnte.
Wenn sich jemand noch genauer mit dem Thema auseinandersetzen möchte dem sei als Einstieg das Tutorial der Marmoset-Seite ans Herz gelegt, von wo auch viele Beispielbilder stammen. Oder man sollte nach spezifischen Anleitungen für das gewünschte 3D-Programm suchen. Inzwischen werden die meisten Engines umgestellt oder sind bereits umgestellt.
Und zum Abschluß noch ein paar Bilder der DA-42 aus der FlightSchool.
Gegenüber den anderen Maschinen hat sie vom Aussehen her durchaus zugelegt, das Flugverhalten ist jedoch weit von Dan Klaue entfernt und auch sein GPS wird sich im Vergleich keine grauen Haare wachsen lassen. Die Flight School versucht zwar hier und da etwas andere Ansätze zu demonstrieren, aber bislang ist sie noch ein ziemliches Stückwerk.
Na da seid Ihr den Werbeabteilungen der Simulatorhersteller ganz schön auf den Leim gekrochen. 😉
PBR meint die Materialeigenschaften und ist nichts neues, das gibts schon im FS9 bei den Flugzeugen mit Specular, Glanz und (Pseudo)reflektionen. Im FSX kamen mit BumpMaps, FresnelRamp und verbesserten Reflections mehr Möglichkeiten hinzu und vorallem können dort alle Einstellungen über die Texturen und das sogar für jedes einzelne Pixel gesteuert werden. Die grösste weiterentwicklung wirds noch im Bereich der Reflektionen geben, indem diese in Echtzeit gerendert werden. Das restliche werden nur Details sein wo man nicht auf den ersten Blick erkennt.
Beim X-Plane wird der Sprung natürlich grösser sein, da dort bisher die Möglichkeiten noch sehr eingeschränkt sind, z.B die fehlenden Reflektionen, so lassen sich Glas oder polierte Flächen kaum realistisch darstellen. Oder die Specularmap mit nur einem Farbkanal. Im FSX ist die nicht wie oben im Text geschrieben in der BumpMap enthalten, sondern es ist eine separate Textur mit allen drei Farbkanälen plus dem Alphakanal für die Glanzstufe. Damit lassen sich sogar Perlmutt-Lackierungen erstellen.
Soll jetzt keine Kritik sein, aber manchmal wäre es besser wenn man auch versteht über was man schreibt.
Dem muss ich jetzt allerdings recht entschieden widersprechen.
Wie üblich haben wir es im Computerbereich mit zwei vollkommen unterschiedlichen paar Schuhen zu tun: Das Userinterface und die dahinter stehenden Hintergründe.
Die Vorstellung , dass es im Grunde alles nichts neues wäre kommt aus dem User-Interface.
Doch dahinter steckt wie üblich jede Menge Marketing.
Es ist so ähnlich wie in den Computersprachen der UNterschied zwischen C++ und Java.
Von der Oberfläche her ähnlich, doch in ihren Hintergründen basieren sie auf vollkommen unterschiedlichen Schulen. Java ist abgesehen von einen Fehler Typsicher, ein Begriff der in den Ansätzen von C++ überhaupt nicht interessierte, denn er hätte ein Einschränkung dargestellt.
Genauso ist der Unterschied zwischen den alten Shadern und PBR.
Wobei ich schon bei der Beschreibung der alten Shader und dem FSX bewußt die Handbremse anzog, genauso wie ich im X-Plane bestimmte Maps vollkommen ausblendete.
Der Materialienbegriff kommt zwar sowohl im FSX, wie auch in den Shadern vor, aber in Wirklichkeit ist es nicht mehr als eine einfache Schublade, genauso wie heute fast alle Fileformate nur noch abstrakte Container sind, die an sich wenig über den Typ und die benötigten Fähigkeiten aussagen.
Der FSX entstammt einer vollkommen anderen Vergangenheit und das zieht sich nicht zuletzt bis ins Grafiksystem durch. Dort ist so manches nicht wirklich sauber durch ein Shadersystem zu erfassen, weil dort vieles vereinfacht und optimiert wurde, wie man es damals ausgedrückt hätte, während man heute es eher so umschreiben würde, dass man sich dort etwas zusammen gehackt hat. Das Grafiksystem war in weiten Teilen nicht auf GPUs ausgelegt, oder um genauer zu sein: Es war nicht auf solche Systeme wie Vexel und Pixelshader ausgelegt.
Die Idee, die gesamte Grafik im Grunde durch die GPU erzeugen zu lassen, stand hier noch nicht einmal auf dem Plan.
Daher musste man sich auch mit bestimmten Codeabhängigkeiten der GPUs erst gar nicht auseinandersetzen. Diese mögen bestimmte Arten von Code überhaupt nicht.
X-Plane war ist an der STelle schon ein vollkommen anderes Kaliber, nicht zuletzt X-Plane 10, denn dessen Grafiksystem ist in Wirklichkeit im Vergleich zu X-Plane 9 entkernt worden.
Daher rühren auch einige der scheinbaren Einschränkungen von X-Plane. Ben Supnik hat sich nicht ohne Grund als Grafik-Nerd geoutet.
Er hat sich nicht ohne Grund geweigert solche Dinge wie Reflektionen in X-Plane einzubauen. Zu X-Plane 9 Zeiten hätte es den Code hässlich gemacht und in X-Plane 10 genau betrachtet das Shadermodell zerrissen.
Die Reflections im FSX haben nichts mit einem echten Shader gemein, aber viel mit den Ansätzen aus denen Shadermodelle entwickelt wurden. Ich kann Bens Abneigung durchaus verstehen. Es ist in etwa so: Dieses Blut will ich nicht an mir kleben haben.
Damit kommen wir zu der eigentlichen Revolution die hinter PBR steht. Wie ich schon schrieb sind die echten Ansätze auf die Mitte der 90er Jahre zurück zu führen, doch in Wirklichkeit hatte man auch innerhalb der Computergrafikszene dieses Konzept nicht vor 2010 auf dem Schirm.
Das wirkich neue versteckt sich nämlich in etwas, was ich in meinen Artikel wohlweislich verschwiegen habe: DIe dahinter stehende Mathematik! Nicht das ich sie auch nur in Ansätzen wirklich verstehe, doch das eigentlich problematische an dem ganzen Ansatz war schlichtweg, dass er in einer ganz anderen Welt spielte, als die damalige Lebenswirklichkeit der Computergrafik. Wie sollte man so ein mathematisches Wirrwarr jemals auf einem Computer wirklich errechnen lassen?
Es hat Jahre gedauert bis sich daraus ein einheitliches mathematisches Gebilde formte, das auch tatsächlich die verschiedenen hinter ihm stehenden Ansätze in sich vereinigte. Das war die eigentliche Revolution die sich abspielte. Daraus schließlich ein Shadermodell zu bauen und das ganze dann auch noch so schön zu verpacken, das man es den Computergrafikern wirklich verkaufen konnte, war noch mal ein ganz eigener Prozess.
Jetzt jedoch sich hin zu stellen und zu behaupten, das ist nichts neues ist schon im Grundsatz falsch. Man hat das ganze so verpackt, dass die Leute glauben, dass sie nichts anderes machen, als sie es immer gewohnt waren. Es gibt nun mal nur eine begrenzte Anzahl von Möglichkeiten bestimmte Dinge zu umschreiben. Das man da gerade im grafischen Umfeld auf einen optischen Ansatz mit Bitmaps verfällt ist naheliegend. Daher kommt es auch, dass in vielen Programmen bestimmte Maps vollkommen anders benannt wurden.
Einige versuchten sich an die Hintergründe anzulehnen, während andere Programme danach vorgingen: Was war der ähnlichste Ansatz den wir bislang genutzt haben.
Das was man an der Oberfläche macht, scheint ausreichend ähnlich zu sein, dass es nichts neues ist, aber was du damit ansteuerst ist ein vollkommen anderes Ding.
Bis 2010 war das ganze extrem obskur und nur einer kleinen Anzahl weniger eingeweihter wirklich bekannt, weil man nun einmal ein enormes mathematisches und physikalisches Rüstzeug benötigte um zu verstehen worüber dort überhaupt geredet wurde.
Dann wurden einige Leute aus der Shader Entwicklung darauf aufmerksam. Doch zunächst war es noch zu abstrakt. Sie brachten diese Spezialisten jedoch dazu das ganze ein wenig umzuformen, damit wurde es dann möglich auf diese Ansätze weitere Leute aufmerksam zu machen, die das neue erkannten und anerkannten.
Aus diesen Hintergründen stammt die tatsächliche Aufregung.
Was das Thema angeht: Wer sich damit auskennt. Sorry, ich habe tatsächlich einen etwas anderen Hintergrund, ich habe weder für den FSX noch für X-Plane wirklich Modelle gezeichnet. Ich komme eher aus der Richtung, dass ich CPUs und DSPs verstand, wobei aus letzteren nach und nach die Shadereinheiten entwickelt wurden. Ich bin Diplom-Informatiker und obwohl ich einige Matheprofs an den Rand der Verzweifelung brachte.habe ich aus diesen Veranstaltungendoch einiges mitgenommen. Allerdings konnte ich mich am Anfang des Studiums nur schwer für Informatik oder Physik entscheiden.
Daher komme ich wirklich aus einer ganz anderen Ecke, und habe tatsächlich im Schnelldurchlauf noch mal die Grundlagen vom FSX und X-Plane nachgeschlagen um dort keinen Unsinn zu erzählen. Was den FS9 und Konsorten angeht, muss ich zugeben, das ich zu dessen aktiven Zeiten wenig mit Flugsimulatoren am Hut hatte, eher mit solchen Dingen wie technische Zuverlässigkeit. Doch ich weiss genau aus welcher Ecke er kam und wie er weiterentwickelt wurde, wobei jede neue Version in weiten Teilen immer noch auf den Schultern der Vorgänger stand.
Ich weiß wie man damals programmiert hat und ich weiß auch warum man damals so programmiert hat, allerdings gehöre ich auch zu den Leuten denen man klar gemacht hat warum man so nicht programmieren darf!
Wenige Jahre später ging mir regelrecht der Hut hoch als ich im Elektrotechnikbereich sah wie man aktiv die Sicherheitsmechanismen der Compiler sabotierte, damit man weiter vor sich her basteln konnte, ohne auch nur einen Gedanken darauf zu verschwenden, dass diese Mechanismen aus guten Gründen da drin stehen.
Der MSFS stammt in Grundzügen aus einer Zeit wo an GPUs noch nicht einmal zu denken war. Der Abschnitt über die Computergeschichte war nicht ohne Grund drin.
Im weiteren Verlauf hat man immer wieder versucht neue Ansätze hinein zu bauen, allerdings sollte man nicht die Illusion hegen das damit diese Shader auch wirklich implementiert wurden.
Nicht das wir uns falsch verstehen, ich beschuldige den MSFS an dieser Stelle nicht. Es ist auch nicht so dass X-Plane zu der Zeit auch nur einen Deut besser war.
Die Dinger hatten damals Klinken drin, das ich mich beim Schreiben des Artikels gefragt habe, ob ich das überhaupt Shader nennen darf! Zum Teil wurde da nicht mehr und nicht weniger getan als Shader nachzuahmen.
Ich war ursprünlich auch kein X-Plane Anhänger. Ich hatte mich X-Plane erst zugewandt, als ich mich vom FSX abwandte, nachdem mir klar wurde, das der FSX in Wirklichkeit von der Codebasis her künstlich beatmet wurde. Bei X-Plane 10 machte man sich zumindest die Mühe erst mal ganze Bereiche zu entfernen und dann die Grundlagen des alten Modells in der Grafikengine neu aufzubauen.
Es war ja auch nicht so, dass die Entwickler des FSX ihren Code für toll hielten. Sie planten auch einen grundsätzlichen Neuaufbau ihres alten Codes um endlich einige Leichen zu entsorgen, als sie abgesägt wurden.
Dem Vernehmen nach setzten sie ja einen Teil der Pläne in Microsoft Flight um. Als das Programm herauskam gab es ja einige Aufregung ob dort Airliner Support vorgesehen war, oder nicht. Die Header deuteten ja ein wenig in diese Richtung, doch es gab Anzeichen, dass dies tatsächlich nur übernommene Header waren. Die Bestätigung dafür bekamen wir ja durch die enttäuschende Nachricht, das man entgegen der ursprünglichen Planungen nicht auf Microsoft Flight, sondern dem FSX Code aufbaute. Ich weiß noch nicht ob ich den Schritt als dumm oder mutig bezeichnen soll.Zumindest hat man durch den angekündigten Verzicht auf Kompatibilität etwas Raum zum atmen bekommen auch wenn im Moment noch vieles Stückwerk ist.
Und jetzt das ganze noch mal kürzer und kleiner, aber besser verständlich, wenn man die Grundlagen kennt:
Man war in der Lage ein mathematisches Modell zu bauen, das physikalisch die gesamten Grundlagen der Reflektion beschrieb.
Aber: Wie in der Physik üblich, sind es natürlich Differentialgleichungen, die dieses Modell beschrieben. Diese sind in sich zwar eine sehr gute Beschreibung physikalischer ZUsammenhänge, aber es ist schwer mit ihnen etwas zu berechnen.
In diesen Gleichungen steckt auch diese Abtrennung der Metalle. Je nachdem ob man einen Leiter oder einen Isolator hat, fallen ganze Bereiche der Formel heraus, das heißt sie werden entweder 0 (Addition) oder 1(Multiplikation).
Würde man versuchen diese Gleichungen in der GPU zu berechnen wären sie in einem Jahr noch nicht fertig.
Da kommt die Stunde der numerischen Näherungsverfahren, da steigen im Grunde bestenfalls ein paar Mathematiker durch, doch es ist möglich einfache Gleichungen zu bauen, bei denen gezeigt werden kann, dass sie innerhalb eines Wertebereiches die gleichen Ergebnisse liefern, wie eine bestimmte Differentialgleichung.
Erst mit diesen numerischen Verfahren können die Shader das Problem wirklich berechnen. Das heißt man hat eine Formel, von der man weiß, dass sie zumindest einen genau definierten Bereich der Ursprungsgleichung wiedergibt. Es sind also die physikalischen Zusammenhänge, ohne dass ich wirklich in der Lage bin, sie in dieser Formel wieder zu erkennen.
Nun ist aber noch das Problem die Eingangswerte dieser Gleichungen mit einem Modell zu verknüpfen, mit dem ich Leuten erklären kann, wie sie zu ihren Ergebnissen kommen können, ohne dass sie auch nur den Hauch einer Ahnung von den physikalischen Grundlagen haben, oder was diese Gleichungen so besonders macht.
Ein Experte für Computergrafiken muss nicht wirklich Ahnung von höherer Mathematik haben.
Genauso ist es für mich ein übliches Erlebnis gewesen, das mir ein Kunde in Photoshop mal schnell etwas zurecht klickte, dass mir das Hören und Sehen verging. Doch er versteht auch nicht, was Photoshop da wirklich gespeichert hat, was wiederum mein Job ist.
Warum ich wiederum auf das Thema FSX so etwas allergisch reagierte ist ein anderes Problem. Viele der Shadermodelle hinter den Grafikprogrammen waren und sind nicht direkt in Realzeit zu rechnen gewesen. Doch es sind gute Beschreibungen.
Der Flugsimulator versuchte nun natürlich diese für Shader ausgelegten Dateien und so umzusetzen, das er in der Lage war etwas zu erzeugen, was so _aussah_ wie diese Eingangsdaten.
Das ist an sich nichts böses und allgemein üblich, man muss nur die Grenzen kennen.
Das heißt in Wirklichkeit waren FS9 und FSX dazu erzogen mit Eingangsdaten klar zu kommen die bestimmte Programme erzeugten.
Das Problem von X-Plane ist ein anderes. Er arbeitet intern tatsächlich mit den gewünschten Shadern, bzw. er weist die GPU an dies zu tun, doch bei den schreibenden Programmen hat sich einiges getan.
Es ist mit Blender kostenlose Konkurrenz hinzu gekommen, die im Grunde das gleiche kann, aber etwas anders arbeitet. Nach Meinung von Experten sind diese im wesentlichen vom Funktionsumfang gleich.
X-Plane ist im wesentlichen an Blender angepaßt worden, weil eben große Teile der Community diese Daten nutzten.
Ein Grundproblem der FSX Designer, wenn sie ihre Daten in X-Plane einspeisen wollen ist, dass sie natürlich erwarten, dass der X-Plane diese Daten so umsetzt wie es im FSX der Fall ist.
Das ist jedoch nicht ganz einfach denn zum einen müssen die Eingangsdaten umgesetzt werden, das sie ihren entsprechenden Gegenstücken im Blender gleichen, zum anderen soll er aber auch berücksichtigen, was der FSX daraus gemacht hat.
Ich denke den letzten Teil können wir vergessen, das steht überhaupt nicht mehr zur Diskussion. Für X-Plane geht es jetzt erst mal darum die neuen Shader und die Worklows so weit zu verbessern, das sie unter Blender nutzbar sind. Danach kann man in einem zweiten Schritt sich daran machen einen Parser u schreiben der die Eingangsdaten der anderen Programme so weit umformt, dass sie auf das Blender Äquivalent kommen. Das heißt das zwei identische Modell in den verschiedenen Programmen so umgeformt werden, das die verschiedenen Eingangsdaten auch in X-Plane gleich aussehen.
Dem FSX jedoch im wesentlichen Featuregleichheit zu PBR zusprechen zu wollen ist ein starkes Stück.
Dann wäre man tatsächlich weit davon entfernt, was gerade wirklich abgeht. Ich habe soweit möglich ein neues Shadermodell, das die tatsächlichen physikalischen Prozesse nachahmt, die wirklich ablaufen. Zumindest die Differentialgleichungen und weitestgehend auch die numerischen Verfahren können also diese Probleme nahezu perfekt lösen. Die Probleme bestehen primär darin darin die Eingangsdaten und ihren Aufbau so weit umzuformen, das die Zeichner glauben zu wissen, was sie da tun.
Das ist nämlich eines der grundlegenden Probleme in diesen Bereich: es sind Quantenphysikalische Prozesse. Es heißt nicht umsonst in diesen Bereich: Wer dieses Thema verstanden hat und nicht erschüttert ist, hat etwas nicht verstanden. Diese Prozesse laufen nicht unbedingt so ab, wie unser Gehirn gelernt hat, wie Dinge ablaufen..
Wie die Shader programmiert sind weiss ich nicht, aber das was hier im Artilkel und im Link als “PBR” beschrieben wird und was ich im Netz sonst noch gefunden habe, genau das definiert man auch schon im Materialeditor des FSX-SDK. Und damit kenne ich mich aus. Die Neuigkeit wird darin liegen, dass der Anteil an reflektiertem Licht berechnet wird und somit nicht mehr zurückgeworfen werden kann als auftrifft. Aber das konnte man bisher mit nicht übertriebenen Reflection- und Specularmaps auch schon einstellen. Daher denke ich nicht, dass man an Objekten überhaupt grosse Unterschiede erkennen kann. Deshalb bleibe ich dabei, dass es wie schon immer vor allem Marketing ist und die grosse Revolution ausbleibt. Physikalische Berechnungen, das tönt natürlich immer gut, vorallem im Bereich von Flugsimulatoren.
Ich weiss nicht weshalb Du die Reflektionen des FSX so schlechtredest. Dort wird mit Cubemaps gearbeitet, das sind im prinzip Panoramabilder. Es ist eine gängige Technik wo häufig angewendet wird. Weshalb die im X-Plane noch nicht zum Zug kommt weiss ich nicht im Detail. Meine aber gelesen zu haben, dass es darum geht, inkompatibilitäten mit künftigen Versionen zu verhindern.
Entscheidend für das aussehen am Modell ist die zugrundeliegende Cubemap. Aus Performancegründen wird im FSX dazu eine statische Textur verwendet, die im Modell definiert wird. Im aktuellen P3d werden dynamische Cubemaps erzeugt, d.h. das Panorama um das Flugzeug wird in Echtzeit im Simulator gerendert. Ob man statische oder dynamische Cubemaps verwendet hat aber mit PBR nichts zu tun, und ob die Shader wo das Panorama auf das Obekt legen jetzt nicht wirklich shader sein sollen oder was auch immer, ist mir als Nutzer und Designer völlig egal, denn ich sehe auch ohne zu theoretisieren, dass Flugzeuge mit Reflektionen einfach besser Aussehen als ohne.
Nun, dann bastel uns mal kurz den FSX mit Star Citizen Grafik zusammen. Und erkläre uns warum so gut wie jede Spieleentwicklungsengine sich überschlug um PBR umzusetzen.
Das Problem besteht schlichtweg darin, das zwar die grundsätzlichen Design-Schritte sich kaum unterscheiden, wenn man davon absieht, dass du keine Schatten und Highlights zeichnen darfst, weil das die Shader für dich machen. Dynamisch und natürlich für mehrere Lichtquellen. Und zwar nicht auf der CPU, sondern in der GPU.
Du siehst ja in dem Artikel das Beispiel des Gewehrs. Was glaubst du wohl wie da die Specular Maps aussehen? Absolut einheitliche graue Farbflächen, weil sich das Material selbst ja gar nicht verändert.
( https://www.marmoset.co/toolbag/learn/pbr-conversion )
Sehr vieles was früher per Hand eingebaut wurde muss für PBR heraus oder wird eben überhaupt nicht eingebaut.
Die Eingabewerkzeuge sind zwar die gleichen, aber die Inhalte die sie beschreiben eben nicht und dabei erzielen die neuen Renderer gleichzeitig eine bessere Qualität.
Und das ganze wird natürlich in der GPU berechnet, das heißt mit dem vielfachen an Pixeflfüllraten, als es die CPU auch nur in Ansätzen erfüllen könnte. Der FSX macht mit der GPU bekanntlich denkbar wenig.
Hallo Karsten,
Auch von mir danke für den Artikel – und die Erinnerungen an die frühen Simulatoren! 🙂
Ein paar Kommentare:
Im FSX ist Specular kein Kanal der Bump/Normal Map. Das ist auch einer meiner Sorgenpunkte bei X-Plane. Zum einen sollte man so wenig wie möglich, wichtige Elemente in Alphakanälen unterbringen. Das macht dem Entwickler einfach die Arbeit schwer. Zum anderen sollten Texturen nach Funktion “sortiert” sein.
Mal angenommen, man stellt fest, dass man doch die Specular Map auf einer eigenen Textur braucht und einen entsprechenden Alpha Kanal dazu, um damit einen bestimmten Effekt zu erreichen. Dann müsste man entweder das wiederrum als Kanal einer anderen Textur hinzufügen, was ein furchtbares Chaos wäre, oder man muss nachträglich die Funktion der Kanäle ändern, dann bekommt LR nicht nur intern viele Probleme, sondern auch mit den Add-on Entwicklern. 🙂
Vielleicht habe ich Dich nicht richtig verstanden, aber auch mit PBR braucht man eine gut gestaltete, abwechslungsreiche Specular Map. Das ist auch in dem verlinkten Artikel zu sehen. Denn nur so bekommt man realistisches Material. Auch eine Farbinformation wäre sinnvoll, denn woher will die Engine wissen, dass die Instrumentenverglasung mehrfarbige Effekte hat, vorallem wenn man mit dem Finger auf selbige gefasst hat. Es gibt dafür durchaus noch mehr Beispiele, wie z.B. eine matt-schwarz lackierte Cowling, die durch das heisse Triebwerk vielfach erhitzt wurde. Die leuchtet stellenweise dann auch in Regenbogenfarben. 🙂
Ich gebe ThomW dahingehend Recht, dass die Unterschiede für den Laien teilweise nicht wahrnehmbar sind. Ob es wert war, über zehn Jahre auf “einfache Reflektionen” zu verzichten… 😉 Wenn man sich mal Engines wie die von “War Thunder” oder “DCS” anschaut, machen die feinen Unterschiede beim Shading allerdings einen enormen Unterschied. In “War Thunder” sind die Flugzeuge nicht so detailliert, wie unsere Add-ons, schauen aber trotzdem einfach toll aus. Mich fasziniert jedes Flugzeug-Modell und ich könnte es mir stundenlang anschauen.
Widersprechen möchte ich Dir bei Highlights und Ambient Occlusion. Ich dürfte der Erste oder zumindest einer der Ersten gewesen sein, der “Ambient Occlusion” von Hand bereits seit dem FS98 hinzugefügt habe. Heutige Renderer können das zwar automatisch berechnen, aber es gibt auch immer noch Möglichkeiten und Bedarf, das per Hand aufzubessern. Und eine Spielengine wird nicht akkurater sein, als ein “3d Renderer”. Eher gröber. Das sieht man auch bei den Bildern zu XP11. Die Modelle werden deutlich besser aussehen, wenn sie beides haben. Vorallem bei Detaills. Zumal wenn der Nutzer Ambient Occlusion deaktivieren muss, wenn es mit der Performance Probleme gibt.
X-Plane braucht dringend eine Veränderung beim Shading. Diese ewig grauen Flugzeuge sind wenig werbewirksam. So gut X-Plane bei Nacht aussieht, und die IXEG 737 im Cockpit, so abschreckend sind mittelgraue Flugzeugrümpfe in den Newsmeldungen und Produktscreenshots. Deshalb bin ich sehr gespannt auf die Veränderungen. Das Shading der Flugzeuge bei DTG Flightschool gefällt mir sehr gut! Ich denke, deren vollständiger Flugsimulator wird nicht schlechter ausfallen, als die Flugschule. 😉
Ich würde mir nur wünschen, dass man sich bei der Belegung der Texturen an den üblichen Standards orientiert. Das macht es dem Entwickler leichter, weil er nicht jedes Mal grübeln muss, welche Textur und welcher Kanel was macht. Außerdem gibt es tolle Programme zur Entwicklung von Materialien, auf die man dann zurückgreifen könnte. Und man könnte ohne viel Aufwand ein Objekt, das für eine andere Engine erstellt wurde, verwenden.
Ich hoffe auch sehr auf Height Maps. Damit könnte man an Flughäfen so viel machen, vor allem wenn sie auf die Simulatorphysik Einfluss haben. Oder, wie von mir oft geschrieben, ein Flussufer mit groben Steinen, die vom Wasser umspült werden, Sand- oder Kiesbänken mit Treibgut. Und dann eine Stelle finden, an der man sicher langen kann. 😉 Und weiter hoffe ich dann darauf, dass die Height Map kein Alpha Kanal der Lichttextur wird. 😉
Also ich glaube kaum, dass Ben irgend eine Absicht hat sich von anderen Programmen abzukoppeln. Er und ich denke auch Austin, weiß ganz genau, das man als kleine Firma an der Stelle nur davon profitieren kann, wenn man sich an die Standards anhängt.
Das entscheidende, dies ist im wesentlichen ein Standard.
Ein Standard auf den im Moment so ziemlich jede Gameengine aufspringt oder aufgesprungen ist, die aktiv an ihrer Engine arbeitet. Die gesamte Flugsimulatorszene ist im Vergleich ein nichts.
Nur diesen Standard gab es vorher nicht. Bis man eben so etwas wie den heiligen Gral der Computergrafikszene fand. Natürlich ist ein gewisser Hype dahinter, allerdings hat dieser Hype sehr reale Gründe.
Nur ist mit Grundlagen im allgemeinen kein Geld mehr zu verdienen. Deshalb ist es seit einigen Jahren mehr oder minder Standard, das man Mitarbeiter dran setzt bei einigen dieser Projekte mitzumachen.
Man kann damit zum &Teil sogar die Entwicklungsrichtung beeinflussen und es ist schlichtweg weitaus günstiger, als wenn man selbst solche Applikationen und Workflows entwickelt.
Es gibt immer noch mehr als genug Möglichkeiten sich von der direkten Konkurrenz abzuheben.Doch insgesamt fliueßt in diesen Bereich damit weit mehr Geld, als es sich ein Hersteller auch nur leisten könnte.
Das mit dem FSX auch nur vergleichen zu wollen.,.. Der FSX ist in Wirklichkeit auch nur Trends nachgetigert, doch das zu einer Zeit wo jeder im Endeffekt auch sein eigenes Süppchen kochte.
Dieser Hype stammte eben nicht aus der Flugsimulatorszene.
Wenn ich mich nicht sehr irre hatte auch Ben bei seiner Präsentation darauf hingewiesen, das es freie Tools zu diesen Thema gibt.
Genauso wie später bei der Soundengine die ebenfalls OpenSource ist und ebenfalls aus dem Umfeld der Game-Engines stammt.
Die Flugsimulator-Hersteller sind nicht zuletzt deshalb auf das Thema aufgesprungen, weil dort in der letzten Zeit,.im Moment und wohl auch in der nächsten Zeit mehr hochbezahlte Spezialisten ihre Zeit rein stecken, als sie selbst überhaupt an Personal haben.
Die Großen arbeiten dort mit, weil sie dort Standards beeinflussen können (ohne Sorgen zu haben, bei jeden Wort irgendwelche Patentklagen am Hals zu haben) die kleinen, weil sie dort lernen können wie sie die Dinger nutzen können.
Du hast mich wahrscheinlich nicht verstanden Karsten. Mir geht es um die Belegung der Texturen und deren Kanäle. Da wäre es schön, wenn man sich an Standards hält. Ich bin mit Ben in Kontakt und er kennt meine Sichtweise.
Ein Weg wäre, sich das Modell des Gewehres samt der Texturen (unverändert) in X-Plane einzubinden und an der Grafikengine so lange zu feilen, bis es wie in dem Screenshot oben rechts aussieht.
Dass Spieleengines sowohl FSX als auch X-Plane viele Jahre voraus sind, da stimme ich Dir zu. Aber der FSX hat jetzt eben schon 10 Jahre lang (einfache) Reflektionen, Specular Map und Specular Apha Channel (Falloff map), Fresnel Ramp, dazu die üblichen Kanäle für Transparenz, Emissive Map/Self-Illumination Map, Bump Map, Cubic Enviroment Map…
Und sehr, wirklich sehr viele Parameter inwiefern sich diese Maps beeinflussen können und verhalten sowie weitere Parameter für das Material. Damit kann man sehr viel machen, wenn man sich Mühe gibt.
Wie gesagt, man kann das aus Nutzersicht sehr gut vergleichen, denn er hatte jetzt zehn Jahre lang weiße Flugzeugrümpfe und je nach Add-on Entwickler sehr schönes Shading und Reflektionen. Von den Screenshots her, sind die Flugzeuge im FSX nicht so weit von Spieleengines entfernt. Das Wow-Erlebnis würde der Simulant erst beim Nutzen eines Simulators mit PBR haben, und auch nur dann, wenn die Features voll genutzt werden…
So ist es im Moment ja schon mit den Lichtern in X-Plane: Mit einem stillen Bild kann man nicht transportieren, wie toll das aussieht.
Beim AO würde ein im Modellierungsprogramm einberechnetes Shading immer noch besser aussehen, als das als das von der Spiele-Engine Erzeugte. Das ist nur ein Vorteil bei der großen Anzahl von Szenerien, bei denen die Entwickler bisher keine Schatten reingerechnet oder reingemalt haben… 🙂
Sehe ich wie Du auch. Allerdings baue ich in P3D Objekte auch jetzt weder Schatten noch lasse ich es rechnen. Das überlasse ich P3D selbst, weil es dies ja von Hause aus macht. Auch einer der Gründe warum ich nichts mehr für den FSX mache, denn dort würde man nichts sehen in dieser Richtung.
Wo ich allerdings generell vorsichtig bin, ist der Vergleich zwischen herkömmlichen Spielengines und dem Flugsimulator. Die Spielengines arbeiten alle auf relativ kleinem Raum mit wechselnden Inhalten. Ein weltweiter Simulator wechselt den Raum ständig, bei gleichzeitig wechselnden Inhalten. Des ist eine ganz andere Herausforderung.
Im Simulator erwartet man ständig die reale Welt zu sehen, in anderen Spielengines ist das nicht Vorrausetzung.
Der Flugsimulator ist eine Spieleengine. Provokant, aber wahr. Und die meisten Spielengines können nicht nur grafisch mehr, sie haben auch realistischer berechnete Physik. 🙂
Ich verstehe, warum Du so denkst. Aber der FSX hat vor zehn Jahren schon viel zu viel Hardware Ressourcen gebraucht. Wir sind der Zeit gefühlt 15-20 Jahre hinterher. Mehr Detaills bedeuten deshalb nicht, dass wir leistungsstärkere Systeme brauchen. AeroflyFS hat vor vielen Jahren schon gezeigt, dass man Luftbildszenerien ohne Ladezeiten haben kann, die selbst beim Tiefflug mit einer F-18 nicht nachladen müssen (ohne SSD). Ja, die Systemtiefe ist geringer und die Welt begrenzt, aber mit Systemen kann man die 10 Minuten Ladezeit der Luftbildszenerien im FSX (ohne SSD) dann auch nicht rechtfertigen. 🙂
Aktuelle Engines sind in der Lage eine immense Anzahl an Details anzuzeigen. Es ist alles eine Frage der Skalierung. Wenn man sich in einem Spiel in einem begrenzteren Areal bewegt, sind dort die Objekte, zum Beispiel Gebäude, wesentlich detaillierter. Und in den Gebäuden gibt es Zimmer, die eingerichtet sind. Andere Spiele generieren ganze Sternensysteme, bei denen man die Planeten besuchen kann.
Wenn man z.B. daran denkt, dass Graspisten in Zukunft mit 3d Gras bewachsen sind, ist das auch nur wieder eine Art von Autogen, wie sie in Spielengines schon lange genutzt werden. Es gibt Engines, die können absolut realistische Landschaften verschiedener Klimazonen automatisch und zufällig generieren und jeder Busch, jede Blume, jeder Stein und jeder Baum steht an einer Stelle, wo wir sie real auch erwarten würden.
Ein großes Problem im Moment ist in der Tat, dass nur sehr wenige Engines eine runde Welt simulieren können.
Ich denke die Antwort darauf ist ein Jein. Man darf nicht vergessen, dass das Spielfeld ein wenig größer ist als bei vielen anderen Spielen. Dann hat man diese Welt mit sehr vielen Häusern besetzen (was würde man ohne Indexing machen?), dann hat man halbtranzparente Wolken, Strassenverkehr, Klima, Terrain, Lichteffekte usw. Das ist schon eine gewaltige Anzahl an Effekten und teilweise werden die Shader nicht kompatibel sein.
Viele Spiele haben trotz weniger aktiven Shadern Performanceprobleme.trotz Budgets, von denen die Simulatorszene nur träumen kann.
Man kann die Spiele nicht direkt miteinander vergleichen. DCS wird wohl trotz allem besser aussehen können.
Mit tools wie dem WED ist man zwar auf dem richtigen Weg doch die technischen Anforderungen bei der Grafik sind auch enorm gestiegen.
Daher halte ich es für so wichtig das man sich jetzt bei PBR gut an Standards anhängen kann.
Man hat ganz einfach nicht die Zeit die Shader selbst zu entwickeln und zu optimieren, doch da PBR eben gerade State of the Art und wissenschaftlich fundiert ist schlägt das Ding nicht zuletzt im universitären Umfeld ein wie eine Bombe. Kostenlos, State of the Art, Freie Tools, industrielles Interesse = Drittmittel.
In dem ganzen Umfeld kann man recht gut angepasste Shader finden, gleichzeitig versuchen die Hardwarefirmen (NVidia) die Ideen und Techniken der Shader aufzugreifen und zu beschleunigen. Die neu ausgebildeten Designer werden zunehmend PBR-Spezialisten sein.
Ein wichtiges Argument für die PBR-Shader besteht nun einmal vor allem darin, das die Designer nicht nur bessere Ergebnisse liefern, sondern deutlich schneller fertig werden, nicht zuletzt dank größerer Nebenwirkungsfreiheit und klarer abgetrennter Zuständigkeiten.
Wobei ich sowieso einen verteilten Ansatz erwarte. Ich denke nur die Flugzeuge selbst werden die neuen Shader wirklich zu spüren bekommen. Dann vielleicht noch etwas für Flughäfen oder Landmarks und der Rest eher eingesprenkelt. So ähnlich dürfte es auch beim AO aussehen. Wenn man ehrlich ist wird man dort mit einfachen Verfahren + vorberechneten Shadingprofilen für bestimmte Objekte besser fährt als mit anderen Verfahren.
Ich könnte mir in dem Bereich auch kaum vorstellen dass Ben bei den neuen Verfahren wirklich die alten X-Plane Standards aufrecht erhalten wird. Die neuen Objekte müssen sowieso anders berechnet werden, aber ich könnte mir vorstellen das an der Stelle am ehesten Blender das letzte Wort haben dürfte.
Ich würde jha sowieso vorschlagen: Einfach alle Kanäle in ein TIFF und fertig ist die Sache. Allerdings glaube ich nicht das Ben davon überzeugt wären. Doch ob man da mehreren Mehrfarb-PNGs oder lauter einzelne Graustufen PNGs die man zur Sicherheit in ein ZIP Datei packt, dürften für X-Plane nicht den Unterschied ausmachen.
Das Jein würde ich voll bestätigen. Es macht einen riesen Unterschied ob ich in einem relativ begrenzten Raum die Szenarien wechsle, oder ob ich mich in einem konstant verändernden Raum mit realen Daten bewege , darin die Szene wechselt und sich Objekte bewegen. Ansonsten bin ich gespannt was die Entwicklung bringt.
Häuser, Fahrzeuge, transparente Wolken etc. hat man in anderen Spielen auch. Dazu muss dort die KI deutlich komplexer berechnet werden als bei Flugsimulatoren, Physik spielt eine größere Rolle, kein Gebäude sieht wie das andere aus etc, Bäume bestehen nicht nur aus zwei Flächen sondern sind ausmodelliert etc. Wenn man sein Leben lang in der Flugsimulation gearbeitet hat, fragt man sich immer wieder staunend, wie sie das hinbekommen. Sowohl von der Performance als auch die immense Arbeitszeit, die in den Objekten steckt. 🙂
Polygoncount und Drawcalls dürften in vielen Spielen deutlich höher sein, als beim FS.
Ich habe versucht, ein Tool zu finden, dass unabhängig vom laufenden Spiel Informationen wie die Anzahl der Triangles oder Drawcalls ausgibt, leider ohne Erfolg. Habt Ihr eine Idee?
Ob man von Räumen spricht, Landschaftsabschnitten oder Kontinenten, realen Daten, fiktionalen Daten oder zufällig generierten Daten dürfte dem PC vollkommen egal sein. Sie müssen nur zum richtigen Zeitpunkt ge- und später wieder entladen werden. Dass der FSX hier falsch programmiert wurde, dafür kann das Genre Flugsimulation ja nichts. Aber auch bei X-Plane läuft es manchmal nicht optimal. Gestern hat bei mir ein X-Plane Guru eine Runde in der IXEG 737 über der Default-Szenerie von Seattle gedreht. Es gab richtige Nachladepausen, Microstutters und Objekte wurden für den Nutzer sehr offensichtlich ein- und ausgeblendet. Ich habe dann gelästert, dass das Maßnahmen sind, damit sich der FSX Nutzer in der Umgebung wohler fühlt. 😉
In dem Zusammenhang wird es sehr spannend, ob ein Wechsel zu PBR mehr Ressourcen braucht oder weniger. Dass es optisch ein wichtiger und notwendiger Schritt für X-Plane selbst ist, steht außer Frage.
Karsten, für jeden Kanal eine eigene Textur, das fände ich auch sehr entlastend für den Add-on Entwickler. Und man bleibt mit der Engine flexibel um später noch Funktionen zu ändern oder hinzuzufügen.
Nun, man muss zugeben das sich X-Plane beim Aufbau von X-Plane 10 teilweise mehrfach böse verspekuliert hatte. Man besaß zwar theoretisches Wissen über OpenGL aber wenig praktische Erfahrung.
Vor allem Mac Os X hat sich dabei als echte Systembremse herausgestellt.weil es nicht dynamisch zwischen verschiedenen Standards wechseln konnte, wo Windows und Linux sich mit dynamischen Erweiterungen aus der Affäre zogen.
OpenGL versprach sehr viel aber über die tatsächlichen Probleme verrät es extrem wenig nach außen.
Das heißt der Entwickler weiß häufig genug nicht, wo es gerade klemmt. Erst im Laufe der Zeit fand man die Connections und das Wissen wo die Probleme wirklich stecken.
Im Grunde sitzt man gerade daran die gesamte OpenGL Engine auf eine andere Grundlage zu stellen.
Vom Vertex zählen ist man inzwischen vollkommen abgekommen. Der Parameter hat kaum noch Bedeutung, denn wo zählst du was?
Eine hohe Anzahl von einzelnen, für sich sehr einfachen Objekten stellt heute ein weitaus größeres Problem da, als wenige Objekte mit sehr vielen Effekten.
Diese Metriken kann das aufrufende Programm recht gut abfragen, aber man versucht solche Details nicht nach außen zu verraten.
Ein sehr guter Überblick!
Die Beschreibung von Materialeigenschaften und deren Auswirkung auf Oberflächen wird differenziert dargestellt, selbst die “Frensnelramp” wird abgehandelt, klasse!
In Anbetracht der Tatsache, dass dieses Thema eine eher trockene Materie ist, so kann man mit den Erklärungen und Beschreibungen einen guten Einblick in das Innerste der Materialeigenschaften moderner Computergrafiken bekommen.
Danke!
Schöner Bericht mit tollen Einblicken, danke dafür! Für wie absehbar hälst du denn die Zeit, bis uns PBR in Form von X-Plane 11 persönlich beschäftigt?
Ich persönlich rechne mit XP11 nicht vor dem Weihnachtsgeschäft 2017. Du beziehst dich in deinen Artikeln immer häufiger auf XP11, was ist deine Einschätzung für die notwendige Entwicklungszeit?
Wie war das? “Wenn ich ihnen das verraten würde, müsste ich sie erschiessen.”
Aber ernsthaft, das lässt sich nicht wirklich seriös angeben.Das zeigt sich immer erst bei der Entwicklung. In einigen Fällen zeigt sich dass unbedingt benötigte Komponenten noch überhaupot nicht vorhanden sind und erst geschrieben werden müssen, während sich in anderen Fällen, wo man mit Wochen und Monaten an Entwicklungszeit gerechnet hatte, im Prinzip schon alles da ist und eine Stunde später ist der Code fertig..
Cooler Bericht. Weit über Niveau von simflight Normal; Respekt!
Im übrigen liegt der Vorteil von PBR zusammen mit weiteren Effekten an der hohen Parallelisierbarkeit der Shader. Und bei heutigen GPU’s mit teilweise 4096 Shadereinheiten (de Fakto kann man sagen Shader=Core; jedoch können alle Kerne zeitgleich nur die gleiche Arbeit erledigen nicht wie bei einer CPU wo jeder Core was anderes machen kann) wird sehr viel Leistung bei den Flugsimulatoren verschenkt da die Grafikengines nichtmehr state-of-the-art sind. X-Plane nutzt noch heute Source von X-Plane 5 und begann erst vor 2 Jahren mit dem Abkoppeln der Grafik vom Simulationskern; eine Arbeit die derzeit Dovetail ebenfalls erledigt und die School als Probierplattform benutzt.
Das Niveau des Artikels ist unabhängig von der Diskussion auf einem wirklich hohen Niveau. Auch wenn man hier und da vielleicht darüber diskutieren kann und sollte. Aber das ist grundsätzlich ja kein Minus Kriterium sondern zeigt nur wie gut dieser Artikel ist. Danke!