So ein Bild sieht man z.B auf Seite 283 der Doku.
Hier das das verwendete LOD11 Mesh im abgesenkten Bereich (welches auch ein LOD11 Addon Mesh sein könnte) nur innerhalb des gelben MIP Level Bereiches arbeitet. (also verkoppelt ist)
Eine Tabelle mit den Verkopplungen MIP Level zu LOD Level von Mesh findet man auf Seite 306 der Doku.
Damit sollte eigentlich auch klar sein, dass der FS Addon Mesh Files immer gestaffelt je nach LOD Level in der Tiefe des Raumes zur Anwendung bringt. Also im Nahbereich Mesh Files mit höheren LOD Level im außenliegenden Bereichen gestaffelt welche mit niederen LOD Leveln.
Da kann auch niemand etwas dran ändern, egal wie er Meshfiles in der Scenerybibliothek anmeldet. (es ist im FS2004 in der Terrain Engine so programmiert)
Im Nahbereich werden immer die hochwertigst aufgelösten Meshfiles die man für die Gegend besitzt angezeigt, danach in der Tiefe des Raumes gestaffelt die nächst niederwertigen die man findet.
Dem zu Folge ist natürlich auch diese Aussage die man in einem aktuellen Meshthread im Anfängerforum findet:
"Das Mesh (ist übrigens nur die Darstellung des Höhenmodells) kann sich nicht überlagern. Es wird immer das Mesh aktiv, das in der Region in der höchsten Ebene liegt."
falsch insofern die Aussage sich auf die Priorität in der Scenerybibliothek bezieht, wo man aufgrund des Textes von ausgehen kann.
Regeln kann man die Priorität nur dann, wenn es sich um konkurierende Meshfiles gleichen LOD Levels handelt. Dann gilt wegen eines Bugs im FS2004 allerdings eine umgekehrtes Prioriätsverhältnis. Man muss bewusst eine gewünschte Meshscenery ganz tief in der Bibliothek anmelden. Sind konkurierende Meshfiles nicht absolut deckungsgleich, kann es leider sein, das man überhaupt keine stabilen Prioritätsverhältnisse herstellen kann. Siehe Doku ab Seite 248.
Das Meshproblem soll hier nicht so wichtig sein.
Wichtig ist das man weis, dass obige drei Parameter auch Verarbeitungsreichweiten von Mesh beeinflussen. Stellt jetzt nämlich jemand bei den Radiuswerten hohe Werte also z.B bis maximal 4 ein, dann wird der FS nicht nur dadurch belastet, dass nun höherwertige Bodentextur MIP Level flächenmäßig größer dargestellt werden sollen, sondern auch wenn entsprechende Addon Mesh Files vorliegen mehr Meshhöhendaten pro Fläche verarbeitet werden müssen. Die Frames werden dann in der Regel im FS sinken.
Das ist tragisch. Denn es ist im FS2004 nicht so wie ITSIMON hier sagt:
"Gerade die Framerate würde ich begrenzen, damit mehr Leistung auf das Nachladen gelegt wird"
Beim FS2004 ist das Nachladen der Bodentexturen im Gegensatz zum FSX (wo wir das Verhältnis sogar über Parameter zusätzlich beeinflussen können) nämlich auch mit der erreichten Framerate verkoppelt.
Umso niedriger die dargestellte Framerate umso weniger Texturmiplevel werden von Festplatte nachgeladen. Eine Scenery wird noch schneller unschärfer als wenn die Frames höher wären.
Siehe auch Doku, die Messkurve auf Seite 488.
Die Zahlenwerte meiner Kurve lassen sich leider nicht 1 zu 1 direkt auf jedes PC System übertragen.
Dennoch bleibt der Kurvenverlauf selbst (Sachverhalt) bei jedem System wo der FS2004 läuft identisch, nur die Zahlenwerte ändern sich.
Das ist schon mal mit einer der entscheidenden Punkte. Der FS2004 benötigt speziell bei abwechslungsreichen Landclass bzw. Fotoscenerien unbededingt hohe Frameraten um immer scharfe Bodentexturen garantieren zu können. Umso höher die Frames bei festen Parametern, umso besser ist es hinsichtlich scharfe Texturen. Diesen ganzen Sachverhalt kann man z.B im Kapitel
44)Problematik unscharf werdender Bodentexturen bei Foto und
Landclass Scenerien, ruckelige Darstellung im Flug
nachlesen. Da kann man auch erfahren, dass die Transportleistung von Texturmipleveln von Festplatte bis zum Speicher eine entscheidende Rolle spielt. (Ein Virenscanner mit Echzeitüberwachung, eine lahme, fragmentierte Festplatte kann hier z.B auch bremsen und zu unscharfen Texturen und Ruckeln führen)
Auch andere Daten die zusätzlich von Festplatte geladen werden müssen behindern die Texturmiplevel Transportleistung (Doku Rolltreppenbeispiel)
Dieses Kapitel 44 scheint Phil offensichtlich nicht gelesen zu haben.
Ihr fixiert euch alle zu stark auf diese Radius Werte.
Sie geben aber im wesentlich nur vor, wie groß maximal die MIP Level Flächen bzw. Verarbeitungsreichweiten von Meshfiles mit jeweiligen LOD Level werden......... könnten!!!!!!
Das soll z.B die Testscenery die Phil gewählt hat demonstrieren.
Ob es der FS schafft während des laufenden Betriebes überhaupt diese oftmals durch zu hohe Radius Werte geforderten Flächen mit benötigten MIP Level / Meshdaten von Festplatte zu beliefern ist eine ganz andere Sache.
Wenn die PC Performance nicht ausreicht, dann schafft das der FS nicht mehr.
Auf meine Testscenery bezogen bedeutet das:
Beim Start hat man noch die geforderte organge große Fläche, während des Fluges sollte sie eigentlich auch mit dem Flugzeug in dieser Form mitwandern, doch der FS schafft es nicht mehr. Sie wird irgendwann grün, dann gelb usw. sprich unschärfer.
Da ist diese von Phil gewählte Demoscenery von mir eigentlich nicht geeignet, denn sie verwendet nur eine einzige Landclassnummer und dessen 7 zugehörigen Texturen großflächig.
Immer wenn der FS in einem Landclassfile größere zusammenhängende gleichartige LC Nummern vorfindet weis er per Logik, dass es nicht nötig ist Texturmiplevel nochmals nachzuladen.
Das ist bei dieser gewählten Testscenery der Fall. Sie dient wie gesagt nur der Demonstration der Funktion der drei Parameter.
|