neue Bodentexturen!

[JOBIA]

Ein Beispiel:

Zwei LOD11 Meshfiles unter TMVL=21. Beide flächenmäßig gleich groß. Das eine in den Alpen, dass 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 fast 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 nahezu identischer Polygonanzahl viel stärker belastet. Ich habe diese Tests im Zuge meiner Doku gemacht. Hier habe ich das flache Mesh mit einer extremen Variante, einem von mir erzeugten Kunstmesh verglichen wo sich die Höhe nahezu ständig ändert. Wir haben im Nahbereich definitiv ein identisch dichtes Polygonmodell. Beim flachen LOD11 Mesh lag meine Framerate im Mittel bei ca. 22 Frames. Bei dem LOD11 Mesh wo ständig Höhenänderungen stattfanden, lagen sie bei ca. 7 Frames.

Wir sehen ein ganz extremer Unterschied trotz identischer Polygonanzahl und Fläche.

Aufschluss bringt es, wenn man sich mal die zugehörigen Meshfiles anschaut.

Bei identischer Flächendefinition und damit identischer Anzahl von umgesetzten Höhenpunkten belegt das flache LOD11 Mesh nur 2270Byte. Das Mesh mit sehr häufiger Höhenänderung belegt bei mir 34818Byte.

Das Extremmesh belegt bei identischer Flächendefinition also 15,34 mal so viel Speicherplatz.

Der Grund ist wie gesagt das Kompressionsverfahren, welches die Microsoft SDK Tools bei der Mesherstellung nutzen. Habe ich z.B ein LOD11 Meshfile, welches 257 x 257 Höhenpunkte also 66049 Höhenpunkte auf einer festen Höhe definiert, dann wäre es unsinnig jeden der Höhenpunkte mittels 16Bit also 2 Bytes im Meshfile umzusetzen.

Ich habe leider noch keine Möglichkeit gefunden einen eindeutigen Beweis zu liefern, aber es würde mich nicht wundern wenn die Terrainengine in der Lage ist direkt ohne Dekompression der Meshfiles Ihr 3D Gelände aufzubauen. Die sehr unterschiedliche Performance bei den obigen LOD11 Meshfiles spricht eigentlich dafür. (nur wie gesagt ein eindeutiger Beweis ist das leider nicht)

An diesem Kompressionsverfahren kommt kein Designtool herum. Bis auf eine Ausnahme sind nämlich alle Tools für Meshdesign nur vorbereitende Tools die einem etwas Arbeit speziell bei der Vordefinition abnehmen. Der eigentliche Programmierprozess läuft mit dem SDK Tool resample.exe ab. (bei älteren Versionen werden weitere SDK Tools benötigt)


Dokuauszug Ende



Das passt natürlich zu meiner hier im Forum gemachten Aussage. Haben wir also ein LOD12 Addon Mesh welches extrem viele Details im Gelände darstellt (nur da würde es einen Sinn ergeben), dann enthält es trotz Kompression sehr viel mehr Bytes an Information als ein LOD11 Mesh der selben Gegend.

Der FS muss natürlich alle Byte Informationen eines Meshfile verarbeiten.

Das allein kostet Performance wie man oben sehen kann.

Nicht der LOD Level ist hier so entscheident sondern die Bytes die ein File pro Fläche mitbringt.

Von daher belastet ein LOD 12 Mesh welches einen Sinn ergeben soll, zwangsweise den FS höher als ein LOD11 Mesh der selben Gegend.

Es sei denn beide spielen sich in flachen oder relativ unspektakulären Gelände ab. Nur da wäre die Verwendung eines LOD 12 Mesh nur wegen dem Gelände Unsinn.

Von daher würde ich die Aussage ob LOD12 oder LOD11 ist doch egal bei den heutigen riesigen Festplatten so nicht stehen lassen.

Es geht hier auch um die Performance des FS2004.

Ich glaube bei diesem Thema dürfte es den meisten Anwendern nicht egal sein ob LOD12 oder LOD11.



Es gibt wie gesagt eh viele Nachteile durch einen hohen TMVL den wir z.B zusätzlich bei einem LOD11 Mesh in der FS9.CFG einstellen müssen um es als solches sehen zu können.

Ich könnte da auf diverse Beiträge von mir verweisen.



Einen Nachteil habe ich bisher selten genannt. Ev. zwei bis drei mal hier im Forum in Bezug zu LOD11. Aber ich kann mich gut daran erinnern, dass ich dieses früher zu FS2002 Zeiten schon mal gemacht habe.

z.B habe ich solche Aussagen gemacht:

Der FS verschiesst sein 3D Pulver bei hohem LOD Level im Vordergrund..... oder...... Vorne hui, hinten pfui.


Aber siehe dazu irgendwann Doku.

Das Polygonmodell selbst arbeitet nämlich auch dynamisch. Das jetzt zu erklären würde allerdings den Rahmen sprengen.







Zu

"Jobia: sehr interresant! Wenn also die Terrain Engine auch bei einer per TMVL erzwungenen Aufloesungs"bremse" interpoliert,"



Zu diesem Thema hatte ich ja bereits erwähnt, dass es sich um eine Vermutung handelte bei dieser Interpolation durch TMVL Begrenzung.

Grund war eines meiner neu erstellten Testfiles im Zuge der LOD12 Diskussion letzte Woche. Dieses hatte mir einen Sachverhalt vorgekaukelt, der mich zunächst zweifeln lassen hat, ob das Verfahren der Auflösungsreduzierung welches ich in meiner Dok. beschreibe korrekt ist.

Es hat sich aber glücklicherweise rausgestellt, dass der FS eine Konstellation in dieser Form wie ich es im Testfile hatte nicht umsetzen kann.

Den Sachverhalt den ich letztes Jahr im Sommer ermittelt hatte ist korrekt und bleibt weiterhin gültig.

Es geht hier wie gesagt um die Begrenzung durch TMVL bzw. um die Auflösungsreduzierung eines Mesh innerhalb seiner Verarbeitungsreichweite.

Dort gibt es zwar auch noch eine Interpolation die tritt aber nicht überall in Erscheinung. Die möchte ich hier zunächst auch nicht erwähnen.

Siehe Vorne hui, hinten pfui.