Ich habe anhand eines LOD9 Testmeshfiles welches extreme Bedingungen simmuliert (ähnlich dem LOD11 File was ich unten erwähne) unter TMVL 19
10,5 Frames im Mittel gehabt. Bei der Interpolation die unter TMVL21 stattfindet knappe 8,5 Frames. Das hört sich zunächst nach keinem großen Unterschied an. Ich gehe aber ganz stark aus das man bei einem nicht so stark belastenden Mesh unter TMVL 19 und TMVL 21 größere Abstände erhalten wird.
Besseres Beispiel. Zwei LOD11 Mesh unter TMVL=21. Beide gleich groß. Das eine in den Alpen, das andere im flachen Norddeutschland. Beide arbeiten jetzt mit der selben Rasterweite beim Polygonmodell. Jeder Höhenpunkt alle ca. 19 Meter ist im Nahbereich theoretisch darstellbar.
Die Grafikkarte hat also die selbe Polygonanzahl zu verarbeiten. (das tut sie auch)
Trotzdem ist die Performancelast an der Küste erträglich, die Frames sind gut. Im Gebirge gehen sie wesentlich stärker zurück, der FS wird trotz identischer Polygonanzahl viel stärker belastet.
Ich habe diese Tests im Zuge meiner Doku gemacht. Hier habe ich das flache Mesh mit der Extremvariante, einem Kunstmesh verglichen wo sich die Höhe ständig ändert.
Wir haben im Nahbereich definitiv ein identisch dichtes Polygonmodell. Beim flachen LOD11 Mesh lagen meine Frames im Mittel bei ca. 22 Frames.
Bei dem LOD11 Mesh wo ständig Höhenänderungen stattfanden lagen sie bei ca. 7 Frames.
Ein extremer Unterschied trotz identischer Polygonanzahl.
Aufschluss bringt es, wenn man sich mal die zugehörigen Meshfiles anschaut.
Bei identischer Flächendefinition und damit identischer Anzahl von Höhenpunkten/Polygonen belegt das flache LOD11 Mesh nur 2270Byte, das Mesh mit sich ständiger Höhenänderung belegt 34818Byte.
Das Extremmesh belegt bei identischer Flächendefinition also 15,34 mal so viel Speicherplatz.
Der Grund ist das Kompressionsverfahren was Microsoft nutzt, wenn man bei der Meshproduktion mit den SDK Tools arbeitet.
Sehr schön ist hier der Vergleich zu dem SRTM Rohdaten der NASA aus denen viele Ihre Meshfiles produzieren. Diese SRTM Rohdaten sind nicht komprimiert. Hier ist jedes File gleich groß, egal ob es die Küste oder Gebirge enthält.
Bei den Meshfiles des FS kann man eindeutig feststellen, dass die Terrainengine des FS in der Lage ist diese komprimierten Daten direkt zu verwenden, ohne das sie erst groß zurückgerechnet werden müssen. Wäre das zurückrechnen das Problem, dann müsste auch das flache Mesh erst zurückgerechnet werden. Die Frames müssten näher beeinander liegen.
Von daher ist dieses ein schönes Beispiel dafür, das hier nicht die Polygonanzahl die Framebelastung ausmacht, sondern eher die Datengröße (die Art der Nutzinformation) des Meshfiles und damit letztendlich wie oft Höhenänderungen stattfinden.
Es wurde schon mal mit variablen Meshfiles bei einem Produkt geworben. Also in flachem Gelände niedriger LOD Level, im Gebirge hoher LOD Level.
Gut gedacht, aber aufgrund dieses Sachverhaltes der Datenkompression der Meshfiles und der Terrainengine wird es die Framerate nicht gravierend verbessern.
Ich möchte natürlich mit dieser Aussage niemand zum oversampeln verleiten.
Auf jeden Fall kann man sehen das es Verschiebungen (Nutzinformation zu Polygonanzahl) bei der Framebelastung geben kann.
Ich kann es bei aktueller Technik nicht beweisen wie lange ein G-MAX Objekt entfernungsmäßig im Speicher ev. vorgeladen ist und wann es definitiv rausfliegt.
Auch Arno hatte erwähnt, dass es dazu von Microsoft bei aktueller Technik keine genauen Aussagen gibt.
Früher bei älterer Technik hätten wir genaue Aussagen machen können.
Es wird aber einen Maximal Radius geben wo der FS sich dieser Informationen entledigt, ansonsten wäre er nicht lauffähig.
Das bedeutet wenn wir unsere Sichtweite der Objekte erhöhen, dann kommen diese näher an die Grenze wo sie auch aus dem Speicher verschwinden würden. Wenn es bei aktuellen Code einen Bereich gibt wo Sceneryinformationen quasi unsichtbar vorgeladen sind, dann wird dieser Bereich bei Erhöhung der Sichtweite der Objekte zwangsläufig schrumpfen müssen.
Was würde das bedeuten?
Bei einer Objektscenery mit extrem vielen dicht beieinander stehenden Objekten (denen wir eine sehr geringe Sichtweite anprogrammieren) wird aufgrund der kleinen Fläche die reine Polygonzahl der von der Grafikkarte zu berechnenden Objekte und zu rendernden Texturen niedrig sein.
Also wenig Framebelastung durch Polygone.
Die flächenmäßig bis an Rand wo eh alles aus dem Speicher fliegt vorgeladenene unsichtbare Objektinformationen (wo diese zu stehen haben) ist aufgrund der größeren Fläche und hohen Dichte stärker belastend. Diese Informationen werden ja zum Teil quasi auf Abruf im Speicher vorgeladen sein.
Würde man die Sichtbarkeit der Objekte erhöhen, muss die Grafikkarte auch mehr Polygone berechen und rendern. Wir sehen sehr viel mehr Objekte.
Die Fläche der unsichtbaren Objekte bis zum Rand wo der FS diese Informationen aus dem Speicher schmeist schrumpft.
In diesem Fall ist die Belastung durch darzustellende Polygone höher als durch die restliche unsichtbare Objektinformation
Eindeutig eine Verschiebung der Belastung des Gesamtsystemes.
Man kann sich das wie einen riesigen großen Kreis mit festem Radius vorstellen. Innen ein kleiner variabler Kreis mit unseren sichtbaren Objekten außen drum herum ein Ring mit unsichtbaren vorgeladenen Objekten.
Da wir es hier mit Flächen zu tun haben, ist es nicht auszuschliessen das wir Verschiebungen bekommen.
|