Wir haben ja mittlerweile schon eine Menge Vorschaubilder aus dem MSFS gesehen. Uns hat dabei interessiert, was sich in Bezug auf das Szenerie Design verändert hat und welches Potential oder auch Herausforderungen ein Szenerie Designer im neuen Simulator sieht. Dazu haben wir für Euch ein Interview mit Umberto Colapicchioni von FSdreamteam geführt und für Euch ins Deutsche übersetzt.

FSDreamTeam ist eine Vereinigung unabhängiger Entwickler unter dem Firmennamen VIRTUALI s.a.s, einem der ältesten Unternehmen auf dem Markt für Flugsimulator-Addons, seit seiner Gründung im Jahr 1993, als der Flugsimulator noch die Version 4.0 hatte und in Ms-Dos lief.

 

Dislcaimer: Übersetzung aus dem englischen mit Hilfe von DeepL. Die Übersetzung erhebt keinen Anspruch auf Richtigkeit. Fehler – auch den Sinn entstellende – können vorhanden sein. Wir bitten um Hinweise, falls ihr einen solchen entdeckt, vielen Dank! Das englische Original Interview findet Ihr unten in diesem Artikel.

 

 

Umberto, Du bist ein Urgestein in der Flugsimulator Community. Hättest Du in jungen Jahren daran geglaubt, dass Du damit so erfolgreich werden wirst? Mit welchem Simulator fliegst Du selbst am liebsten?

Sicherlich konnte ich nicht vorhersagen, wie lange und in welchem Umfang ich mit 20 Jahren in der Lage sein würde, diesen Beruf auszuüben.

Ich habe damals in der Musikindustrie gearbeitet ( ich arbeitete für Roland Corp. und spielte professionell Keyboards in Clubs ), aber parallel dazu war ich immer ein Softwareentwickler/-macher, angefangen mit meinem Commodore 64 Tage, und schon damals arbeitete ich schon mit MS Flight Simulator. Vor langer Zeit habe ich die MSFS 2.0 C64-Diskette “gehackt”, um eine italienische Version davon zu erstellen, die sogar ohne Genehmigung von einem der vielen Magazine+Disketten veröffentlicht wurde, die in den 80er Jahren populär waren.

Also beschloss ich um 1993 herum, meine Musikkarriere aufzugeben, um mich auf Software zu konzentrieren, und gründete meine Firma, um eine komplette Szenerie für Italien ( alle 110 Flughäfen… ) in herrlicher 16-Flach-Farbgrafik zu veröffentlichen, für FS 4.0 und Ms-Dos 6, die in 4 Disketten kam, 3 davon 1.44Mb und die letzte nur 720k, um etwas Geld bei der Duplikation zu sparen…

Aus rein kommerzieller Sicht waren die 90er Jahre jedoch eine sehr befriedigende Ära. Es stimmt zwar, dass die Gemeinschaft kleiner und es teurer und schwieriger war, Produkte zu vertreiben ( man konnte keine “0-Tage-Patches” erstellen ), aber es stimmt auch, dass es fast keine Konkurrenz gab und das Wissen über Add-Ons, Dateiformate und Reverse Engineering sehr knapp und schwer zu erwerben war, so dass die Verkäufe von Add-On-Produkten überraschend gut waren. Unsere größten Hits waren Szenerien für Venedig und Tokio für FS5 und FS6. Tokio war besonders erfolgreich, da unser japanischer Partner es schaffte, sie mit der ersten japanischen Version des Flugsimulators, dem von ihm vertriebenen FS6.0 ( FS 95 ), zu bündeln. Die Verkaufszahlen überstiegen 65.000 Exemplare, was heutzutage in keiner Flughafenlandschaft mehr zu finden ist. Es gelang mir, mit diesen Verfahren die Vorauszahlung für mein Haus zu leisten, was heutzutage wiederum nicht mehr möglich ist, sicherlich nicht mit einem Flughafenszenenprodukt.

 

Mit welchem Simulator fliegst Du selbst gerne?

Du meinst: “Mit welchem Simulator wärst Du geflogen, wenn Du noch Zeit übrig gehabt hättest, es tatsächlich zu tun? Das ist die traurige Realität der Flugsimulatorentwickler: Wir starten den Simulator etwa 200 Mal am Tag neu, und benutzen ihn fast ausschliesslich im “Slew-Modus”…

Um Dir die Wahrheit zu sagen, der einzige Simulator, den ich wirklich zur Unterhaltung “spiele”, ist Elite Dangerous, der in vielerlei Hinsicht eine Art Flugsimulator im Weltraum ist. Aber ich muss sagen, dass mir der neue MSFS irgendwie die Freude am Fliegen zurückgebracht hat.

 

Wir wollen ja über den MSFS sprechen. Welches Potential bietet der MSFS, dass Du bei den bestehenden Simulatoren FSX/P3D/X-Plane bisher vermisst hast?

Die erste offensichtliche Antwort ist die Grafic Engine: Jeder kann das sehen, aber für einen Entwickler ist es noch offensichtlicher, vorausgesetzt, man lernte bereits, mit dem vollen PBR-Workflow zu arbeiten (mehr dazu später). MSFS ist der EINZIGE Simulator da draußen, bei dem das, was Sie in einem PBR-Texturierungsprogramm (wie z.B. Substance Painter) sehen, fast identisch mit dem ist, was Sie in der Simulation erhalten. Wir verbringen unzählige Stunden mit dem Versuch, Farben, Reflexionen usw. zu optimieren, weil man unmöglich genau wissen kann, wie sie in der Simulation aussehen werden, und manchmal ändert es sich auch (sehr) sogar zwischen verschiedenen Simulatorversionen. Nein, 100%ige Genauigkeit ist fast unmöglich, aber MSFS ist sehr nah dran, und das ist bei der Entwicklung wirklich hilfreich.

Die Beleuchtungsumgebung ist so gut, dass es schwer zu glauben ist, dass es kein Ray Tracing verwendet. Sogar ein leeres Objekt ohne Texturen sieht dort anständig aus, und das ist sehr lohnend, und es macht Lust, mehr zu tun.

Außerdem hat MSFS ein riesiges Anpassungspotential, und Asobo war sehr geschickt darin, eine gute Balance zu finden, dass es einerseits Erweiterungsmöglichkeiten gibt, aber andererseits die Möglichkeit von Benutzern und Entwicklern, die Simulation zu verkorksen oder Konflikte zwischen den Add-Ons zu verursachen, gering zu halten.

Ich möchte betonen, dass das SDK immer noch nicht fertig gestellt ist, es ist noch in Arbeit, und wir denken, dass es noch eine ganze Weile dauern wird. Aber wenn man sich die Dateistruktur ansieht und in undokumentierten Dingen herumstöbert, ist klar, dass die Simulation so konzipiert wurde, dass sie auf unzählige Arten angepasst werden kann, indem Standarddateiformate verwendet werden ( xml, html, json, css, javascript, usw. ), und das ist ein gutes Vorzeichen für die Zukunft.

 

Wir lesen oft “native Entwicklung für MSFS”. Was bedeutet das? Muss nun wirklich jedes 3D-Modell neu erstellt werden? Ist es möglich, bestehende Szenerien “einfach schnell” in MSFS zu portieren?

Es gibt mehrere Ebenen, in denen das Zauberwort “nativ” verwendet werden kann, um auf die Entwicklung für MSFS zu beschreiben:

– Flugmodell : Der MSFS kann zwei verschiedene Flugmodelle verwenden (und die Benutzer können sogar zwischen den beiden wechseln), das “native” und das Legacy für den FSX. Es ist sogar möglich, eine .AIR-Datei zu platzieren, und das Flugzeug wird wie im FSX fliegen. Aber das wird als veraltet angesehen, also schätze ich, ein natives Flugmodell ist eines, das keine .AIR-Dateien verwendet.

– Flugzeug-Instrumente: MSFS unterstützt so viele verschiedene Möglichkeiten zur Erstellung von Flugzeuginstrumenten, dass mir jeder Neuling leid tut, der versucht, es herauszufinden. Es gibt eine gewisse Unterstützung für XML-Flugzeuginstrumente alten Stils, aber die Standardflugzeuge verwenden hauptsächlich eine neue Methode von Html+Css kombiniert mit Javascript-Code für die Logik mit Hilfe von CoherentGT, einer hochleistungsfähigen Grafik-Engine für Webseiten. Darüber hinaus ist C++ immer noch möglich, wenn auch auf eine völlig neue Art und Weise, mit Hilfe eines Webassembly-Moduls, das eine Art virtuelle Maschine ist, die C++-Code sicher ausführen kann, ohne die Simulation abstürzen zu lassen, bei der die Messgeräte sandboxartig Zugriff auf das Dateisystem haben, so dass sie nur aus ihrem eigenen Installationsordner lesen und nur im lokalen Ordner des Benutzers lesen und schreiben können, so dass sie theoretisch keinen Schaden am System oder anderen Add-Ons anrichten können. Sie können nicht auf die Windows-API zugreifen, was die größte Einschränkung darstellt, aber wir verstehen, dass dies die einzige Möglichkeit war, komplexen benutzerdefinierten Code in der zukünftigen Xbox-Version laufen zu lassen. Webassembly verfügt über nicht weniger als 3 verschiedene Grafik-APIs, von denen eine niedriger als die andere ist, so dass es möglich ist (allerdings mit viel Arbeit), bestehenden GDI+-Code in das neue System zu konvertieren oder völlig neuen Code mit den APIs auf niedrigerer Ebene zu schreiben, ohne sich mit komplizierten (und potenziell gefährlichen) DirectX-Aufrufen befassen zu müssen. Ja, es ist ziemlich komplex, und wir denken, dass Flugzeugentwickler viel “Spaß” an der Portierung ihrer vorhandenen Produkte haben werden.

– 3D-Modellierung: Dies ist der Teil, der uns als Landschaftsentwickler am meisten beschäftigt, daher werde ich versuchen, die Probleme zu erklären, die hier im Spiel sind, damit die Benutzer besser verstehen, was “native” wirklich bedeutet.

In den letzten Jahren war einer der größten Fortschritte bei Grafik-Engines die Umstellung auf PBR ( Physically Based Rendering ), was kurz gesagt bedeutet, Texturen zu haben, die auf realistischere Weise beschreiben, wie ein bestimmtes Material auf einfallendes Licht reagieren wird.

Kunststoff sieht ganz anders aus als Metall oder Glas, und dies kann nur dann gut simuliert werden, wenn ein Objekt mit der ganzen Palette von PBR-Texturen texturiert wird, die normalerweise Albedo ( die “wahre” Farbe des Objekts ohne jegliche Licht- oder Schatteninformation ), Metallness ( welche Teile eines Objekts metallisch sind ) und Roughness ( Null-Rauhigkeit ist ein Spiegel, maximale Rauhigkeit ist so etwas wie Pappe ) sind. Diese Werte sind nicht von Künstlern erfunden worden: es gibt für fast jedes Material da draußen bekannte kodierte Werte, und es ist sogar möglich, etwas in der realen Welt zu scannen, indem man mehrere Bilder aus verschiedenen Lichtwinkeln verwendet, und diese Werte zu erhalten, was, wenn die Grafic Engine richtig gemacht wird, sehr naturgetreu aussehen wird.

Denn dies ist das wichtigste Konzept bei PBR: Wenn Sie ein Objekt nur mit PBR-Materialien texturiert haben, wird es besser aussehen, wenn die Rendering-Engine besser ist. Wenn eine Grafik-Engine der nächsten Generation, die besser als MSFS ist (oder ein Upgrade auf MSFS), irgendwann in der Zukunft kommt, werden Objekte, die im vollständigen PBR erstellt wurden, mit der zukünftigen Engine noch besser aussehen, ohne dass sie neu erstellt werden müssen.

Wie jeder weiß, unterstützen sowohl X-Plane 11 als auch P3D4/5 PBR, und viele Entwickler waren überrascht, als diese Änderungen eingeführt wurden. Aber diese Simulatoren unterstützen auch die Legacy-Rendering-Methode (basierend auf dem Diffuse + Specular + Glossiness-Modell), so dass Sie nicht(!) das gesamte Produkt (also das Flugzeug oder die Szenerie ) in PBR umwandeln *müssen*, wenn Sie nur einige Effekte vorführen wollen. Ein häufiger Fehler ist die Annahme, dass das PBR hauptsächlich für Metalle erforderlich ist, so dass wir viele Produkte gesehen haben, die als PBR beworben wurden, aber was sie wirklich taten, war, einfach ihre vorhandenen Texturen zu nehmen, die Metallteile als solche zu kennzeichnen und Schluss zu machen. Da es sowohl in P3D als auch in X-Plane möglich ist, Nicht-PBR-Objekte gemischt mit PBR zu verwenden, ließen viele Entwickler das nichtmetallische Material einfach unverändert, um die Umwandlung zu beschleunigen und in der Lage zu sein, einige PBR-ähnliche Effekte zu zeigen.

Es stimmt zwar, dass Metalle die offensichtlichste Verbesserung sind, aber es gibt noch andere Probleme im Zusammenhang mit der Handhabung von Licht/Schatten, was dazu führt, dass diese “Halb-PBR”-Arbeiten in Engines wie XP oder P3D4 nicht so gut aussehen, wie sie in Engines wie XP oder P3D4 sein könnten, und noch mehr im MSFS, das nur im PBR funktioniert. Die Sache ist die: in XP und P3D4 verwenden die meisten Standard-Szenerieobjekte und Terrains noch kein PBR, so dass die gesamte Grafik-Engine so abgestimmt wurde, dass beide Arten von Objekten zusammen einigermaßen gut aussehen, weil das Wegwerfen der Rückwärtskompatibilität die Add-on-Entwickler vor Angst schreien lassen würde, da sie gezwungen wären, Tausende von Texturen von Grund auf neu zu erstellen. MSFS funktioniert nur in PBR, also geht die gesamte Beleuchtungsengine davon aus, was bedeutet, daß es nur für PBR hätte optimiert werden können, deshalb sieht es so viel besser aus als alles andere da draußen: das Licht ist *kohärenter*, alles ist aufgeräumter, Objekte fallen normalerweise nicht als fehl am Platz auf (wie ein nettes PBR-Objekt in einem Gebiet mit Legacy-Texturen), alles ist dadurch lebensechter. Das ist der Hauptgrund, warum die Grafik so realistisch aussieht.

Dies bringt uns also zu einem weiteren Problem, nämlich der Frage, wie Objekte, die von Grund auf nicht “wirklich” für PBR erstellt wurden, im MSFS aussehen werden, und wie viel Arbeit es erfordert, etwas auf das MSFS zu “portieren”.

Ein Objekt, das nicht für PBR gemacht wurde und erzwungen oder schnell konvertiert wurde (es gibt einige Werkzeuge, die dabei helfen, einige sogar kostenlos, und die Ergebnisse sind gewöhnlich “meh”…), um das PBR zu verwenden, wird fast immer schlecht oder nicht so gut wie erwartet aussehen, bis zu einem Punkt, an dem einige Standardobjekte besser aussehen könnten, nur weil ihre Texturen von Grund auf immer im PBR erstellt wurden.

Die aufschlussreichsten Dinge, nach denen Sie Ausschau halten müssen, um eine schnelle und schmutzige Umwandlung in das PBR zu erkennen, sind:

– Zu schwerfällige Ambient Occlusion, mit zu dunklen vertieften Bereichen, selbst wenn kein direktes Licht vorhanden ist (z.B. unter Wolken). Ambient Occlusion baked war das Hauptwerkzeug, das den Modellierern zur Verfügung stand, um “Tiefe” in Grafik-Engines hinzuzufügen, die keine Echtzeit-Ambient Occlusion (P3D) haben, oder wenn sie sie haben (XP11), ist sie nicht so effektiv oder glatt wie die pre-baked, und nicht viele Anwender ermöglichen sie aus Leistungsgründen. Das Entfernen von baked AO aus bestehenden Texturen ist sehr schwierig, besonders wenn man einige Arbeiten nimmt, die man vielleicht schon Jahre zuvor durchgeführt hat, so dass möglicherweise nicht alle ursprünglichen Assets sofort verfügbar sind, oder wenn man Methoden oder Software zur Berechnung verwendet hat, die möglicherweise nicht mehr funktionieren. In vielen Fällen wurde Ambient Occlusion sogar mit “Stichen” aus zusätzlichen Polygonen hinzugefügt, die an strategischen Stellen hinzugefügt wurden, um den Effekt an ausgewählten Stellen zu erzielen. Um ihn zu entfernen, müssen Sie also all diese Dinge entfernen, die jetzt überflüssig sind, da MSFS ein sehr schönes AO in Echtzeit berechnet, und das macht bei der Modellierung/Texturierung von Objekten den größten Unterschied in der Welt aus. Aber einige Entwickler könnten versucht sein, einfach ihre existierende diffuse Textur ( ie Farbe + Licht + AO ist) zu nehmen und sie als “Albedo” zu übergeben, vielleicht mit einigen Optimierungen, um das offensichtlichste baked AO loszuwerden, während die wirkliche Albedo in Wirklichkeit eine völlig andere Sache ist: die reine Farbe ohne jegliche Lichtinformation. So kontra-intuitiv es auch klingen mag, eine gute Albedo-Textur, die im Spiel fotorealistisch aussieht (weil sie mit den richtigen Metalness/Roughness-Maps assoziiert wird), wird sehr schlecht und flach aussehen, wenn man sie in Photoshop öffnet. Und das Gegenteil ist der Fall: Etwas, das in Photoshop “echt” aussieht, wird in der Simulation wahrscheinlich schlecht/schlecht aussehen, weil das Foto bereits viele Informationen erfasst hat, die vom Simulator *vermutet* werden, so dass sie in der Textur gar nicht erst vorhanden sein sollten.

– Schattenwürfe in der Textur sind ein weiteres Beispiel. Früher haben wir darüber gescherzt, dass eine Szenerie mit Richtungsschatten in der Textur wie eine kaputte Uhr ist, die zweimal am Tag perfekt pünktlich geht. Bei einer Szenerie ist es genauso: Wenn Sie einen Richtungsschatten haben, bedeutet das, dass Ihre Szenerie nur für die genaue Zeit, zu der das Foto aufgenommen wurde, realistisch ist…

– Rauheit oder Umgebungsverdunkelung nicht kohärent mit normalen Karten. Das ist ein weiteres Anzeichen dafür, dass die Textur von einem Nicht-PBR-Workflow angepasst wurde. In der realen Welt haben Objekte selten eine konstante Rauheit entlang ihrer gesamten Oberfläche. Stattdessen ändert sie sich ständig aufgrund von Kratzern, Oberflächenunebenheiten, Schmutz, Öl usw. und ihre Wirkung ändert sich in Abhängigkeit von den Hohlräumen des Objekts. Daher sind die Normal Maps wichtig, und sie werden idealerweise durch eine viel höhere Poly-Count-Version derselben Objekte erzeugt, die nur zur Berechnung von Normal Maps, Mikro-AO und der entsprechenden Rauheitskarte entsprechend den physikalischen Eigenschaften des Materials verwendet wird. Wenn Sie eine Textur mit einem konstanten Rauheitswert sehen, bedeutet dies fast ausnahmslos, dass es sich um eine Schnellübertragung aus einer früheren Arbeit handelt, die für Nicht-PBR-Motoren erstellt wurde.

– Verwendung von “unsicheren” PBR-Farben. Im wirklichen Leben ist nichts jemals reines Weiß (Schnee, unter einigen Lichtbedingungen vielleicht) und nichts ist reines Schwarz. Es gibt bestimmte Wertebereiche, die von den Materialien abhängen, die man bei der Texturierung nie draußen bleiben sollte, und wenn man es absichtlich tut, wird das Ergebnis in der Simulation karikaturhaft und nicht realistisch aussehen, weil ihre Werte die PBR-Berechnung dazu bringen, falsche Ergebnisse zu produzieren. Wenn Sie etwas sehen, das zu schwarz oder zu weiß hervorsteht, ist das ein Zeichen dafür, dass die Textur gemacht wurde, ohne dies zu berücksichtigen. Es gibt Softwareprodukte, die Funktionen haben, die dabei helfen, illegale PBR-Farben zu finden.

 

Damit kommen wir zum nächsten Schritt: Welche Produkte sind es WERT für den MSFS umgewandelt zu werden? Ich hoffe, dass nach der Bereitstellung dieses Hintergrundes die Antwort nur lauten kann:

“Diejenigen, die von Anfang an so konzipiert wurden, daß sie vollständig in PBR hergestellt werden, wobei ausschließlich Softwareprodukte für PBR verwendet werden, die Texturen ausgehend von Materialbibliotheken mit PBR Eigenschaften erzeugen”.

In der Praxis läuft dies auf Produkte hinaus, die fast ausschließlich unter Verwendung von Produkten wie Substance Designer, Substance Painter, Quixel, 3D Coat usw. texturiert wurden. Diese Werkzeuge können Texturen in jedem Format exportieren, das von der Simulator-Engine benötigt wird: wir haben Profile, die wir von Substance nach P3D4, XP11 und MSFS exportieren können, aber die Möglichkeit, Texturen zu “exportieren”, bedeutet an sich nicht viel: wenn die Textur vollständig unter Verwendung von PBR hergestellt wurde, ist der Export in die verschiedenen Simulatoren fast kein Aufwand und wird in allen Simulatoren “einigermaßen” gut und “einigermaßen” ähnlich aussehen.

Wenn sie schnell von einem Nicht-PBR-Job konvertiert wurde, wird sie wahrscheinlich in allen dreien schlecht oder fehl am Platz aussehen, aber während XP/P3D-Entwickler immer noch die Wahl haben, NICHT PBR zu verwenden, haben MSFS-Entwickler diesen Luxus nicht: sie MÜSSEN PBR verwenden, was bedeutet, dass sie eine größere Chance haben, etwas zu erschaffen, das großartig aussieht, aber auch eine größere Chance, etwas zu tun, das schlecht oder enttäuschend aussieht.

 

Welche neue Funktion im MSFS gefällt Dir am besten? Gibt es Dinge im MSFS, die wir von anderen Simulatoren gewohnt sind und die nicht leicht zu implementieren sind?

Ich glaube, meine frühere Antwort über Grafik hat bereits angedeutet, was ich über MSFS denke:

– Die Lighting-Engine ist wirklich bahnbrechend, und das Echtzeit-AO ist eine Bereicherung für Modellierer, denn es verändert die Arbeitsweise, es spart Zeit sowohl beim Modellieren als auch beim Texturieren, und es lässt alles viel besser “zusammen wirken”, als es jemals der Fall war.

– Der mitgelieferte Szenen-Editor ist sehr leistungsfähig und erlaubt es jedem, sobald man sich daran gewöhnt hat, eine Szenerie in sehr hoher Qualität zu erstellen. Die Standardbibliothek von Objekten ist groß und in der Regel von sehr hoher Qualität. Wenn Sie also etwas Standardmäßiges zum Platzieren benötigen, wie z.B. ein PAPI-Lichtgehäuse oder eine kleine ILS-Hütte, sieht das Standardobjekt bereits sehr gut aus, was die Erstellung von Freeware oder sehr preiswerter Payware erleichtert, vielleicht für Flughäfen, die sonst kommerziell nicht machbar wären.

– Die Standard-Autogen-Engine in Verbindung mit der zugrundeliegenden fotorealen Abdeckung von Bing ist wirklich herausragend, und es ist wahrscheinlich die größte Errungenschaft des MSFS. Was noch interessanter ist, ist die Tatsache, dass die Szenerie wahrscheinlich während der Lebensdauer der Simulation verbessert wird, und zwar ganz automatisch, ohne dass sich die Benutzer darum kümmern müssen. Sie starten die Simulation, und Ihre Lieblingsstadt wurde mit Lidar auf magische Weise mit Lidar aktualisiert, während Sie schliefen. Ist das nicht großartig?

– Die neuen Programmierfunktionen der Messgeräte sind interessant, und ich denke, wir werden viele sehr gute Sachen von den Entwicklern sehen, die viele Sachen machen können, ohne zu viele Tricks mit unsicheren Codes machen zu müssen.

Es ist schwierig zu sagen, welche Dinge wir bei anderen Sims am meisten vermissen, vor allem, weil das SDK noch in Arbeit ist. Bevor ich also sage “wir können das in MSFS nicht machen”, würde ich lieber abwarten, wie es sich entwickeln wird. Sagen Sie lieber “wir können das *jetzt* nicht machen”.

Aber wir können mit Sicherheit sagen, dass einige Dinge immer anders sein werden, und dass einige Anpassungsmöglichkeiten immer ausschließlich P3D oder XP vorbehalten sein werden. Das P3D-SDK (was ich am besten kenne, aber ich weiß auch etwas über das XP-SDK, und selbst wenn es anders ist, gibt der Ansatz den Entwicklern viel Kontrolle), ist extrem tiefgehend und gibt Entwicklern fast keine Beschränkung in dem, was sie damit machen können. Es ist klar, dass P3D für den professionellen Markt entwickelt wurde und MSFS nicht. Es gibt Firmen, die Software-Add-ons anbieten, die die Grafik aus der P3D-Szenerie in Software mit DirectX-Code verarbeiten können, um sie um mehrere Projektorbildschirme zu wickeln und so zu kalibrieren, dass sie verzerrungsfrei dargestellt werden kann. Dies ist natürlich von unschätzbarem Wert für professionelle, aber auch für private Cockpitbauer, und ich bin mir nicht sicher, ob MSFS jemals versuchen wird, dies zu tun, sicherlich nicht auf der Ebene des SDK. Wir haben DirectX 11 direkt in P3D4 verwendet, und das gab uns einige nette Funktionen, die nur wenige andere Add-ons haben, wie Textur-Rendering on the fly, Schriftart-Rendering in der Szenerie, und das ist etwas, was MSFS im Moment nicht kann. Es hat seine eigenen verschiedenen Methoden, die wir gerade erforschen, aber es wird uns niemals erlauben, etwas so potentiell gefährliches zu tun, wie selbst DirectX-Aufrufe zu machen. Der Umstieg von DirectX11 auf DirectX12 in P3D5 ( und der ähnliche Umstieg auf Vulcan in XP ) gab dem Sim einen großen Leistungsschub, der jedoch auf Kosten der Stabilität ging, da DirectX 12 die gesamte Verantwortung für die Verwaltung der Ressourcen in die Hände des Anwendungsentwicklers legt (vorher erledigte der Videotreiber fast die gesamte Arbeit), so dass es schwieriger denn je ist, die Anwendung stabil zu machen, wenn Benutzer mit ihren Schiebereglern über Bord gehen. Aber da P3D als professionelles Produkt konzipiert ist, war es natürlich die richtige Wahl, denn wenn ein Profi wirklich eine bestimmte Art von Grafikqualität benötigt, kauft er einfach eine professionelle Grafikkarte mit viel VRAM. MSFS kann unmöglich mit “mindestens 16 GB VRAM” vermarktet werden, was wohl erklärt, warum sie einen vorsichtigeren Ansatz verfolgten und bei DirectX 11 blieben, das sich bewährt hat und, was noch wichtiger ist, es ist viel einfacher zu benutzen, während DirectX 12 eine Lernkurve hat, die mit “steil” nicht einmal ansatzweise definiert ist…

Und natürlich gaben sowohl XP als auch P3D dem Add-on-Entwickler vollen Zugriff auf die gesamten Funktionen des Betriebssystems, ohne Einschränkungen. MSFS wurde vom Design her eingeschränkt, um stabiler zu sein, da dies eine Voraussetzung dafür ist, um schließlich auch Add-ons von Drittanbietern auf der Xbox-Plattform zuzulassen.

Im Allgemeinen haben die anderen Simulatoren also immer noch sehr tiefe Fähigkeiten in ihren SDKs und die völlige Freiheit, fast alles zu tun, einschließlich des Absturzes der gesamten Simulation und des gesamten Betriebssystems (eine nicht verwaltete DLL, die in C++ geschrieben wurde, kann sicherlich die Simulation zum Absturz bringen, und eine, die DirectX verwendet, kann die Grafikkarte zum Absturz bringen, was wiederum möglicherweise das gesamte Betriebssystem zum Absturz bringen kann). MSFS hat seine eigene (andere) Art und Weise, Dinge zu tun, vielleicht nicht auf der gleichen Ebene der Kontrolle, aber es ist sicherlich eine sicherere und einfachere Umgebung, mit der man arbeiten kann. Wenn wir es nur schneller hätten ….

 

Welche neuen Werkzeuge werden nun für das Szeneriedesign verwendet?

Wir verwenden 3DS Max schon seit einiger Zeit, da es den Export nach FSX, P3D und MSFS ermöglicht.

Wir begannen vor Jahren mit reinen PBR Produkten zu arbeiten, noch bevor P3D überhaupt PBR hatte, bis zu dem Punkt, an dem wir sogar ein benutzerdefiniertes Plugin für Substance Painter schrieben, um etwas, das in echtem PBR hergestellt wurde, nach FSX und P3D V3 zu exportieren. Es benutzte viele Hacks und Tricks, aber es gab uns die Möglichkeit, unsere Zeit im “PBR-Modus” zu verbringen, so dass wir, als P3D4 mit PBR-Unterstützung herauskam, vor Freude sprangen, da wir nur *aufhören* mussten, unser Plugin zu benutzen, und einfach die Texturen in echtem PBR exportieren mussten, wie sie immer sein sollten.

Wir haben auch unser eigenes benutzerdefiniertes 3DS Max-Plugin, das es uns erlaubte, eine Flughafendatei zu erstellen, ohne Werkzeuge wie ADE zu benutzen. Damit können wir den 3D-Flughafen und das Gelände mit den “AFCAD”-Daten abgleichen, da wir beides aus den gleichen Dateien und Koordinaten in 3DS Max erzeugen, und dies war sehr nützlich, um sehr präzise AFCADs in unserem neuesten Produkt zu erstellen, und durch die Aktualisierung zur Unterstützung der neuen MSFS-Funktionen konnten wir einige unserer bestehenden Flughäfen recht einfach anpassen, ohne darauf warten zu müssen, dass ADE schließlich im MSFS ankommt.

 

Welche neuen Entwicklungsmöglichkeiten ergeben sich für Dich mit MSFS? Und sind sie auch auf P3D portierbar?

Nun, das ist jetzt schwer zu sagen, da eben das SDK noch nicht abgeschlossen ist. Zum Beispiel steckt im neuen Missionssystem viel Potenzial, das erweitert und, für andere Dinge als nur “Missionen”, nutzbar gemacht wurde. Bodenfahrzeuge und Menschen (unsere Spezialität) können in das System integriert werden, und ich denke, wir werden in diesem Zusammenhang noch viel Gutes erleben.

Noch schwieriger ist es zu sagen, was nach P3D “rückportiert” werden kann. Sicherlich lassen sich Objekte, die in echtem PBR hergestellt wurden, leicht zurückportieren. P3D hat auch ein gutes System zur Animation des menschlichen Skeletts (was uns bisher einschränkte, war das FSX-System), so daß jedes Modell oder jede Animation, die für das MSFS gemacht wurde, leicht zwischen beiden hin und her portiert werden kann.

Aber in anderen Dingen weichen sie voneinander ab. Die Simconnect-API, die mit dem MSFS geliefert wird, ist direkt von der FSX-Version abgeleitet und noch immer nicht 1:1 funktional gleichwertig zu ihr. Wir gehen davon aus, dass sie verbessert wird, um zumindest alles zu bieten, was zuerst im FSX funktionierte, und dann mit völlig neuen Funktionen erweitert wird. Das P3D-Simconnect hat sich in der Zwischenzeit in seine eigene Richtung entwickelt, und P3D hat eine völlig separate und extrem leistungsfähige API namens PDK, die auf niedrigerem Niveau und mit höherer Leistung arbeitet, und der MSFS hat nichts dergleichen. Aus funktionaler Sicht können die beiden Sims also als “hard forks” betrachtet werden, die nun auf getrennten Pfaden voranschreiten.

Aber etwas Gutes für P3D-Benutzer wird wegen MSFS kommen: Da das neue Simconnect nur 64 Bit hat, haben wir endlich die Chance ergriffen, das zu tun, was wir wahrscheinlich schon vor langer Zeit hätten tun sollen, nämlich das Couatl-Programm auf 64 Bit umzustellen. Bis heute war es nicht wirklich erforderlich, da es extern zum Sim lief, so daß es nicht aus dem eigenen Speicher der Sim herausgeschnitten wurde (selbst wenn die Sim 32 Bit war und der Speicher knapp war), so daß wir als FSX-Simconnect-Client nur mit einer .EXE zu tun hatten, die sich mit dem FSX und jeder Version von P3D verbinden konnte. Tatsächlich kann sie jetzt sogar eine Verbindung zum MSFS herstellen, aber wenn wir jemals in der Lage sein wollen, die NEUEN Simconnect-Funktionen zu nutzen, die schließlich zum MSFS hinzugefügt werden, müssen wir vollständig auf 64 Bit umstellen, so dass wir die native Version von Simconnect für MSFS verwenden können.

Das wird auch den P3D-Benutzern zugute kommen, denn sobald wir den Umstieg auf 64 Bit abgeschlossen haben, werden wir auch eine spezielle 64-Bit-Version für P3D erstellen, so dass wir statt einer einzigen 32-Bit-Version, die eigentlich ein FSX-Client ist, die aktuelle 32-Bit-Version behalten, um uns nur mit dem FSX zu verbinden, und wir werden zwei separate 64-Bit-Versionen haben, eine für P3D4/5, die mit dem nativen P3D-SDK erstellt wird, und eine für MSFS, die mit dem nativen MSFS-SDK erstellt wird.

Dadurch wird es viel zuverlässiger, weil es nicht mehr vom FSX Simconnect abhängt, ob P3D oder MSFS richtig installiert ist, und auch nicht mehr von den VC++-Laufzeiten, die vom FSX Simconnect benötigt wurden, es wird nicht mehr von diesem Support-Alptraum abhängen, dass niemand wirklich versteht, was Windows SxS ( Side-By-Side loading ) ist, weil sowohl P3D- als auch MSFS-Versionen von Simconnect statisches Linken verwenden, so dass die Chancen, dass es nicht startet, weil etwas in der Windows-Installation schief gelaufen ist, stark reduziert werden, weil es nur von den Systembibliotheken des Simulators abhängt, mit dem es verbunden werden soll.

 

Vor einigen Tagen beschrieben einige in der Community, dass das Software Development Kit als noch nicht “voll ausgereift”. Was fehlt Deiner Meinung nach noch?

Nun, was fehlt, ist völlig öffentlich und gut dokumentiert, da ich denke, dass jeder, der die Chance hatte, es sich anzusehen, sicherlich alle “TO-DO”-Kapitel bemerkt haben muss. In erster Linie fehlt also eindeutig alles, was als TO-DO aufgeführt ist. Wir sind nicht genau sicher, ob es wirklich “fehlt” oder ob es nur “fehlende Dokumentation” ist. Wahrscheinlich beides: einige Dinge sind einfach noch nicht erklärt, aber in der Simulation deutlich sichtbar, aber andere erfordern möglicherweise sowohl ein SDK-Update als auch ein Simulator-Update, bevor sie von Add-Ons verwendet werden können.

Wir arbeiten ständig mit Asobo zusammen und geben viel Feedback zu beidem: Was muss dokumentiert werden, und was möchten wir gerne hinzugefügt haben, und sind ziemlich zuversichtlich, dass die fehlenden Bits irgendwann eintreffen werden.

 

Performance ist wohl das ewige Dauerthema in der Community. Was beeinträchtigt aus Deiner Sicht am stärksten die FPS bei der Szenerieentwicklung im MSFS?

Die MSFS-Engine unterscheidet sich ziemlich stark von z.B. P3D. Während man in P3D mit über 100 fps bei einer Standard-Szenerie und einem Standard-Flugzeug anfangen kann, hauptsächlich weil beide nicht sehr detailliert sind, kann es schnell einbrechen, wenn man anfängt, Sachen hinzuzufügen. MSFS ist anders: die Standardszenerie ist so viel besser und die Standardflugzeuge sind so viel detaillierter als die P3D/FSX-Standardwerte, daß man nie 100 fps sieht, aber es ist nicht so einfach, sie in die Knie zu zwingen, wie es vielleicht klingt. Erstens, weil man nicht so viel grundlegendes Zeug hinzufügen muss, denn wenn man die Standardeinstellungen für Boden, Autogen und Wolken betrachtet, sieht das schon sehr gut aus.

Aber auch, weil man bei der Erstellung einer Add-on-Szenerie nicht mit fps gegen ein altes Nicht-PBR-Standardobjekt “konkurriert”, das 2006 für den FSX erstellt wurde und noch heute bei uns ist. Im MSFS sind die Standard-Flughäfen bereits volle PBR, so dass Sie, wenn Sie einen Standard-Flughafen ersetzen, die Möglichkeit haben, etwas möglicherweise Besseres zu tun, das sich nicht stärker auf die fps auswirkt als das, was Sie ersetzt haben. Denn das, was Sie ersetzt haben, war von Anfang an schon ziemlich fps-intensiv.

Die Kehrseite davon ist natürlich, dass Sie sich nach besten Kräften bemühen müssen, die Benutzer davon zu überzeugen, zunächst den Standard-Flughafen zu ersetzen, da viele den Standard-Flughafen (insbesondere die handgefertigten) für “gut genug” halten könnten. Also ja, es stimmt, die Messlatte wurde höher gelegt, und das ist gut so.

 

Wie sieht Deine Produktstrategie für MSFS aus? Werden FSX/P3D/X-Plane und Co. jetzt sterben? Was ist mit den Ground Services X?

Die erste Auswirkung des MSFS-Release ist, was uns betrifft, dass unsere Absichten, X-Plane endlich zu unterstützen, (wieder) verschoben wurden. Dies geschieht aus irgendeinem Grund immer wieder in jährlichen Abständen. Wir prüfen, ob wir X-Plane unterstützen können, und dann passiert immer etwas anderes: entweder wird bald eine neue X-Plane-Version erscheinen, oder es kommt eine weitere große Sim-Version heraus (wir haben uns erneut mit XP beschäftigt, als P3D V5 den Testern viele Monate vor der Veröffentlichung privat angekündigt wurde), so dass jedes Mal, wenn wir versuchen, etwas Zeit zu finden, um X-Plane zu unterstützen, etwas anderes passiert.

Die Sache ist die, dass X-Plane in einigen Fällen sehr unterschiedlich sein kann, besonders das Software-SDK, und natürlich hat es nicht Simconnect, was es erlauben würde, etwas wie GSX zum Beispiel leicht zu portieren. Anstatt also etwas völlig Neues zu lernen, fanden wir es immer besser, unsere begrenzte Zeit mit der Unterstützung der uns bekannten Plattformen zu verbringen, und MSFS, mit all den Unterschieden, die auf die neue Engine zurückzuführen sind, unterscheidet sich nicht dramatisch vom FSX, es hat Simconnect (auch wenn es nicht 100%ig vollständig ist, wird es irgendwann vollständig sein), und, allgemein gesprochen, werden wir nicht die zeitlichen und personellen Ressourcen haben, um drei verschiedene Plattformen zu unterstützen, so dass, wenn eine gehen muss, es diejenige sein wird, mit der wir nie arbeiten, nämlich X-Plane 11. Wir werden darauf noch einmal zurückkommen, wenn X-Plane 12 schließlich herauskommen wird.

GSX wird natürlich auf MSFS portiert werden, es wäre töricht, etwas anderes anzunehmen, da es unser bei weitem meistverkauftes Produkt ist, und wir sind sicher, dass die MSFS-Version glänzen wird, und die Benutzer werden sie haben wollen, besonders dann, wenn High-End-Flugzeuge von Drittanbietern ankommen werden, denn wenn Sie ein High-End-Flugzeug von Drittanbietern fliegen, werden Sie wahrscheinlich überall in der Simulation den gleichen Grad an Realismus wünschen, so dass die Standard-Bodendienste nicht ausreichen. Was ich persönlich am meisten vermisst habe, als ich selbst MSFS geflogen bin, war ein FollowMe Car, da Progressive Taxi im MSFS für meinen Geschmack etwas zu “gamey” aussieht, denke ich, dass die FSX-Version besser war.

Jetzt ist GSX allerdings noch nicht möglich, weil es nicht genug Funktionalität in Simconnect gibt, um so etwas wie GSX zu ermöglichen. Man kann kein Optionsmenü erstellen oder etwas zum Simulatormenü hinzufügen (es gibt kein “Addons”-Menü im MSFS), aber das sind Funktionen, die so grundlegend sind und von so vielen Addons benötigt werden, daß wir sicher sind, daß sie irgendwann kommen werden, Asobo ist sich ihrer voll bewußt, und Sie können sicher sein, daß wir (und auch andere Entwickler) darauf drängen werden, daß sie so bald wie möglich erscheinen. Nach allem, was wir wissen, könnten sie jederzeit erscheinen, daher bezieht sich alles, was ich hier sage, nur auf den aktuellen Status der Simulation zum heutigen Zeitpunkt.

Aber so, wie GSX gemacht wird, wird es, sobald Simconnect fertig ist, relativ schnell möglich sein, das vollständige GSX damit zu benutzen. Das liegt daran, dass GSX selbst ein zu 100 % in Python geschriebenes Programm ist, das vollständig außerhalb der Sim läuft, unter unserem eigenen Python-Interpreter, der Couatl-Engine. GSX selbst kümmert sich also nicht allzu sehr darum, mit welchem Simulator der Simulator arbeitet. Es muss vielleicht nur wissen, dass, wenn die Simulation kein PBR ist, bestimmte Objekte möglicherweise nicht verfügbar sind, aber das ist alles, was es wirklich wissen muss, über welche Simulation es auch spricht.

Abgesehen von der Programmierung wurde die meiste Arbeit zur Unterstützung einer “Next-Gen”-Grafik-Engine bereits im letzten Jahr geleistet, als wir fast alle (nur wenige fehlen) GSX-Fahrzeuge umgestaltet haben, um ein volles PBR zu erhalten. Diese Arbeit nahm fast ein Jahr in Anspruch ( wir veröffentlichten GSX L2 im September 2018 und das PBR-Update im Juli 2019 ), dennoch beschlossen wir, sie kostenlos zur Verfügung zu stellen, was zu diesem Zeitpunkt verrückt schien, da wir einen anderen großen Flughafen in der gleichen Zeit hätten umbauen können, aber dies wird sich wahrscheinlich im MSFS auszahlen, da wir nicht alle unsere Objekte erneut herstellen müssen und sie im MSFS einfach besser aussehen werden, da sie bereits “echtes PBR” haben.

Im Allgemeinen sind wir sehr glücklich über die Veröffentlichung des MSFS, da es viele neue Benutzer und möglicherweise auch alte Benutzer, die das Hobby aus irgendeinem Grund aufgegeben haben, wieder zurückbringen kann, und das ist etwas, was nur Flight Simulator kann. Wir sind absolut sicher, dass der Flugsimulator hier bleiben wird und für die kommenden Jahre die herausragende Plattform sein wird.

Das bedeutet aber nicht, dass der andere Sim “sterben” wird. Nichts “stirbt” wirklich, wirklich. Wir verkaufen immer noch FS9-Produkte, natürlich nicht in großen Stückzahlen, aber es ist nicht Null, und sie sorgen für interessante Zahlen zum Jahresende, was in Ordnung ist, wenn man bedenkt, dass die meisten unserer FS9-Produkte vor mehr als einem Jahrzehnt hergestellt wurden. Der FSX hat einfach zu viele Add-ons, um einfach zu verschwinden, und P3D befindet sich in der gleichen Situation, da es derzeit die fortschrittlichsten Add-ons hat. Und X-Plane hat eine sehr starke Anhängerschaft, also nein, niemand wird wirklich “sterben”, aber natürlich wird MSFS einen großen Teil der Nutzerbasis einnehmen, die es übrigens immer hatte, bevor das ACES-Studio aufgelöst wurde. Also ja, wir sind froh, dass MSFS zurückgekehrt ist.

 

 

 

---

Englisches Original Interview

Umberto, you are a veteran in the flight simulator community. Would you have believed at a young age that you would become so successful with it?

Sure I couldn’t predict for how long and how much I would be able to do this job when I was in my 20s.

I used to work in the music industry back then ( I worked for Roland corp. and I played keyboards professionally in clubs ), but in parallel I always was a software developer/maker, starting from my Commodore 64 days, and even then I was already working with MS Flight Simulator. Ages ago, I “hacked” the MSFS 2.0 C64 disk, to create an Italian version of it, which was even published without any authorization by one of the many magazines+disk that were popular in the 80s.

So, about 1993, I decided to abandon my music career, to concentrate on software, and started my company, to publish a complete scenery for Italy ( all 110 airports… ) in glorious 16 flat color graphic, for FS 4.0 and Ms-Dos 6, which came in 4 floppies, 3 of them 1.44Mb and the last only 720k, to save some money in duplication…

However, from a purely commercial point of view, the 90s were a very satisfying era. While it’s true the community was smaller, and it was more expensive and difficult to distribute products ( you couldn’t do “0-day patches” ), it’s also true there was almost no competition, and the knowledge about how to do add-ons, file formats, reverse engineering, was very scarce and difficult to come up with, and the result was that sales for add-on products were surprisingly good. Our biggest hits were sceneries for Venice and Tokyo for FS5 and FS6. Tokyo was especially successfully, since our Japanese partner managed to bundle it with the first Japanese version of Flight Simulator, which was FS6.0 ( FS 95 ) that he distributed. Sales exceeded 65K copies, which is unheard of for any airport scenery nowadays. I managed to make the advance payment for my home with those proceedings which, again, it’s no longer possible nowadays, surely not with an airport scenery product.

 

With which simulator do you like to fly yourself?

You mean “With which simulator you would have flown, had you any spare time left to actually do it ?”. That’s the sad reality of flight sim developers: we restart the sim like 200 times at day, and are almost exclusively using it in “Slew mode”…

To tell you the truth, the only simulator I really “play” for entertainment, is Elite Dangerous, which in many ways is a sort of Flight simulator in space.  But I must say that, the new MSFS has kinda brought me back to the joy of flying.

 

We want to talk about MSFS. What potential does MSFS offer that you have been missing in existing FSX/P3D/X-Plane simulators?

The first obvious reply is the graphic engine: everybody can see that but, for a developer is even more apparent, provided you were already used to work using the full PBR workflow ( more on this later ). MSFS is the ONLY simulator out there in which what you see in a PBR texturing program ( like Substance Painter, for example ), is almost identical to what you get in the sim. We spend countless hours trying to tweak colors, reflections, etc, because you cannot possibly know exactly how they’ll look like in the sim, and sometimes it also changes ( a lot ) even between different simulator versions. No, 100% fidelity is almost impossible, but MSFS is very close, and that’s really helping during development.

The lighting environment is so good, that is hard to believe it doesn’t use Ray Tracing. Even a blank object with no textures looks decent there, and this is very rewarding, and it makes you wanting do more.

Also, MSFS has a huge customization potential, and Asobo has been very clever in finding a good balance between extensibility and the ability of users and developers to screw up with the sim, or create conflicting add-ons.

I would like to stress out the SDK is still not completed, it’s still a work in progress, which we think will continue to progress for quite some time. But looking at the file structure and poking into undocumented things, it’s clear the sim was designed to be customizable in countless of ways, using standard file formats ( xml, html, json, css, javascript, etc. ), and this bodes very well for the future.

 

We often read “native development for MSFS”. What does that mean in detail? Do you really have to redo each and every 3D model? Is it possible to “just quickly throw” existing sceneries into MSFS?

There are several levels in which the magic word “native” can be used to indicate any development for MSFS:

– Flight Model : MSFS can use two different flight models ( and users can even switch between the two ), the “native” one and the legacy for FSX. It’s even possible to place an .AIR file, and the plane will fly like in FSX. But that’s considered obsolete so, I guess a native flight model is one that doesn’t use any .AIR files.

– Airplane instruments : MSFS supports so many different ways to create airplane gauges, that I feel for any newcomer trying to figure it out. There’s some support for old-style XML gauges, but the default airplanes use mainly a new method of Html+Css combined with Javascript code for logic with the help of CoherentGT, which is an high performance graphic engine for web pages. In addition to that, C++ is still possible, although in an entirely new way, by means of a Webassembly module, which is a sort of Virtual machine that can safely run C++ code without crashing the sim in which gauges have sandboxed access to the file system, so they can only read from their own install folder, and can only read/write in the user local folder so, in theory, they cannot do any damage to the system or other add-ons. They cannot access the Windows API, which is the biggest limitation, but we understand it was the only possible way to allow complex custom code to run in the future Xbox version. Webassembly has no less than 3 different graphic APIs, each more low level than the other, so it’s possible ( with a lot of work, though ), to convert existing GDI+ code to the new system, or write entirely new code with the more low-level APIs, without having to meddle with tricky ( and potentially dangerous ) DirectX calls. Yes, it’s quite complex, and we think airplane developers will have lot of “fun” porting their existing products.

– 3D Modeling : This is the part the concern us more, as scenery developers, so I’ll try to explain the issues at play here, so users might get a better understanding how what “native” really means.

In the past years, one of the biggest advancements in graphic engines, was the switch to PBR ( Physically Based Rendering ), which in in a nutshell means having textures that describe in a more realistic way how a certain material will react to incoming light.

Plastic looks very different than Metal or Glass, and this can only be simulated well if an object is textured with the whole complement of PBR textures, which usually are Albedo ( the “true” color of the object without any light or shadow information ), Metallness ( which parts of an object are metallic ) and Roughness ( zero roughness is a mirror, maximum roughness is something like cardboard ). Those values are not made up by artists: there are known coded values for almost every material out there, and it’s even possible to scan something in the real world, using multiple pictures taken from different light angles, and obtain those vales which, is the engine in the game is done correctly, will look very lifelike.

Because this is the most important concept with PBR: if you textured an object using only PBR materials, it will look better, if the rendering engine is better. If a next-gen graphic engine, better than MSFS ( or an upgrade to MSFS ) will eventually come in the future, objects made in full PBR will look even better with the future engine, with no need to rebuild them.

As everybody knows, both X-Plane 11 and P3D4/5 supports PBR, and many developers were caught off-guard when those changes were introduced. But those simulator also support the Legacy rendering method ( based on the Diffuse + Specular + Glossiness model ), so you don’t *have* to convert the whole product ( aircraft or scenery that is ) to PBR, if your goal is to just show off some effects. A common mistake is to assume that PBR is mostly required for metals, so we saw lots of product that were advertised as PBR, but what they really did was to just take their existing textures, flag the metallic parts as such, and call it a day. Since both P3D and X-Plane allow to use non-PBR object mixed with PBR, many developers simply left the non-metallic stuff unchanged, so speed up conversion, and be able to show off some PBR-like effects.

While is true that metals are the most obvious enhancement, there are other issues related to how light/shadows are handled, which results in those “half-PBR” jobs not looking as good as they could be in engines like XP or P3D4, and even more in MSFS, which works only in PBR. The thing is: in XP and P3D4, most of the default scenery objects and terrain doesn’t use PBR yet, so the whole graphic engine has been tuned to have both kind of objects looks reasonably good together, because throwing away backward compatibility would make add-on developers scream in angst, being forced to redo thousands of textures from scratch. MSFS only work in PBR, so the whole lighting engine assumes that, which means it could have been optimized for PBR only, that’s why it looks so much better than anything else out there: the light is more *coherent*, everything is more tidied up, objects don’t usually stick out as being out of place ( like a nice PBR object in an area with legacy textures ), everything is more lifelike because of that. It’s the main reason why the graphic looks so realistic.

So this bring us to another issue, which is how objects not “really” made for PBR from the ground up, will look like in MSFS, and how much work is required to “port” something to MSFS.

An object which was not made for PBR, and has been forced or quickly converted ( there are some tools to help with that, some even free, and the results are usually “meh”…) to use the PBR format, will almost invariably look bad, or not as good as expected, up to a point that some default objects might look better, just because their textures were always made in PBR from the ground up.

The most telling things you need to look for to spot a quick and dirty conversion to PBR are:

– Too heavy handed Ambient Occlusion, with too dark recessed areas even when there’s no direct light ( under clouds, for example ). Ambient Occlusion baked in was the main tool modelers had at their disposal to add “depth” in graphic engines that don’t have realtime Ambient Occlusion ( P3D ) or when they have it ( XP11 ), is not as effective or smooth as the pre-baked one, and not many users enable it for performance reasons. Removing baked AO from existing textures is very hard, especially if you take some work you might have done years before, so not all originally assets might be readily available, or you used methods or software to calculate it that might no longer work. In many cases, Ambient Occlusion was even added using “stitches” of additional polygons, added in strategic locations to give the effect in selected places, so in order to remove it, you’ll have to remove all these things that are now redundant, since MSFS calculates a very nice AO in realtime,  and this makes all the difference in the world when modeling/texturing objects. But some developers might be tempted to just take their existing Diffuse texture ( which is Color + light + AO ), and pass it as “Albedo”, maybe with some tweaks to get rid of the most obvious baked AO, when in fact the real Albedo is a completely different thing: the pure color without any light information of any kind. As counter-intuitive as it might sounds, a good Albedo texture that will look photorealistic in game ( because is associated with the proper Metalness/Roughness maps ), will look very bad and flat if you open it in Photoshop. And the opposite is true: something that “looks real” in Photoshop, will probably look bad/wrong in the sim, because the photo already captured lots of information that is *supposed* to be created by the simulator, so it shouldn’t be there in the texture in the first place.

– Casted shadows in the texture are another example.  We used to joke that a scenery that has directional shadows in its textures is like a broken clock which is perfectly on time two times per day. Scenery it’s the same: if you have a directional shadow in, it means your scenery will be realistic only for the exact time that photo was taken…

– Roughness or Ambient Occlusion not coherent with Normal Maps. That’s another sign the texture has been adapted from a non-PBR workflow. In real world, objects rarely have a constant roughness along their entire surface. Instead, it constantly changes, because of scratches, surface bumps, dirt, oil, etc. and its effect changes depending on the object cavities, so the normal maps are important, and they are ideally created by a much higher poly-count version of the same objects, used only to calculate normal maps, micro-AO and the relevant roughness map according to the physical properties of the material. If you see a texture with a constant Roughness value, it almost invariably means it was a quick port from a previous work that was made for non-PBR engines.

– Usage of “unsafe” PBR colors. In real life, nothing is ever pure White ( Snow, under some light conditions, maybe ) and nothing is pure Black. There are specific range of values depending on materials you should never stay outside when texturing, and if you intentionally do it, the result will look cartoonish and not realistic in the sim, because their values will make the PBR mathematics to produce wrong results. When you see something too black or too white sticking out, it’s a sign that texture was made without taking into account this. There are software products that have features to help finding illegal PBR colors.

This bring us to the next step: what kind of products are WORTH converting into MSFS ? I hope that, after providing with this background, the answer can only be:

“Those that were designed right from the start to be entirely made in PBR, using only PBR software products, which generates textures starting from libraries of materials using PBR properties”.

In practice, this boils down to products which were textured almost entirely using products like Substance Designer, Substance Painter, Quixel, 3D Coat, etc. Those tools can export textures in any format required by the simulator engine: we have profiles to export from Substance to P3D4, XP11 and MSFS, but being able to “export” texture, by itself, doesn’t mean much: if the texture was made entirely using PBR methods, exporting to the different simulators is almost no effort, and will look “reasonably” good and “reasonably” similar in all sims.

If it was quickly converted from a non-PBR job, it will probably look bad or out of place in all three but, while XP/P3D developers still have the choice NOT to use PBR, if they realize the old textures will look bad when converted to PBR, MSFS developers don’t have this luxury: they MUST use PBR, which means they have a greater chance of doing something that looks great, but also a greater chance to do something that looks bad, or underwhelming.

 

Which new feature in MSFS do you like best and vice versa, are there things in MSFS that we are used to from other simulators that are not easily implemented?

I think my previous reply about graphic were already hinting about what I think of MSFS:

– The lighting engine is truly groundbreaking, and the realtime AO is a game changer for modelers, because it changes the way you work, it saves time both when modeling and texturing, and it allows everything to “stick together” way better than it ever did.

– The included scenery editor is very powerful and, once you get used to it, it allows anybody to create a scenery in very high quality. The default library of objects is big, and it’s usually of very high quality, so if you need something standard to place, like a PAPI light enclosure, or a small ILS hut, the default object already looks very good, so this makes for easy creation of either freeware or very low cost payware, maybe for airports not commercially feasible otherwise.

– The default autogen engine, coupled with the underlying photoreal coverage from Bing is really stellar, and it’s probably the MSFS greatest achievement. What’s more interesting is the fact the scenery will be likely improved during the life of the sim, all automatically, without users having to worry about it. You start the sim, and your favorite city was magically updated with Lidar while you were sleeping. Isn’t that great ?

– The new gauges programming features are interesting, and I think we’ll see a lot of very good stuff from developers, which can do lots of stuff without having to do too many tricks with unsafe code.

It’s difficult to say which things we are missing the most from other sims, mostly because the SDK is still a work in progress so, before saying “we can’t do this in MSFS”, I would rather wait to see how it will evolve. Better say “we can’t do this *now*”.

But we can say for sure that some things will always be different, and some customization abilities will always be exclusive to P3D or XP. The P3D SDK ( which is what I know best, but I also know something about the XP SDK, and even if it’s different, the approach is equally giving devs lots of control ), is extremely deep and it give developers almost no limitation in what they can do with it. It’s clear P3D has been designed for the professional market and MSFS hasn’t. There are companies out there that do software add-ons that can take the graphic from the P3D scenery, and process it in software using DirectX code, to wrap it around multiple projector screens and calibrate it to show it with no distortion. This is of course invaluable to professional, but also to home cockpit builders, and I’m not sure if MSFS will ever try to do that, surely not at the SDK level. We used DirectX 11 directly in P3D4, and this gave us some nice features few other add-ons have, like texture rendering on the fly, font rendering in the scenery, and this is something MSFS can’t do right now, it has its own different methods which we are exploring right now, but it will never allow us to do something as potentially dangerous as making DirectX calls ourselves. The move from DirectX11 to DirectX12 in P3D5 ( and the similar move to Vulcan in XP ) gave the sim a big performance boots, but it came at a cost of stability, since DirectX 12 places all responsibility of managing resources in the hands of the app developer ( before, the video driver did almost all the work ), so it’s more difficult than ever to make the application to be stable when users go overboard with their sliders. But of course, P3D being designed to be a professional product, made the right choice because, if a professional really needs a certain kind of graphic quality, he will just buy a professional video card, with plenty of VRAM. MSFS cannot possibly be marketed “16GB VRAM minimum”, which I guess explains why they took a more cautious approach, and stayed with DirectX 11, which is tried and true and, more important, it’s far easier to use, while DirectX 12 has a learning curve which “steep” doesn’t even begin to define it…

And of course, both XP and P3D gave the add-on developer full access to the whole OS features, with no limitations. MSFS has been limited by design to be more secure, because this is a requirement to eventually allow 3rd-party add-ons on the Xbox platform as well.

So, generally speaking, the other simulators still have very deep capabilities in their SDKs, and a complete freedom to do almost everything, including crashing the whole sim and the whole OS too ( an unmanaged .DLL written in C++ can surely crash the sim, and one that uses DirectX can crash the video card, which in turn can possibly bring down the whole OS with it ), MSFS has its own (different) way of doing things, maybe not at the same level of control, but it’s surely a safer and easier environment to work with. If only we could start it faster…

 

Which new tools for scenery development are used now?

We have been using 3DS Max for a while now, since it allows exporting to FSX, P3D and MSFS.

We started working with PBR-only products years ago, even before P3D ever had PBR, up to the point we even wrote a custom plugin for Substance Painter to export something made in true PBR, to FSX and P3D V3. It used lots of hacks and tricks, but it gave us the ability to spend our time working in “PBR-mode” so, when P3D4 came out with PBR support, we were jumping with joy, since we only had to *stop* using our plugin, and just export the textures in true PBR, as they were always meant to be.

We also have our own custom 3DS Max plugin, that allowed us to create an airport file without using tools like ADE. With it, we can match the airport 3d and grounds with the “AFCAD” data, since we generate both from the same files and coordinates in 3DS Max, and this has been very useful to create very precise AFCADs in our latest product and, by updating it to support the new MSFS features, we have been able to adapt some of our existing airports quite easily, without having to wait for ADE to eventually arrive on MSFS.

 

Which new development possibilities are emerging for you with MSFS? And are they also portable to P3D?

Well, that’s difficult to say now, with the SDK not being completed yet. For example, there’s a lot of potential in the new Mission system, that has been expanded and made usable for things other than just “missions”. Ground vehicles and humans ( kind of our specialty ), can be integrated with it, so I think we’ll see a lot of good stuff coming up related to that.

Even more difficult to say what can be “back-ported” to P3D.  Surely, objects made in real PBR are easily to port back. P3D has a good human skeleton animation system too ( what limited us so far was the FSX system ), so any model or animation made for MSFS should be easily ported back and forth between the two.

But in other things they are diverging apart. The Simconnect API that comes with MSFS is derived directly from the FSX version, and still is not 1:1 functionally equivalent to it. We expect it will be improved to at least offer everything that worked in FSX first, and then expanded with entirely new features. The P3D Simconnect, in the meantime, has progressed in its own direction, and P3D has a completely separate and extremely powerful API called PDK, which is more low-level and higher performing, and MSFS doesn’t have anything like that. So, from a functional point of view, the two sim can be considered to be “hard forks” that are now progressing to separate paths.

But something good for P3D users will come because of MSFS: since the new Simconnect is 64 bit only, we finally took the chance to do what we should probably have done a long ago, that is converting the Couatl program to 64 bit. Until today, it wasn’t really required, since it ran externally to the sim, so it didn’t cut from the sim own memory ( even when the sim was 32 bit and the memory was scarce ) so, as an FSX Simconnect client, we only had one .EXE to deal with, which could connect to FSX and every version of P3D. In fact, it can even connect to MSFS right now but, if we want to ever be able to use NEW Simconnect features that will be eventually added to MSFS, we have to switch to 64 bit entirely, so we can use the native version of the Simconnect for MSFS.

This will benefit P3D users too, since once we’ll complete the move to 64 bit, we’ll do a specific 64 bit version for P3D too so, instead of having a single 32 bit version that is really an FSX client, we’ll keep the current 32 bit version to connect to FSX only, and we’ll have two separate 64 bit versions, one for P3D4/5, made with the native P3D SDK, and one for MSFS, made with the native MSFS SDK.

This will make it a lot more reliable, because it won’t depend anymore from the FSX Simconnect to be properly installed in P3D or MSFS, it won’t depend anymore from the VC++ runtimes which were required by the FSX Simconnect, it will not depend anymore from that support nightmare that nobody really understands which is Windows SxS ( Side-By-Side loading ) because both P3D and MSFS versions of Simconnect use static linking so, chances it will not start because something in the Windows installation went wrong, will be greatly reduced, because it will depend only on the system libraries of the simulator it’s supposed to connect with.

 

A few days ago, some in the community described the Software Development Kit as not yet “fully mature”. What do you think is still missing?

Well, what’s missing is entirely public and well documented, since I think everybody that took a chance to look at it, surely must have noticed all the “TO-DO” chapters. So, first and foremost, everything that is listed as TO-DO, is clearly missing. We are not exactly sure if it’s really “missing” or it’s just “missing documentation”. Probably both: some things are just not explained yet, but are clearly visible in the sim, but others might require both an SDK update and a simulator update before they can be used by add-ons.

We are constantly working with Asobo, providing lots of feedback about both: what needs to be documented, and what we would like to be added, and are quite confident the missing bits will eventually arrive.

 

Performance is probably the eternal topic in the community. In your opinion, what is the biggest impact on FPS in scenery development in MSFS?

The MSFS engine is fairly different than, for example, P3D. While in P3D you might start with over 100 fps on a default scenery and a default plane, mostly because both are not very detailed, you can go way lower than that if you start adding stuff. MSFS is different: the default scenery is so much better and the default airplanes are so much more detailed then P3D/FSX defaults, that you never see 100 fps but, it’s not as easy to bring it down to its knees as it might sounds. First, because you don’t have to add that much basic stuff, considering the default ground, autogen, clouds, already looks very good.

But also because when doing an add-on scenery, you are not “competing” with fps against an old non-PBR default object which was made in 2006 for FSX and it’s still with us today. In MSFS, the default airports are already full PBR so, if you are replacing a default airport, you have the chance to do something possibly better and not any more impacting on fps than what you replaced. Because what you replaced was already fairly fps-intensive to begin with.

The downside of this, of course, is you must to your best to convince users to replace the default airport to begin with, since many might consider the default airport ( especially the handcrafted ones ) to be “good enough”.  So yes, it’s true the bar has been raised, and it’s a good thing.

 

What is your product strategy for MSFS? Will FSX/P3D/X-Plane and Co. die now? What about Ground Services X?

The first effect of the MSFS release, as far we are concerned, is that our best intentions to finally support X-Plane have been ( again ) postponed. This keeps happening for some reason at yearly intervals. We look into supporting it, than something else always happen: either a new X-Plane version will soon come, or another major sim release happens ( we were looking again into XP, when P3D V5 was privately announced to testers, many months before the release ), so every time we try to find some time to start supporting X-Plane, something else comes.

The thing is, X-Plane can be very different in some cases, especially the software SDK, and of course it doesn’t have Simconnect, which might allow something like GSX, for example, to be ported easily. So, rather than learning something entirely new, we always found our limited time to be better spent in supporting the platforms we know, and MSFS, with all the differences due to the new engine, is not dramatically different than FSX, it has Simconnect ( even if it’s not 100% complete, it will eventually be ) and, generally speaking, we won’t have the resources in time/manpower to support 3 different platforms so, if one has to go, it will be the one we never work with, that is X-Plane 11. We’ll revisit again this, when X-Plane 12 will eventually came out.

GSX will of course be ported to MSFS, it would be foolish to assume otherwise, since it’s our best selling product by far, and we are sure the MSFS version will shine, and users will want it, especially when high-end 3rd party airplanes will start to arrive, since if you are flying an high-end 3rd airplane, you’ll likely want the same level of realism everywhere in the sim, so default ground services won’t cut it. Personally, when flying MSFS myself, what I missed the most was a FollowMe Car, since progressive taxi in MSFS looks a bit too much “gamey” for my tastes, I think the FSX version was better.

It’s not possible to have it now because there’s not enough functionality in Simconnect to allow something like GSX. You cannot create an option menu, or add something to the simulator menu ( there’s no such thing as an “Addons” menu in MSFS ), but these are features so basic, and are required by so many add-ons, that we are sure they will eventually arrive, Asobo is fully aware of them, and you can be sure we ( and other developers too ) will push for them to appear as soon as possible. For all we know, they could appear any time so, everything I’m saying here, is only related to the current status of the sim as of today.

But the way GSX is made, once Simconnect will be ready, it will be reasonably quick to have the full GSX working with it. That’s because GSX itself, is a program 100% written in Python, which runs entirely outside the sim, under our own custom Python interpreter, which is the Couatl engine. So GSX, by itself, doesn’t really care too much which simulator is working with. It might just have to know that, if the sim is not PBR, certain objects might not be available, but that’s all the things it really need to know about which sim it’s talking too.

Programing aside, most of the work to support a “next-gen” graphic engine, was already made last year, when we remodeled almost all ( just few are missing ) GSX vehicles to be full PBR. This work took almost a year to complete ( we released GSX L2 in September 2018, and the PBR update in July 2019 ), yet we decided to give it for free, which seemed to be madness at that time, since we could have done another big airport in the same time, but this will likely pay off in MSFS, since we won’t have to re-made all our objects again, and they will just look better in MSFS, because they are already “true PBR”.

In general, we are very happy of the release of MSFS, since it will be able to bring back lots of new users, and possibly old users that left the hobby for some reason, and that’s something only Flight Simulator can do. We are absolutely sure the sim is here to stay, and will be the prominent platform for years to come.

That doesn’t mean the other sim will “die”. Nothing really “dies”, really. We are still selling FS9 products, not in big numbers of course, but it’s not zero, and they make for interesting end of year figures, which is fine, considering most of our FS9 products were made more than a decade ago. FSX has just too much add-ons to simply disappear, and P3D is in the same situation, since it currently has the most advanced add-ons. And X-Plane has a very strong following so no, nobody will really “die”, but of course MSFS will take a big chunk of the user base which, incidentally, it’s what it always had, before ACES studio was disbanded. So yes, we are glad MSFS has come back.