Bei dieser Diskussion werden leider mal wie so oft Äpfel mit Birnen verglichen.
Man kann einen auf einen bestimmten Raum begrenzten Airport wie z.B Fly Tampa Wien überhaupt nicht mit einem weitläufig weit verstreuten Objektaddon wie German Landmarks vergleichen, bei dem die Objekte zum Teil mehrere Kilometer auseinander stehen aber dennoch zum Teil zeitgleich sichtbar sind.
Für den Laien mag es zunächst so aussehen, da ja beide Addons Objekte in die Scenery einbringen.
Es ist auch nicht immer nur die reine Polygon oder Texturlast die hinsichtlich Performance zählt.
Auch ist es nicht unbedingt wie häufig erwähnt der Verdienst ob es sich um hierbei um eine GMAX Scenery handelt. Es gibt auch gute und schlechte GMAX Scenerien. Man kann viel tricksen, nicht immer sind aber Tricks möglich.
Warum ist GMAX hierbei nicht unbedingt das Entscheidende.
Der Grund ist folgender.
GMAX Objekte selbst kann der FS überhaupt nicht direkt
verwenden.
Dieser Code muss für Scenerien erst in ein gültiges FS BGL Format umgesetzt werden.
Bei den BGLs gibt es aber verschiedene BGL Formate die der FS2004 noch verarbeitet. Das geht rückwärts runter bis zu diversen Befehlen des FS2000.
Ich möchte es hier nicht kompliziert machen.
Der Vorteil bei GMAX ist, dass Microsoft das nötige Beiwerk im Zuge eines neuen FS bzw. SDKs mitliefert was man benötigt um aus GMAX Objekten auch aktuelle Scenery BGLs gemäß neuer FS Version erstellen zu können.
Ein wesentlicher Vorteil, ist also das man einen wesentlich effizienteren aktuellen BGL Code erhält, der oftmals vom FS auch anders als älterer BGL Code verwertet wird.
Prinzipiell ist die bessere Performance von GMAX Scenerien zu einem sehr hohen Anteil auf den optimaleren aktuellen BGL Code zurückzuführen.
Dazu muss man aber kein GMAX haben. Jedes andere halbwegs moderne Objektdesigntool wäre tauglich. Es muss nur in der Lage sein aus seinem Objektcode einen für den FS verständlichen BGL Code zu erzeugen.
Das kann jeder bei einem Designtool integrierte bzw. fremde FS konforme Kompiler erfüllen.
Am besten natürlich einer der aktuellsten Code für den FS2004 erzeugt.
Hier bestehen jetzt die wesentlichen Unterschiede zwischen neuen und alten Objektdesigntools bzw. GMAX.
Oftmals ist nicht der Objektcode im Designtool ein Performanceproblem sondern der BGL Code den man daraus erzeugt.
Ein identischer Quader mit acht Eckpunkten ist ev. kein gutes Beispiel.
Bei komplexeren e.v gar zusammenhängenden Objekten sieht es nämlich schon ganz anders aus. Nicht nur die einzelnen Vertexpoints also Vertices und dessen Positionen im Raum sind entscheident sondern auch welche dieser Definitionspunkte mittels Polygonen später miteinander zu verbinden sind um komplexere Formen zu erzeugen. Genau hier schlägt ein aktueller BGL Code zu. Wenn man hier eine Betrachtung des Byte Code selbst anstellt, wird man erhebliche Unterschiede finden wie diese Definitionen im BGL Code auf Byteebene untergebracht sind.
Bei älteren enthaltenen Objektcode kann man mit Wissen um den Code sich eine Vorstellung erschaffen was da definiert wurde.
Bei aktuellen GMAX basierenden BGL Objektcode sind die Definitionen kaum mehr per Vorstellung auswertbar. Das Verfahren ist mehr an die Hardware bzw. 3D Darstellungstechnik selbst angelehnt. Daher auch bei großen Airports mit vielen Objekten auf begrenzten Raum Vorteile dieses aktuelleren BGL Codes in der Performance.
In was jetzt German Landmarks programmiert ist, müsste man anhand des Bytecode der BGLs erst ermitteln um hier eine Aussage zu treffen.
Auch ist nicht unbedingt gesagt, dass egal welcher BGL Code es wäre gravierende Unterschiede eintreten werden.
Denn es bliebe beim Vergleich Äpfel mit Birnen.
Bei German Landmarks handelt es sich um weit auseinanderliegende Objekte. An einem Airport habe ich alles dicht beieinander.
Hier kann ich mir erlauben hin und wieder einen gemeinsamen REF Point als Bezug für mehrere Objekte zu wählen.
Ein Ref Point und seine zugehörigen Steuerparameter die z.B steuern wann Objekte sichtbar werden schlucken aber Bytes in der BGL, erfordern weiterhin Auswertearbeit durch den FS.
Habe ich mehrere Airporthauptgebäudeobjekte stört ein gemeinsamer zentraler Ref Point und seine Steuerparameter nicht, da z.B alle großen Hauptgebäude gleichzeitig sichtbar werden sollen.
Dieser Ref Point und seine Steuerparameter haben übrigens auch starke Auswirkung darauf wie viel Autogenobjekte im Umfeld dieser Addon Objekte vernichtet wird.
Habe ich weit verstreute Objekte wie bei German Landmarks, funktioniert das mit einem gemeinsamen REF Point nicht. Das geht technisch zum Teil nicht, wenn diese weit auseinander liegen. Weiterhin gäbe es Probleme bei Excludierung von einzelnen Objekten.
Schlimmer noch wäre aber eine sehr weitreichende Vernichtung von Autogenobjekten wenn man so vorgehen wollte.
Wir hätten im Extremfall großflächig null Autogen.
Ergo schleppe ich zwangsweise bei so einem Addon wie German Landmarks unabhängig davon womit sie erstellt wurden wesentlich mehr REF Points und Steuerparameter mit mir rum, die der FS natürlich auswerten muss. Es geht gar nicht anders. Zumal es sich ja auch oftmals um wiederkehrende Library Objekte handelt.
Logisch das schon allein aus obigen Gründen Unterschiede in der Performance existieren müssen, selbst wenn hier die Anzahl der darzustellenden Polygone im Vergleich zu einem Airport gleich wäre.
Grundsätzlich kann man sagen auf GMAX und aktuelle BGL Technik basierende Scenerien haben aufgrund Ihres besseren BGL Codes Vorteile gegenüber älteren Code (vermutlich auch in Sicht Kompatibilität zu neueren FS Generationen)
Man sollte auch wissen, dass egal womit ein ADDON erstellt wurde, man zusammenhängende ObjektScenerien hinsichtlich Performance nicht mit weit verstreuten Objektscenerien trotz ev. identischer Polygonzahl vergleichen kann, da hier grundsätzlich nicht die selben Design Möglichkeiten bestehen.
|