Hallo Horst

Interessanter Link zum Avsim Forum den Du gesetzt hast. Mit dieser Upperframerate und LOD Target Geschichte in diesem Thread bewegen wir uns auf einer etwas höheren Niveaustufe als in der dortigen Diskussion.

Ich meine das nicht bezogen auf die dortige Diskussion selbst, sondern nur von der Thematik her. Wir sind eine Ebene höher von der Technik. Wir beschäftigen uns damit ob wir einen frameratebezogenen Einfluss auf Objektcode mit den zuvor erwähnten Stellgliedern haben können oder eben nicht.

Im AVSIM Thread geht es im wesentlichen darum was denn den FS nun bei Objektcode im wesentlichen belastet.

Von daher hast Du recht, es passt vom Sachverhalt eindeutig zu der Thematik in diesem Thread.

Aber wie so oft kann man auch im dortigen Thread sehen, dass immer wenn es um das Thema Frames geht die Aussagen variieren. Einiges im dortigen Thread ist wenn man alle Beiträge liest wiedersprüchlich.



Aqui hat den FS mit sehr vielen sichtbaren Objekten belastet, ganz klar er hat heftige Frameeinbrüche. Was kurios ist, er ist der Meinung das er die selben Frameeinbrüche auch hat, wenn er die Objekte mit einer Sichweitenbegrenzung belegt. Dadurch werden nur im Nahbereich seine Objekte dargestellt. Sehr viele der Objekte tauchen erst auf wenn man sich Ihnen nähert.

Normalerweise sollte das was man nicht sieht den FS auch nicht belasten. (könnte man meinen)

Dick seine Antwort darauf ist das Aqui im Prinzip recht hat.
Es entscheidet nicht ob etwas sichtbar ist oder nicht, sondern ob der FS diese Informationen schon im Speicher hat und mit diesen Informationen arbeiten muss.

Die Objektinformationen sind in der Regel schon geladen bevor sie sichtbar sind.

Diese Polygon-, Textur und Positionierungsinformationen der Objekte sind also zum Teil schon vorhanden, folglich werden diese auch den FS belasten. Im wesentlichen sind es laut Dick wohl die vielen Polygone die den FS belasten (auch schon bevor man sie sieht).

Falls ich Dick richtig interpretiere schliesst er auch nicht aus, dass Multi-Resolution Modelle die aufgrund Ihrer zusätzlichen niederwertigen LOD Level weitere Polygone mit sich bringen den FS zusätzlich belasten könnten.

Ich kann Dick falsch interpretiert haben, gegen diesen Sachverhalt würde dann aber die Äußerung von Microsoft sprechen LOD Level Modelle zu verwenden. Sergio erwähnte in der FXP das Microsoft dieses empfiehlt.


Das mit den Multi-Resolution Modelle kann ich mir nicht vorstellen, da es die ganze 3D Welt auf den Kopf stellen würde. Zumal wir diese LOD Modelle im FS bei verschiedenen Techniken antreffen.


Vincent vertritt die Meinung das vermutlich nicht die Polygonanzahl den FS belastet sondern eher die Anzahl der Objekte selbst. Seine Frames waren bei sehr vielen Objekten ähnlich schlecht egal ob es sich um komplexe oder einfache Objekte handelt.

Ich denke Arno hat in dem Thread die eindeutigsten Aussagen gemacht.

Ich vertrete auch Arnos Meinung:

Umso mehr Details an einem Objekt umso mehr Polygone benötigen wir. Dadurch muss zwangsweise die Performance belastet werden. Die Frage ist in welchem Verhältnis dieses geschieht.

Wie Arno richtig schreibt, wächst mit der Anzahl der Objekte logischer Weise natürlich auch die Anzahl der darzustellenden Polygone mit.

Durch mehr Polygone weniger Performance. Immer wenn wir mehr Objekte haben, dann haben wir zwangsweise auch mehr Polygone. Von daher denke ich könnte manch einer auf die Idee kommen das es nur mit der Anzahl der Objekte zusammen hängt. Dem wird mit Sicherheit nicht so sein.

Bleibt die Frage warum Vincent sein PC bei gleicher Objektzahl bei komplexeren Objekten nicht wesentlich stärker als bei der gleichen Anzahl einfacherer Objekte belastet wird.

Ich denke auch hier ist Arnos Antwort naheliegend. Aus seiner Sicht kommt es darauf an wieviele Objekte in Vincent seiner Scenery überhaupt angezeigt werden. Weiterhin wie stark die Frames bei Vincent überhaupt einbrechen.


Das ist auch meine Meinung. Man wird mit Sicherheit nicht sagen können 20% mehr Objekte im FS lassen diesen auch um 20% in den Frames einbrechen.

Meiner Meinung nach kommen da so viele Variablen zum Einfluss, dass hier eine eindeutige Aussage nicht möglich ist. Unser PC wird nicht nur durch den FS sondern auch durch das Betriebssystem und andere Prozesse belastet. Der PC wird beim FS durch viele andere Techniken belastet, Sceneryverwaltung, Wettergeneration, AI-Traffic um ein paar wenige zu nennen.

Die Objekttechnik ist nur ein Teilaspekt der den FS belastet.

Wir müssen auch beachten das der PC ein System aus verschiedenen Komponenten ist (CPU, Grafikkarte, Speicher usw.)

Nicht jede dieser belastenden Techniken belastet jedes Element des PC gleichmäßig.

Einige Techniken belasten mehr die CPU andere wieder mehr die Grafikkarte.

Man kann daher mit Sicherheit nicht sagen das bei linear zunehmender globaler Scenerylast (nicht nur auf Objekte bezogen) die Performance auch halbwegs linear einbricht.

Es ist zu erwarten, das sich die jeweilige Belastung je nach Hardwarekomponenten verschiebt.

Was wenn Vincent sein System durch extrem viele Objekte so stark belastet hat, dass eine Verdopplung der Polygonzahl bei diesen Objekten auch nicht mehr viel schlimmeres hinsichtlich niedriger Frames anrichten kann.

Ich denke da auch an den letzten Beitrag von Arno (Stand Donnerstag morgen 24.02.05)

Er hatte eine Testscenery mit sehr vielen einfachen G-MAX Objekten (Würfeln) erzeugt. Diese waren so programmiert das sie von der Sichtweite nicht beschränkt waren.

Wenn er sich innerhalb dieser unbeschränkten Objektscenery befand, hatte er nur noch ca. 4 Frames.

Was hätte da noch größer einbrechen sollen bei etwas komplexeren Formen. Etwa von 4 auf 3,6 Frames.

Wenn er nur einen Teilbereich der Scenery im Sichtfeld hatte waren es schon 10 bis 20 Frames.

Das bestätigt zumindest schon mal eindeutig, dass Objekte die nicht sichtbar sind, auch nicht unbedingt die Performance des FS belasten. Irgendwann fliegen die Information raus bzw. werden es später geladen.


Den nächsten Test hat Arno mit Sichtbeschränkungen bei den Objektwürfeln gemacht. Es wurden nur die Würfel in der Scenery sichtbar, die nicht weiter als 500 Meter entfernt waren.

Das bedeutet weniger sichtbare Objekte auch wenn man sich mitten in der Scenery befindet.

Arno hatte jetzt relativ konstante 17 Frames. Also besser als die 4 Frames ohne Sichtbeschränkungen bzw. die 10 bis 20 Frames bei Teilsicht auf die unbeschränkte Scenery.

In meinen Augen logisch ein anderes Verhalten wäre in meinen Augen auch tödlich für den FS.

Arnos Test spricht natürlich vom Sachverhalt gegen Vincent seine Feststellung, teilweise auch gegen Aqui seine.


Wir sehen die Problematik ist komplex.

Ich vermute, das Aqui und Vincent Ihre PC Systeme einfach an Ihre Grenzen gefahren haben.

Da ich zwei unterschiedlich leistungsstarke PCs habe, sehe ich es selbst anhand meiner Testscenerien immer wieder, wie unterschiedlich stark die Frames bei identischer Belastung bei beiden PCs zurückgehen.

Beim 3,4GHz Desktop brechen die Frames unter Last wesentlich stärker ein als beim Notebook mit 2,53GHz. Trotzdem liegen die Frames beim 3,4GHz wesentlich höher. Es ist halt ein Unterschied wenn die Frames von 85 auf 20 beim 3,4GHz einbrechen als wenn sie beim Notebook von 22 auf 17 zurückgehen.

Belastet man noch mehr, werden die Unterschiede im Grenzbereich noch geringer.

Ich denke Vincent und Aqui werden genau diesen Effekt der Extrembelastung gehabt haben.

Aqui sagt:

I'm working on a complex scenery with thousand of High Voltage towers and telephone poles.

Vincent spricht bei seiner Theorie von:

When there are thousands just keeping track of the ref points must add an enourmous amount of cpu calculations.


Aufgrund der Anzahl genannter ref points können wir auch bei ihm von Tausenden von Objekten ausgehen.

Normalerweise exitieren solche belastenden Scenerien mit tausenden von Objekten (bei hoher Dichte) im FS überhaupt nicht. Ausser beim reinen Autogencode. Bei den Autogenbäumen und Autogenhäusern handelt es sich aber auch um einen ganz anderen Objektcode. Der ist mit G-Max Objekten vermutlich überhaupt nicht vergleichbar.

Keine Ahnung wie dieser Autogenobjektcode genau definiert ist.

Ich denke aber nicht das es dort so viele Informationen wie bei den G-MAX Modellen mit Vertexlist, Polygonlist, Materialinformationen usw. gibt.



Eine Thematik bleibt, was belastet den FS mehr?

Die reine Anzahl der Objekte?

Die Anzahl der Polygone?

Wäre es überwiegend die Anzahl der Objekte anstatt der Polygone, dann würde das bedeuten, es wäre egal wie komplex die Objekte sind. Wir müssen nur dafür sorgen das es wenig Objekte sind.


In meinen Augen wäre das äußerst unlogisch.

Denn wenn es so wäre, dann würde ich mir doch als Airportdesigner meine Gedanken machen.

Ein Großairport muss aktuell wegen des AI Traffic auf dem Apron usw. eh waagerecht flach sein.

Da würde ich doch jetzt als Designer einfach auf die Idee kommen anstatt zwei einzeln stehenden Terminalkomplexen (ein Gebäude rechts, ein Gebäude links) einfach einen großen zusammenhängenden Terminalkomplex zu programmieren. Die rechte Hälfte ist sichtbar oberirdisch, die Mitte wird unsichtbar ins Mesh abgesenkt, die linke Hälfte ist wieder sichtbar oberirdisch.

So habe ich nur ein einziges Objekt programmiert. Das benötigt jetzt zwar mehr Polygone aber anstatt zwei Objekten existiert nur eines.

Ev. habe ich ja sogar Glück und die Terrainengine erkennt, dass ein Teil des Objektes im Mesh versunken ist. Die Grafikkarte freut sich, denn sie weis das sie mit diesen versunkenen Polygonen nicht arbeiten muss. Es müssen auch keine Texturen gerendert werden.


Tolle Sache. Warum nicht den ganzen Airport als ein einziges Monsterobjekt mit vielen tausenden Polygonen zeichnen.

Das würde die Frames doch theoretisch in die Höhe treiben. Der Super Addon Airport. Detailierter als alles andere was jemals da gewesen ist. Das ganze mit einer Performance die besser ist als jeder Kleinstairport wo nur eine Zapfsäule steht.

Ehrlich gesagt das kann nicht funktionieren.

Bezüglich Frames möchte ich allerdings diese Geschichte:

"Höhere Belastung durch Objektanzahl oder Polygonanzahl?"

nicht ganz von der Hand weisen.


Ich schliesse nicht aus, dass es hin und wieder gewisse Verschiebungen hinsichtlich Framebeeinflussung geben kann.

Das ganze bedingt dadurch wie diese Objekte oder nennen wir es 3D Information geliefert wird.

Mal wirkt sich die Anzahl der Basisinformationen etwas stärker aus, mal liegt der Schwerpunkt bei der Anzahl der Polygone.

Das ganze ev. auch etwas abhängig davon, was beim Anwender besser von der Performance ist. (Grafikkarte, CPU, RAM).

Es kommt hier darauf an wie die Technik der Informationen ausgelegt ist.


Ein Beispiel:

Ich erwähnte in einem anderen Thread wo es um das Thema Mesh geht, dass der FS z.B bei einem LOD 9 Mesh unter Manipulation des Parameter TERRAIN_MAX_VERTEX_LEVEL von 19 auf 21 im Nahbereich das LOD9 Mesh zusätzlich interpoliert. Die Polygonstruktur liegt obwohl das Mesh nur LOD9 hat jetzt wie bei einem LOD11 Mesh vor.

Das bedeutet wir haben bei identischen Mesh im Nahbereich sehr viel mehr darzustellende Polygone als vorher.

Die Performancelast steigt aber trotzdem nicht überdurchschnittlich an.

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.

Die Verschiebung hinsichtlich Framebelastung "abhängiger von Polygonzahl oder Objektanzahl" wäre dann von der Sichtbarkeitsgrenze und dem Abstand der Objekte untereinander abhängig. Speziell unter Library Technik. Denn wir können bei der Librarytechnik in gewissen Maße einen Vergleich zu dem Kompressionsverfahren bei der Meshtechnik ziehen.

Wenn dann noch Multiresolution Modelle zur Anwendung kommen, würde das noch komplexer ausfallen.

Bei älterer Technik hätte ich zumindest was die gedachten Kreise betrifft eindeutigere Aussagen machen können.


Wer weis ev. regeln wir ja mit LOD Target Frames diesen Bereich der vorgeladenen Objekte frameabhängig.

Nur der Nachweis dürfte schwierig sein.


Aber das schweift jetzt zu sehr von den eigentlichem Thema des Threads ab.

Auf jeden Fall sieht man wieder mal wie komplex die ganzen Zusammenhänge doch sein können. Leute testen und erhalten aus oben erwähnten Gründen ev. ganz andere Ergebnisse.

Hallo Joachim,
Sehr schwierig beizutragen, da sehr umfangreich und es verschiedene Bereiche abdeckt!
Wie du schreibst, es ist tatsächlich sehr komplex, und vor allem auf unseren Heim PCs und der Möglichkeit der Abänderung von Codes fast unmöglich die Auswirkungen festzustellen.
Wir können nur den subjektiven Bereich messen (mit was? bzw. überprüfen), und dies auf sehr unterschiedlichen PCs und Konfigurationen.

Im Prinzip denke ich, der LOD Target Schieber dient den LOD der Texturen. (reine Vermutung)
Er ist mir im Prinzip egal.
Ich stelle bei mir ganz einfach keine Auswirkungen fest, die ich optisch und vor allem begeisternd wahrnehmen kann!

Über Objektcode (also nicht agn oder terrain.cfg, sondern Autogen\default.xml, oder eigenes xml) habe ich, so vermute ich, keinen Einfluss mit diesem LOD Target Parameter.

Man empfiehlt zwar Multi- Resolution, aber setzt man es auch korrekt um, bzw. macht man es bei eigenen Objekten?
Aber hat, wie geschrieben, mit diesem Wert, meiner Meinung nach, nichts zu tun.

Horst

Ich habe beim LOD Target auf alles geachtet. Ich konnte nirgends etwas entdecken auch keinen Einfluss auf Texturen egal über welche Scenerytechnik diese zugewiesen wurden.


Bei LOD Modellen wie gesagt auch nicht.

Microsoft wendet diese LOD Modelle konsequent an.


Ich kann es eindeutig beweisbar nachweisen.

Von daher hat sich das eigentliche Thema dieses Threades erledigt.

Dieser Parameter LOD Target hat keinen nachweisbaren Einfluss. Bisher hat bei meiner genaueren Hinterfragung sich noch keiner gemeldet der Auswirkungen erkennt.


Aus diesem Grund hat sich auch der immer wieder kehrende Tipp mit UPPER_FRAME_RATE und LOD_TARGET_FPS endültig erledigt.


Es funktioniert nicht!!!!!


Von daher werde ich an diesem Thema nicht mehr weiterarbeiten und auch nichts mehr zu schreiben.


Ausnahme es meldet sich jemand mit neuen Sachverhalt oder Beweis.

Jobia, ich möchte dir nochmals herzlich danken für den 'brain-food' den du hier zubereitet hast. Great stuff und äusserst interessant!


Du hattest übrigens recht, dass das Verhältnis LOD/Framelock rund 70% ist und nicht 2/3 wie ich gedacht habe. Ich habe nochmals ein bisschen rumprobiert und die folgende Gleichung gefunden (min. gültig bis zu einem Lock von 45): LOD_Target_FR = 2/3 des Locks + 1. Bei 45 müssten sich nach der 70% Regel, eine LOD von 32 (31.5 plus Aufrundung) ergeben, tut es nicht, sondern es resultiert 31.

Wie gesagt, freue ich mich riesig auf deine Doku.

Take care, good luck und Grüsse

Jaap

Danke

Was diese Objektgeschichte unter G-Max betrifft.

Man könnte das natürlich genau rausbekkommen wann etwas aus dem Speicher fliegt usw.

Aber ich denke darüber kann man sich Gedanken machen wenn jenmand feststellt es ergibt auch einen Sinn sich damit zu beschäftigen.

Ich habe noch mal neue Tests anhand eines Testlandclassfiles welches hinsichtlich Belastung den schlimmsten Zustand darstellt den es für den FS2004 geben kann durchgeführt. Überlagert war eine zweite Testlandclasscenery die nur stichpunktartig farblich den Zustand des MIP Level Status einblendet. Stichpunktartig damit die Belastung erhalten bleibt.

Anhand dieser stichpunkartigen farblichen Einblendung ist eine eindeutige Aussage möglich wo gerade welche MIP Level Qualitätsstufe der Bodentexturen aktiv ist.

Es wurde wieder mit den Paramtern LOD_TARGET_FPS= und UPPER_FRAMERATE_LIMIT gearbeitet.
Getestet wurde der Überflug mit dem Learjet bei sehr hoher Geschwindigkeit unter Autopilot. Das ganze bei gemäßigter Höhe (fliegt man zu hoch schaltet der FS von sich aus im Nahbereich auf einen niederen MIP Level zurück)

Auf meinen schwächeren Notebook konnte ich bei Variation der erwähnten Parameter keine Unterschiede erkennen. Die Texturen wurden unscharf und erholten sich auch eigentlich nicht richtig.

Bei dem P4 3,4GHz der unter normaler Landclasscenery bei mir nie hinsichtlich MIP Level eingebrochen war, ist mit dieser speziellen Testscenery und schnellen Überflug jetzt erkennbar, dass der FS es nicht mehr schafft die Texturen im Nahbereich im höchsten MIP Level zu halten.

Ich habe hier zwar kein extremes Problem wie andere, es wird nie groß unscharf ich erkenne aber eindeutig das er manchmal nur die MIP Level Stufe 1 bei Bodentexturen im Nahbereich schafft. Zur Erinnerung MIP Level Stufe 0 mit 256 x 256 Pixeln hat die höchste Qualität. MIP Level 1 hat nur noch 128 x 128 Pixel und wirkt etwas unschärfer.

Jetzt kommt es. Hatte ich zuvor die Framevorgabe im Displaymenü bzw. die UPPER_FRAMERATE_LIMIT in der FS9.CFG auf 20 begrenzt, schaffte er die höchste MIP Level Stufe 0 des öfteren nicht. Stelle ich die Framevorgabe auf unendlich also UPPER_FRAMERATE_LIMIT auf 0 dann hatte er durchweg keine Probleme auch die höchste MIP Level Stufe 0 zu halten.

Es ist also doch was dran an dem Tipp!!!!!!

Das Problem ist, man kann es je nach PC Performnance bzw. Scenerylast ev. nicht nachweisen.


Mein 3,4GHZ muss schon besonders gequält werden um einen Effekt zu sehen. Der Notebook ist hingegen schon fast zu schwach um etwas zu erkennen.

Allerdings habe ich festgestellt das nicht die Einstellung der Framevorgabe auf unendlich (wie im Tipp) entscheident ist sondern das sie generell hoch eingestellt wird.


Ich habe dann anhand der aktuellen Fotoscenery Real Germany 3 weitere Tests durchgeführt.

Hier wurde der PC immer an einer markanten Stelle mittels gespeicherten Fluges aufgesetzt.

Von hier aus wurde das Flugzeug im Slewmodus um etliche Kilometer mit maximaler Geschwindigkeit an eine andere Stelle an einen markanten Berghang versetzt. Klar die Texturen waren dann total unscharf. Es wurde nun die Zeit gestoppt bis sich der höchste MIP Level der Texturen aufgebaut hat.

Eines vorweg man merkt hier eindeutig ob der FS bei eingeschalteten PC schon mal in dieser Flugsituation gestartet war. Er greift definitiv auf Teile die noch im Speicher liegen zurück.

Bei Framevorgabe unendlich also UPPER_FRAMERATE_LIMIT=0 dauerte es nach einem Neustart des PC in dieser Prüfsituation ca. 45 Sekunden bis die Scenery scharf war.

War der FS schon einmal gestartet dauerte es nach Neustart des FS nur noch ca. 35 Sekunden.
Das ganze konnte im Toleranzbereich ca. 1 Sekunde nachgewiesen werden.

Bei UPPER_FRAMERATE_LIMIT=20 dauerte es sage und schreibe nachweisbar ca. 75 Sekunden.

Ob ich UPPER_FRAMERATE_LIMIT=0 (unendlich) einstellte oder 96 bzw. 100 erzeugte keinen messbaren Nachteil.

Es ist scheint allein die hohe Einstellung des Wertes zu sein, die Bodentexturen (unter der Vorraussetzung der PC hat halbwegs gute Performance) länger scharf hält bzw. dafür sorgt das sie schneller nachladen.

Bei mir hat ein hoher Einstellwert des UPPER_FRAMERATE_LIMIT allerdings nach wie vor zur Folge das der FS bei abwechslungsreicher Scenery irgendwie optisch nicht so flüssig läuft.



Wo ich allerdings immer noch nichts nachweisbares erkennen kann, ist der zugehörige LOD_TARGET_FPS. Ich konnte bei keiner meiner Testsituationen einen direkten Nachweis irgendwelcher Framevorgaben auf einen LOD Level von Objektcode usw. nachweisen.

Auch konnte ich z.B bei Bewölkung oder anderen Objektcode keine Nachteile feststellen.

Denn irgendwo sollte der der FS auf einmal seine Performance hinsichtlich scharfer Bodentexturen herholen.

Die Frage ist nur wo?

Sind es ev. doch unsichtbare Sachen die im Speicher vorgeladen werden.

Noch kurioser ist ja der Sachverhalt, dass wenn ich hohe Frames zulasse, ich irgendwo Performance für die Texturen her bekomme.

Eigentlich müsste es umgekehrt sein. Ich begrenze die Frames nach unten das System muss weniger Bilder pro Sekunde berechenen, der FS hat jetzt mehr Rechenpower für andere Sachen zur Verfügung hat. Eben z.B für scharfe Bodentexturen.

Die Microsofthilfe sagt genau dieses aus. Also passt auch die Hilfe selbst nicht zu diesem Phänomen.

Um auf den Tipp zurückzukommen. Die Frames müssen also nicht unbedingt auf unendlich stehen, weiterhin muss man auch nicht bei dem LOD_TARGET_FPS in der FS9.CFG herumspielen.

Für die Bodentexturen scheint es aber in der Tat sinnvoll zu sein diese Framevorgabe hoch einzustellen.

Speziell bei Fotoscenerien. Hier ganz besonders in der Kombination mit deaktivierten Extended Terrain Textures.

Nicht jeder wird allerdings Auswirkungen bemerken.

Siehe meine vorigen Tests. Der Notebook zu schwach, der 3,4GHz unter normalen Landclasscenerien zu stark.

Was da allerdings genau im Hintergrund vor sich geht... keine Ahnung. Muss man mal sehen.



Momentan werde ich aber aus privaten Gründen vorerst keine Zeit mehr für den FS haben.