|
FS9.CFG hier UPPER_FRAMERATE_LIMIT & LOD_TARGET_FPS
Wie verhält es sich bei euch eigentlich mit diesen Parametern UPPER_FRAMERATE_LIMIT & LOD_TARGET_FPS im FS2004.
Ich hatte da auch eine Interpretation dieser Parameter in meiner Doku (denn die LOD_TARGET_FPS ist ja eigentlich undokumentiert), nur ich glaube ich lasse die lieber weg, denn ich kann da zwar interpretieren aber nichts logisches entdecken. Es gab ja seit FS2002 Zeiten immer den Tipp nicht direkt im FS Menü die Zielframerate einzustellen, sondern direkt in der FS2002.CFG bzw. FS9.CFG folgende Einstellung vorzunehmen: Die Empfehlung lautete die UPPER_FRAMERATE_LIMIT auf unendlich also =0 zu setzen. Die LOD_TARGET_FPS der 70% Wert der UPPER_FRAMERATE_LIMIT soll man z.B auf einen gewünschten niedrigen Minimalwert z.B 10 stellen. Microsoft schreibt in der Hilfe zur Ziel-Bildwiederholrate die übrigends nicht die LOD_TARGET_FPS sondern die UPPER_FRAMERATE_LIMIT ist folgendes: ""Im Kino durchlaufen Filme im Allgemeinen mit einer Geschwindigkeit von 24 Bildern pro Sekunden den Projektor. Bei dieser Geschwindigkeit erkennt das menschliche Auge nicht, dass der Film in Wirklichkeit eine schnelle Abfolge von Bildern ist. Wie bei einem Film wird bei animierten Graphiken auf Computerbildschirmen jedes Bild einzeln erstellt. Dies geschieht mit einer hohen Bildwiederholrate, so dass es sich um ein einziges Bild in Bewegung zu handeln scheint. Bei manchen Computern empfiehlt es sich gegebenenfalls, die Ziel-Bildwiederholrate zu begrenzen. Wenn Sie die maximale Bildwiederholrate begrenzen, werden die Ressourcen des Computers nur soweit in Anspruch genommen, wie dies zum Erreichen der gewählten Bildwiederholrate erforderlich ist. Ressourcen, die nicht zum Erzielen einer höheren Bildwiederholrate benötigt werden, stehen so für andere Aufgaben zur Verfügung, beispielsweise die Darstellung von Wolken oder entfernten Szeneriedetails. Welche Bildwiederholrate Ihnen am ehesten zusagt, sollten Sie einfach ausprobieren."" Irgendwie habe ich gerade bei meinem P4 mit 3,4GHz keinerlei positiven Erfahrungen mit beiden Parametern. Bei mir kann ich folgenden Sachverhalt nachweisbar feststellen. Nehmen wir mal an ich habe alle Sceneryregler rechts, die höchste Performancebelastung für den FS. Zusätzlich noch Wolken, mäßige Dichte. Weiterhin habe ich die Ziel-Bildwiederholrate auf unendlich. Der FS erreicht sagen wir mal ca. 50 Frames. Jetzt begrenze ich auf 30 Frames. Was ich feststellen kann, ist das die Frames jetzt definitiv auf 30 begrenzt sind. Genau wie es Microsoft beschreibt. Entsprechend der MS Beschreibung hätte mein PC jetzt Performance für irgendetwas frei, er könnte z.B gemäß Hilfe mehr Wolken oder eine höhere Wolkendichte darstellen. Jetzt erhöhe ich mal die Wolkendichte oder die Wolkenreichweite extrem, so das ich nur noch auf ca. 18 Frames komme. Der FS hat nun laut Hilfe keine zusätzliche Performance mehr frei. Ich würde erwarten das er jetzt die Wolkenreichweite oder Dichte bzw. andere Scenery minimiert, da er ja die 30 Frames nicht mehr schafft. Er würde auch den 70% Wert also die LOD_TARGET_FPS nicht mehr schaffen. Es müssten also irgendwelche Details abgeschaltet werden. Es passiert aber überhaupt nichts, alles bleibt aktiv, selbst die Bodentexturen bleiben scharf. Nur die Frames sind halt schlechter als die Ziel Vorgabe von 30 sie liegen nur noch bei ca. 18. Jetzt kommt es. Ich regele die Ziel-Bildwiederholrate auf 16 also tiefer als die erreichten 18. Die Frames bleiben schön bei 16 stehen. Demnach müsste jetzt ja wieder mehr Performance für andere Sachen frei sein. Es verändert sich aber an der Scenery und den Wolken bzw. der Dichte usw. nichts. Da kommt nichts dazu. Es hat nie eine Veränderung stattgefunden. Zmindest kann ich nichts erkennen. Ergo ich kann das was in der Hilfe steht überhaupt nicht bestätigen. Auch der Tipp von damals wie man es in der FS9.CFG einstellen soll bewirkt bei mir nichts positives. Das einzigste was ich nachweisbar bestätigen kann, ist das die Frames auf den Wert der Ziel-Bildwiederholrate abgeregelt werden wenn der FS theoretisch höhere erreichen würde. Auch läuft der FS bei mir (bei Unendlich Einstellung der Ziel-Bildwiederholrate )minimal ruckeliger wenn er z.B ständig zwischen 25 und 90 Frames schwankt. Begrenze ich ihn dann auf 25 läuft er optisch flüssiger. Aber irgendein Frame abhängiges schalten von Sceneryelementen bzw. Wolken kann ich nicht erkennen. Wie sind da eure Erfahrungen mit beiden Paramtern? Getestet wurde mit gepatchten FS2004 also Stand FS9.1 |
Hi JOBIA!
Ich glaube, die Bedingungen für den Test sind schlecht gewählt. Ich kann jetzt nicht wirklich testen, bin aber der Meinung, dass für einen Effekt der Frameratebegrenzung die Regler nicht alle rechts stehen dürfen. Stehen alle Regler rechts, wird der FS gezwungen, an die Grenzen zu gehen. D. h. er wird die eingestellte max. Framrate schwerer erreichen. Die Priorität liegt bei den Reglereinstellungen höher, so dass die Frames bei rechts liegenden Reglern eben in den Keller gehen. Stelle ich nun Mipmaps oder Wolkendichte oder sonstwas herunter und der FS erreicht locker die eingestellte max. Framerate, schaltet er intern auf höhere Details als in den Reglereinstellungen eingestellt ist, solange er die Framerate einhalten kann. Welche Regler davon betroffen sind (Schatten und Lichtreflexe etc. sicher nicht), kann ich nicht sagen, aber nur so macht die Framerategrenze für mich überhaupt Sinn. |
Ehrlich gesagt ich habe mich im Zuge meiner Doku mit sehr vielen Parametern des FS beschäftigt. Auch mit dem dazugehörigen Texten der Hilfe. Die Texte passen sehr oft nicht zu dem Sachverhalt der wirklich passiert. Zumindest ist es nicht eindeutig interpretierbar.
Bei den beiden zuvor erwähnten beiden Parametern würde ich die Funktion ganz anders beschreiben, ich denke hier hat das Team welches die Hilfe erstellt hat, ev. das Programmierteam falsch verstanden. Wie ich es interpretieren würde oder wie es aus meiner Sicht sinnvoll erscheinen würde schreibe ich ev. morgen. Ich muss allerdings gestehen das auch wenn ich die Paramter nicht alle rechts stehen habe, ich keine erwähnten Regelprozesse bei mir erkennen kann. Bezüglich Deiner Aussage. Warum sollte der FS wenn alle Regler rechts stehen nicht irgendwelche Regelprozesse nutzen. Denn speziell wenn er and die Grenzen gehen muss, wäre es doch gerade sinnvoll wenn er Möglichkeiten hat bestimmte Elemente abzuschalten bzw. in minderwertige Qualitäten runterzufahren. Z.B minderwertige MIP Level oder anstatt 3D Wolken in Entfernung nur die alten 2D zu nutzen. Du kannst natürlich recht haben. Nur bei mir scheint es nicht richtig zu funzen. |
Hi!
Zitat:
Zu FS 2000 Zeiten wurden ja selbst bei der Pilotenprüfung li/re verwechselt. Das Problem ist,daß die Jungs aus Redmond nicht die Übersetzung zurücklesen;) |
Hi Jobia, afaik, empfehlen gewisse Photoscene Publishers die Framerate auf unbegrenzt zu setzen. Ansonsten erkenne ich hier nur eine Gleichung: Framelock XX führt zu 2/3 davon in LOD. Also 27 gelocked ergeben 18 LOD. Stellt man z.B. 28 ein, rundet sich die LOD automatisch auf die nächst höhere Instanz auf, in diesem Fall 19. Wo man die LOD einstellen soll, wenn die Framerate unbegrenzt ist, no idea..? Schätzungsweise und vielleicht nicht höher als 14-18? Eventuell gar noch tiefer? Wie du sicherlich bemerkst hast, ist 10 das Minimum. Andere haben hier eventuell mehr Erfahrung und Wissen?
Eine Konsequenz ist deshalb unter Umständen -wenn schon- den Lock mit Multiplikatoren von 3 zu definieren. Also bsw. 24, 27 oder 30. Upps, bevor ich's vergesse, falls man V-Sync aktiviert hat, erkennt man oft Teiler der Bildwiederholfrequenz (BWF) als Framerate. D.h. bei z.B. 85Hz BWF, sieht man häufig 42.x --> 28.x --> 21.x fps usw. Es könnte also nützlich sein, bei aktivem V-Sync, den Lock auf 1-3 FPS unter einem 'natürlichen' Teiler zu setzen? Eventuell funktioniert dies besser bei Displays, welche höhere BWFen anbieten? D.h. es ergeben sich vielleicht idealere resp. höhere Teiler? Im Bewusstsein bei aktivem V-Sync Frames zu 'verschenken', gefällt mir persönlich die Simulation viel besser und wirkt sie viel lebendiger so. Hope this adds to thoughts. Ich bin gespannt und freue mich sehr auf deine Doku! Im voraus Dank für deine Bemühungen. Liebe Grüsse Jaap |
Hallo nochmal!
Ich hatte nun mal ausgiebig Zeit, mit den Reglern zu spielen. Und ich gebe Dir Recht, JOBIA. Es lässt sich nicht wirklich etwas erreichen mit diesem Framerateregler (außer natürlich die Begrenzung der Frames). Schon seltsam, denn M$ wird sich doch was dabei gedacht haben. |
Zu
"Hi Jobia, afaik, empfehlen gewisse Photoscene Publishers die Framerate auf unbegrenzt zu setzen". Ja das ist bekannt. Wie gesagt das entspricht ja auch dem was man immer zu FS2002 Zeiten gelesen hat, bzw. was man auch heute noch immer liest. Direkt in der FS2004.CFG den UPPER_FRAMERATE_LIMIT auf unbegrenzt und den LOD_Target_Frames auf einen niedrigen Wert einstellen. "Ansonsten erkenne ich hier nur eine Gleichung: Framelock XX führt zu 2/3 davon in LOD" Das ist eigentlich auch bekannt, der genaue Sachverhalt sieht etwas anders aus: Der LOD_Target_Frames ist der 70% Wert von UPPER_FRAMERATE_LIMIT. Einstellen können wir im FS Display Menü nur den UPPER_FRAMERATE_LIMIT. Das ist eine der Kuriositäten. In der deutschen Version steht im Display Menü eindeutig Ziel-Bildwiederholrate. Stellen wir die auf 20Frames ein dann wird der UPPER_FRAMERATE_LIMIT auf 20 eingestellt. Von der Übersetzung würde Ziel-Bildwiederholrate eigentlich eher zu LOD_Target_Frames passen. Übrigends in der englischen Version nennt sich im Display Menü Ziel-Bildwiederholrate Target frame rate. Also im Prinzip eine eindeutige Übersetzung. Nur auch hier gilt der Sachverhalt das sich hinter Target frame rate nicht der LOD_Target_Frames sondern UPPER_FRAMERATE_LIMIT verbirgt. Kurz zu Schubi Die Hilfe in der englischen Version sagt exakt das selbe aus wie die deutsche Version. Von daher bin ich der Meinung hier ist was faul. Es wurde von dem Team welches die Hilfe erstellt eine Information des Entwicklungsteames falsch interpretiert. Vermute ich zumindest. Ich kann auch falsch liegen. Wie gesagt für mich ist im wesentlichen interessant was andere Anwender anhand verschiedener Einstellungen definitiv bei sich im FS nachweisen können. Erkennen sie Regelprozesse, wenn mit diesen Parametern gearbeitet wird. Also das der FS z.B gezielt Wolken deaktiviert wenn irgendwelche Frames nicht erreicht werden. Ich kann bei meinem neuen P4 3,4GHz HT keine Regelprozesse erkennen. Ich muss das mal genau prüfen ich meine bei meinem langsameren Notebook P4 2,53 GHz ist was erkennbar. Lasse ich mal meine Problematik bei mir und die MS Hilfe außen vor, wie würde ich mir die wahre Funktion vorstellen oder wie würde ich sie programmieren. Dieser Sachverhalt steht im Prinzip auch in meiner Doku. Nur wie gesagt mittlerweile zweifele ich daran. Was ist eindeutig beweisbar. Stelle ich die Ziel-Bildwiederholrate auf 30, dann ist in der FS9.CFG die UPPER_FRAMERATE_LIMIT auf 30 eingestellt. Die LOD_Target_Frames steht dann auf 21. Könnt Ihr nachrechen sind genau 70%. Stelle ich die Ziel-Bildwiederholrate auf 20, dann ist in der FS9.CFG die UPPER_FRAMERATE_LIMIT auf 20 eingestellt. Die LOD_Target_Frames steht dann auf 14. Könnt Ihr nachrechen sind auch genau 70%. Stelle ich die Ziel-Bildwiederholrate auf 25, dann ist in der FS9.CFG die UPPER_FRAMERATE_LIMIT auf 25 eingestellt. Die LOD_Target_Frames steht dann auf 17. Könnt Ihr nachrechen von 25 sind 70% 17,5 der FS rundet anscheinend ab. Stelle ich die Ziel-Bildwiederholrate auf 21, dann ist in der FS9.CFG die UPPER_FRAMERATE_LIMIT auf 21 eingestellt. Die LOD_Target_Frames steht dann auf 14. Könnt Ihr nachrechen von 21 sind 70% 14,7 der FS rundet offensichtlich immer ab. Hat man keine Nachkommastellen passt es mit den 70% immer. Hat man Nachkommastellen wurde bei mir immer abgerundet. Dieser Sachverhalt mit dem 70% Wert ist eindeutig beweisbar wenn man über das FS Displaymenü arbeitet. Was noch beweisbar ist, ist der Sachverhalt das der FS seine Frames auf den UPPER_FRAMERATE_LIMIT abregelt wenn er technisch in der Lage ist höhere Frames als die UPPER_FRAMERATE_LIMIT zu erreichen. Optisch sehe ich noch das es etwas flüssiger läuft da die Frames konstant sind und nach oben nicht so stark schwanken. Dann hört es bei meinem P4 3,4Ghz mit der Beweisbarkeit aber schon auf. Das was in der Hilfe steht kann ich was Regelprozesse betrifft, auf keinen Fall nachweisen. Aber denken wir mal weiter. Von der Theorie muss der 70% Wert LOD_Target_Frames einen Sinn haben. In meiner Doku habe ich im Prinzip folgendes stehen (ich bin bisher immer davon ausgegangen das es so funktioniert.) Also ich stelle den FS z.B auf Ziel-Bildwiederholrate 30 ein. Dann ist in der FS9.CFG die UPPER_FRAMERATE_LIMIT auf 30 eingestellt. Die LOD_Target_Frames steht dann auf 21. Startet man den FS und fliegt durch die Gegend der FS schafft nur 28 Frames dann haben wir auch nur 28 Frames. Wird er noch mehr gequält und er kommt unter dem 70% Wert 21Frames, dann schaltet er Details z.B Wolken ab. Er hat die LOD_Target_Frames erreicht. LOD heist ja Level of Detail er schaltet also Details ab. Kommt er jetzt über 21 dann schaltet er diese Details aber noch nicht wieder zu. Erst wenn er über die 30 der Ziel-Bildwiederholrate (UPPER_FRAMERATE_LIMIT) kommt schaltet er die zuvor deaktivierten Details wieder zu. Er hat jetzt nämlich Performance frei. Das wäre meine Übersetzung dieser Paramter. Wie man sieht ist meine Übersetzung anders als die von Microsoft. |
Warum glaube ich das es so sein sollte oder müsste.
Nehmen wir mal an der FS würde unter 21 Frames Details abschalten. Sobald er über 21 kommt würde er sofort wieder Details zuschalten. Das hätte zur Folge das der FS durch die hinzukommenden Details sofort wieder in den Frames einbrechen würde. Er käme sofort wieder unter 21. Wir hätten also einen Zustand in dem ständig Details an und abgeschaltet werden. Wolken würden z.B immer nur für Sekundenbruchteile auftauchen. Schlimmer noch der FS würde durch den ständigen Regelprozess zusätzliche Arbeit verrichten müssen. Deshalb denke ich müsste meine Auslegung der Parameter die richtige sein. Dann ergibt diese Geschichte mit dem gekoppelten 70% Wert auch einen logischen Sinn. Es ist eine Hysteresefunktion. Es gibt hier im Prinzip einen Totbereich. Der FS schaltet erst Details ab wenn er unter LOD_Target_Frames kommt. Darüber gibt es einen 30% Totbereich wo hinsichtlich Details nicht gearbeitet wird. (Ein ständiger belastender Regelprozess findet nicht statt da er auch keinen Sinn ergeben würde). Erst wenn wir den 100% Wert überschreiten werden die Details zugeschaltet. Ich meine diesen Regelprozess auch früher im FS2002 so gehabt zu haben. Nur wie gesagt im FS2004 im P4 3,4GHz HT kann ich es nicht erkennen. Wie gesagt aus diesem Grund interessiert es mich ob bei euch so ein logischer Vorgang wie ich ihn beschrieben habe erkennbar ist. Ev. funktioniert diese Logik beim FS2004 (ev. FS9.0 zu FS9.1 Version) nicht mehr. |
Übrigends was oben bisher nicht rüberkam.
Der eigentliche Grund warum ich diese Thematik mit in meine Doku genommen habe war der, dass ich diesen Tipps die im Internet gehandelt werden, bei meinem P4 3,4GHz nichts erkennbares positives abgewinnen kann. Aus diesem Grunde habe ich nachgeforscht und festgestellt das der ganze Sinn dieser Parameter auch im Defaultbetrieb irgendwie nicht sinnvoll umgesetzt wird. Ob es nur mit schnellen P4 HT Prozessoren oder mit der gepatchten FS2004 Version Probleme gibt, habe ich noch nicht getestet. Funktionert es ev. generell beim FS2004 nicht? Hat es nur beim FS2002 funktioniert? Letztere beiden Sachen werde ich prüfen, die Möglichkeiten habe ich noch. Wie gesagt von daher interessiert es mich ob Ihr was nachweisen könnt. Ev. gibt es Möglichkeiten hier zu handeln. Aber thb bestätigt ja das Verhalten, irgendetwas ist da faul. Von daher scheint der gehandelte Tipp allerdings auch nicht sinnvoll zu sein. |
Komisch bisher noch keinerlei Meldungen zu der Thematik?
Ist sich keiner mehr sicher, ob die Tips wirklich etwas auslösen bzw. ob die Parameter im Defaultbetrieb also ohne Tipps irgendetwas hinsichtlich Regelprozessen in der Scenery auslösen? Zum Sachverhalt möchte ich noch etwas anmerken, damit man weis worum es mir geht. Setzt man einen neuen Flug auf, bzw. lädt eine Flugsituation, dann hat der FS zunächst alle Zeit der Welt um Sceneryinformationen im Umfeld der Sichtposition des Anwenders zu laden. Sind alle Sceneryregler nahezu rechts dann lädt er höchstmögliche Details im Umfeld. Die Logik des FS ist so programmiert, dass in weiterer Entfernung minderwertige Texturen (MIP Level) und niedere Detailstufen bei Objekten (LOD Level) insofern vorhanden geladen werden. Ähnlich verhält es sich beim Mesh. Sind Objekte oder Details zu weit entfernt, werden sie überhaupt nicht verarbeitet. Diese Vorgehensweise bzw. Programmierung findet man im Prinzip bei jedem 3D Game. Noch fliegen bzw. bewegen wir uns nicht. Bewegen wir uns jetzt durch den Raum (ev. schnell) und der FS hat Performanceprobleme dann treffen wir irgendwann z.B auf diese minderwertigen Details der Scenery das können niederwertige MIP Level von Texturen sein. Diese wirken optisch sehr unscharf. Diesen Effekt kennen mit Sicherheit alle. Es kann aber auch sein, dass ein Mesh z.B sehr grob, also nicht detailiert wirkt. Pausieren wir den Flug erholt sich die Scenery. Nur das bezeichne ich zunächst noch nicht als Framerateabhängigen Regelprozess sondern es ist bei schnellen Flug ein grundsätzliches Performanceproblem des FS. (je nach dem wie stark der PC des Anwenders ist) Wenn das was Microsoft bezüglich Framevorgabe schreibt halbwegs eine Funktion hat dann müsste das wie folgt sein. Nehmen wir an wir haben die Upperframerate auf 30 eingestellt, dann wird die LOD Target intern vom FS auf 21 eingestellt. Wir stellen bei unserer gespeicherten Flugsituation (die unter Autopilot abläuft damit vergleichbare Bedingungen herschen) fest der FS kommt mit den Texturen oder anderen Details nicht mehr nach. Die Frames sacken auf unter 21 ab, bleiben aber über 17. Dann ist das bis hierhin noch logisch das Scenerydetails verschwinden denn der FS schafft noch nicht mal die untere Vorgabe 21. Jetzt stelle ich bei der selben Flugsituation (alles unter Autopilot) die Upperframerate auf 15 ein. Ich stelle fest der FS schafft immer über 15 Frames trotzdem werden die Texturen mit der Zeit unscharf auch hier verschwinden Details. Das dürfte nicht sein wenn diese Frameratevorgabe einen logischen Sinn ergeben sollte. Sein kann das schon das alles unscharf wird, nur es steht in keinem Zusammenhang mit einem Regelprozess der in einen Bezug zur Frameratevorgabe gebracht werden kann. So ähnlich verhält es sich bei meinem schwächeren Notebook. Man kann beim Notebook Performanceeinbrüche und niedere Frames erkennen, nur ein verknüpfter Regelprozess bei Wolken, Scenery usw. aufgrund der Framevorgaben ist nicht erkennbar. Wenn es so wäre, dann müsste der FS wesentlich mehr Details bei gleicher Situation schaffen, wenn die Framevorgabe grundsätzlich sehr niedrig angesetzt wird. Oder aber umgekehrt auf meinen schnellen P4 3,4GHz müsste ein Detailverlust auftauchen, wenn ich die Framevorgabe übertrieben hoch ansetze. Nur dann wäre ein logischer Zusammenhang nachweisbar. Aber nichts dergleichen passiert. Egal wie ich beim 3,4GHz die Framevorgabe einstelle an der Scenery ändert sich nichts. Der 3,4GHz schafft immer alle Details nur das er ev. die Framevorgabe nicht schafft. Mit einer regulären Scenery kann man natürlich nicht unbedingt erkennen ob Details in der Ferne abgeschaltet werden. Ich habe deshalb Testscenerien erstellt mit denen man das testen kann. Aber auch hier tut sich nichts. Das einzigste was ich erkennen kann, habe ich in den anderen Beiträgen schon beschrieben. Das war nur das er bei oberer Framevorgabe diese nicht überschreitet wenn er technisch dazu in der Lage wäre. Weiterhin das er bei konstanten Frames z.B abgeregelt auf 30 optisch flüssiger läuft, als wenn er zwischen 40 und z.B 100 (und höher) ständig schwankt. |
Zitat:
Vielleicht hat M$ ja den Frameratebegrenzer dazu gedacht, dass der User sich diesen Regler so einstellt, dass der Ablauf flüssiger ist, weil der FS aufgrund der begrenzten Frames nebenbei die Berechnungen o. ä. ausführen kann, wofür er sonst einige Frames gelegentlich auslassen muss, was eben diese Schwankungen und gelegentliches Ruckeln verursacht. Zuzutrauen wäre es M$, dass sie das in ihrer "Doku" dazu eben etwas schöner verpacken. |
Könnte man ev. noch so sehen. Sehr viele der Hilfetexte sind nicht immer eindeutig.
Nur der Satz unten aus der Hilfe ist eigentlich eindeutig: "Ressourcen, die nicht zum Erzielen einer höheren Bildwiederholrate benötigt werden, stehen so für andere Aufgaben zur Verfügung, beispielsweise die Darstellung von Wolken oder entfernten Szeneriedetails." Es muß sich demnach doch irgendetwas in der Scenery oder am Himmel tun. Weiterhin. Wozu dann diese definitiv nachweisbare 70% Kopplung UPPER_FRAMERATE_LIMIT und LOD_Target_Frames. Was ist mit dem häufig gehandelten Tipp die 70% Kopplung zu umgehen in dem man UPPER_FRAMERATE_LIMIT direkt in der FS9.CFG auf unendlich setzt die LOD Target auf einen niederigen Wert z.B 15 oder sogar 10. Bewirkt bei meinen Notebook nur das dieser wenn er mal genug Performance hat, weil man nur blauen Himmel im Steigflug sieht auch mal recht hoch in den Frames geht. Ich kann aber wiederrum nicht erkennen das die Scenery durch den niedrigen LOD Target 10 länger scharf bleibt bzw. mehr Wolken zu sehen sind. Wie gesagt ev. hat ja noch jemand anders eine eindeutige Beobachtung das bei ihm definitiv etwas hinsichtlich Detailregelung bei Framevorgaben erkennbar ist. Wenn nicht gehe ich davon aus das bei mir nichts faul ist, sondern das bei niemanden so eine in der Hilfe erwähnte Funktion nachweisbar ist. Ev. passte dieser Tipp der in Foren immer wieder erwähnt wird nur für den FS2002. Wie es in Foren so üblich ist wird dann automatisch davon ausgegangen das er auch im FS2004 etwas auslöst. So taucht er immer wieder auf, löst aber eigentlich nichts aus. Dadurch das der FS durch die Vielseitigkeit der Scenerien sehr unterschiedlich stark belastet wird, glaubt der Anwender er kann eine Auswirkung erkennen. Dem ist aber ev. überhaupt nicht so. Andere Uhrzeit andere AI Traffic Belastung oder andere Gegend bedeutet andere Landclassverteilung bzw. anderes Mesh, bedeutet wiederrum andere FS Belastung hinsichtlich Details. Bestes Beispiel das wir öfters etwas glauben zu sehen was nicht funktioniert ist doch z.B das Thema Mesh. Vor dem FS2004 Patch konnte der FS2004 definitiv keine LOD11 Meshfiles als solche darstellen. Hat es jemand gemerkt? Nein, ich übrigends auch nicht. Ich hatte nur festgestellt das irgendetwas beim FS2004 beim Mesh anders ist. Aber das er LOD11 nicht kann, habe ich auch nicht gemerkt. Nach dem FS9.1 Patch kann er jeden Höhenpunkt eines LOD11 Mesh optisch darstellen. LOD11 ist aber die Obergrenze. LOD12 oder gar LOD13 Meshfiles kann er auch nach dem FS9.1 Patch nicht als solche darstellen. Trotzdem werben immer noch einige Anbieter mit Ihren Supermeshfiles die eine Auflösung 9 Meter oder besser haben. Da wird der Anwender (ev. auch aus Unwissenheit der Produzenten) veräppelt. Sehr schön auch immer das Flimmerproblem von Texturen. Habe bei meinen ATI Radeon Treiber folgenden Sachverhalt bewiesbar festgestellt. Je nach Einstellung des Mipmap Detailebene Reglers im Treiber wird ungefragt trilineares Filtern zusätzlich aktiviert. Das ganze schwankt nach Einstellung der Qualitätsstufen und Einstellung der Grafikkartenauflösung. Es ist in 3D Foren bekannt das bei Treibern nicht nur sehr viel verbessert, sondern auch im Hintergrund auf Kosten der Qualität gemauschelt wird. Von daher wundert mich diese ganze Diskussion bezüglich Texturflimmern eigentlich auch nicht. Anwender mit identischen Treibern hätten für mein Beispiel mit dem trilinearen Filtern oben unterschiedliche Flimmerprobleme bei Texturen nur weil Anwender A mit 1024 x 768 Pixeln Anwender B mit 1280 x 1024 Pixeln fliegt. Das ganze dadurch das bei dem einen trilinear gefiltert wird bei dem anderen nicht. Der ein oder andere stellt jetzt bei einem neuen Treiber fest das auf einmal das Flimmern stärker oder schwächer als beim Vorgängertreiber ist. Die Wahrheit könnte aber auch sein das ev. nur eine vorher nicht beachtete Einstellung des Treibers nach dem aufspielen anders ist. Ev. auch eine undokumentierte Eigenschaft(Fehler?) wie z.B dieses ungefragte trilineare Filtern. Das ist nur ein Beispiel was alles mit reinspielen kann, denn auch die Performance fällt durch so etwas ev. verschieden aus. |
Jobia,
da spielt auch noch etwas anderes in den Parameter hinein. Wo eine Begrenzung sich eindeutig und nachweisbar auswirkt ist beim online-Fliegen. (Jetzt von mir nur an den Auswirkungen überprüft, andere sollen dies anhand des Datentraffics überprüft haben.) Bei unlimitierten FPS führt dies zu einem ständigen Senden von Datenpacketen. Diese können von den anderen Clients nicht mehr schnell genug verarbeitet werden, mit der Auswirkung, dass die Mitspieler anfangen zu springen. Sobald wir eine Target-Frame von irgendwas bei 20-30 haben, fliegen die Flugzeuge der Mitspieler wieder flüssig. Wobei es reicht, wenn nur ein Spieler den Regler auf unlimitiert stehen hat. Ansonsten habe ich bewußt auch noch keinen wirklichen Einfluss fest gestellt. |
Zu online Fliegen kann ich überhaupt nichts sagen.
Aber dieser Effekt mit dem etwas flüssigeren beim online Flug bei den anderen Mitspielern bei einer Begrenzung der Frames zeigt einen ähnlichen Sachverhalt wie ich ihn bei meinem 3,4GHz habe. Direkt vergleichen kann man es allerdings nicht. Aber auf jeden Fall eine Einstellung die auch gegen die üblichen Tipps der unendlichen Frameeinstellung beim FS2004 spricht. Mich wundert ehrlich das niemand diesen Original Microsoft Hilfe Text in irgendeiner Form direkt bestätigen kann. Zum einen weil es offensichtlich bestätigt das keiner solche Auswirkungen nachweisen kann, was bedeutet das irgendetwas am FS faul ist. Zum anderen weil viele mit irgendwelchen auf Tipps basierenden Einstellungen durch die Gegend fliegen wo sich keiner sicher ist das wirklich etwas positives passiert. Aber Ok das kennen wir ja auch von den Tipps zu den Terrain_Default_Radius und Terrain_Extended_Radius hier arbeitet man ja auch mit Werten über 4 die beim FS2004 definitiv nichts mehr auslösen. Habe ich mittlerweile anhand Testdateien bei ein paar Leuten vor Ort beweisbar kontrolliert. Werde jetzt mal testen wie es sich bezüglich der Framevorgaben beim ungepatchten FS2004 bzw. beim FS2002 verhält ev. ist dort ja etwas erkennbar. |
Übrigends was diesen Thread betrifft.
Wie lange wird es das Forum noch geben Es war eben 4 Uhr 40. Ich weis nicht wo der Server für das Forum steht. In Deutschland sollte aber nicht viel Traffic los sein. Es hat eben auch mal wieder sehr lange gedauert bis mein Text im Forum erschien. |
Hallo !
So intensiv hab ich mich mit dem ganzen noch nicht auseinandergesetzt, aber mir is eins aufgefallen. Hier ist immer von einem Framerateregler die Rede. Ich sehe dieses Ding einfach als Begrenzer, und wenn man's als Regler bezeichnet, hat man vielleicht einfach höhere Erwartungen. Meiner Ansicht nach steckt da überhaupt nix anderes dahinter, als große Framesprünge zu vermeiden. Wer schon einmal aus dem Cruise bei 40 fps auf einem Addon Airport gelandet is, wo man vielleicht noch 15 fps kriegt, der weiß, dass es viel besser is, nur 20 bis 25 die ganze Zeit zu haben, weil einem der Einbruch dann einfach nicht so vorkommt. Also ich würde diese Einstellung nicht überbewerten, schon gar nicht so, dass gar irgendwas abgeschaltet würde, nur um mehr fps zu erreichen. Auch die ganzen Erklärungen mit "mehr Rechenzeit für andere Dinge" find ich ziemlich suspekt. Wenn ich mir die CPU Auslastung bei meinem Rechner während des FS anschaue, kann ich über "freie Ressourcen" nur Lachen. Und ich denke mal, mit all den Addons die teilweise laufen, wird es dem überwiegenden Teil von Usern auch nicht anders gehen. Alles in Allem finde ich die Begrenzung nicht schlecht, solange man keine Wunderdinge erwartet, die sie ja auch gar nicht liefern kann. Wie gesagt, das is meine Meinung als reiner Anwender. Wenn man so will, sehe ich den FS also ziemlich oberflächlich, im Gegensatz zu Jobia und einigen anderen hier. vg martin |
Zitat:
Nichts von dem was Microsoft erwähnt passiert bei mir. Ich hatte die Frage auch nur ins Forum gestellt weil A) Microsoft in der Hilfe was anderes schreibt. B) weil das was ich festgestellt habe sich mit Deinem deckt (nicht mehr und nicht weniger) und irgendwie die Tipps die gehandelt werden in Frage stellt. Aber lassen wir das, es kommt glaube ich eh nichts bei rum außer das die Funktion so wie beschrieben nicht funktioniert. Na ja und die meisten Tipps....... sehe ich ja immer wieder, werden eh nicht hinterfragt oder getestet. |
Zitat:
Ehrlich gesagt warte ich schon sehnsüchtig auf deine Ergebnisse, so weitgehen wie du diese Regler testest macht es wohl kein anderer. Darum ist deine Arbeit auch so wichtig. Also drann denken wenn die Lust mal wieder fehlt: Es gibt zumindest eine Person, die sehr gerne deine Doku sehen will und auch die Arbeit sieht, die dahinter steckt. :) |
Zitat:
|
Wir haben ja auch noch einen anderen aktuellen Thread wo diese Parameter erwähnt werden.
Da ich für Gassa sein Problem eh eine den FS extrem belastende Landclasscenery erstellen musste habe ich diese gleich mal zum testen genutzt. Ich habe sowohl im FS2002 als auch im FS2004 getestet. Dabei ist mir aufgefallen das bei beiden FS Versionen die 70% Regel gilt, das war eigentlich auch klar. Stelle ich UPPER_FRAMERATE_LIMIT=20 ein erhalte ich bei beiden Versionen LOD_Target_Frames=14, stelle ich UPPER_FRAMERATE_LIMIT=30 ein erhalte ich bei beiden FS Versionen LOD_Target_Frames=21 So weit so gut. Mache ich aber bei beiden FS Versionen einen sofortigen Wechsel im Displaymenü auf unendlich, dann wird UPPER_FRAMERATE_LIMIT=0 gesetzt. So wurde die Stellung unendlich ja auch bei den Tipps interpretiert. Was aber schon mal überhaupt nicht witzig ist das bei beiden FS Versionen dann keinerlei Änderung bei LOD_Target_Frames= erfolgt. Dieser Wert bleibt auf dem zuletzt eingestellten Wert hängen. Von daher müsste man eigentlich überhaupt nicht in der FS2002.CFG bzw. in der FS9.CFG rumwursteln. Man kann es durch gezielte Einstellung auch direkt im Displaymenü einstellen. Aber das ist alles uninteressant und unwichtig. Wichtiger sind diese Tipps mit der dazugehörigen Interpretation. Ich gebe zu ich habe das damals auch geglaubt und meinen FS2002 mit diesen Einstellungen gefahren. Nach genauer Prüfung und Simulation im FS2002 und FS2004 kann ich aber schon mit ziemlicher Sicherheit sagen das dieses wohl eine der größten Enten sein wird der man beim FS aufgesessen ist. Kurios weil die Hilfe von Microsoft zwar nicht das aussagt was bei diesem Tipp immer hereininterpretiert wurde, aber immerhin deutet sie einen Regelprozess von Elementen anhand der Frameratevorgabe des Anwenders an. Den kann ich aber sowohl beim FS2002 und FS2004 bei keinem meiner PCs nachweisen. Das einzigste was nachweisbar ist, habe ich bereits zuvor erwähnt. Nämlich das der FS auf die Framevorgabe des Displaymenüs abriegelt insofern er technisch in der Lage ist diese zu erreichen. Auch das er flüssiger mit einer erreichbaren Framevorgabe läuft als wenn man ihn auf unendlich stellt wo es dann zu heftigen Frameschwankungen kommen kann. Mittlerweile deuten immer mehr Leute an (zum Teil auch über Mail) das sie diese normalerweise erwarteten Regelprozesse anhand der Framevorgabe nicht nachweisbar erkennen können. Von daher hat sich das für mich mit dem ominösen immer wieder auftauchenden Tipp erledigt. Es löst zumindest bei mir und auch bei anderen Leuten nichts nachweisbares aus. Zumindest hat bisher noch keiner geantwortet der sagt: "Ja ich kann eindeutig erkennen das wenn ich die LOD_Target_Frames ganz niedrig ansetze z.B 10 dann bleiben meine Bodentexturen scharf solange die Frames über 10 liegen. Stelle ich sie auf 20, dann werden die Texturen unscharf ab dem Moment wenn der FS die 20 nicht mehr erreicht." Ich denke das einzige was man erkennen kann, dass ab einer gewissen Belastung je nach Performance des PCs, Texturen unscharf werden. Mit einer Framevorgabe konnte es bisher offensichtlich niemand glaubhaft regeln. |
Hallo Leute,
also ich bin froh wenn mein FS mit meinem Athlon 2000+ mir auf nem addon-airport so um die 15 Fps bringt...mehr will ich gar nicht. Das menschliche Auge kann ja sowieso nur ca. 17- 20 Bilder / sec. erkennen....wozu dann also 40 fps? ;-) |
Es geht hier weniger um die Frames (wobei 40 Frames nicht nötig sind, aber 20 schon nicht schlecht wären. Meine Augen erkennen übrigends schon noch einen Unterschied zwischen 17 und 25 Frames)
Es geht hier im wesentlichen um einen Regelprozess bezüglich Scenery und Wolkenelementen des FS der stattfinden sollte. Das Problem an der Sache ist, dass sehr viele Leute darüber klagen das während des Fluges die Bodentexturen oft unscharf werden. Man sieht dann nur eine verwaschene Scenery. Da gibt es seit dem FS2002 einen Tipp zwei Parameter des FS in der FS2002.CFG bzw. beim FS2004 in der FS9.CFG zu verändern. Einen dieser Parameter den UPPER_FRAMERATE_LIMIT können wir auch direkt im Displaymenü einstellen. Dieser Tipp soll helfen das die Bodentexturen auch bei niedrigen Frames möglichst lange scharf bleiben. Darum geht es im wesentlichen. Leider trifft genau dieses bezüglich des Tipps nicht nachweisbar ein. |
Zitat:
15 FPS auf einem Adon-Airport sind o.k., die Bewegungen sind dynamisch langsam genug um sie nicht als störend zu empfinden. 2. Falsch, Das Auge kann beliebig viele Bilder pro Sekunde erkennen und die Sehnerven leiten diese auch viel schneller weiter, aber die für die Umsetzung zuständigen Hirnareale können diese nach gegenwärtigem Wissensstand "nur" etwa in 30ms Intervallen hintereinander verarbeiten. Das heißt: Würde z.B. ein FormelX Rennwagen mit 1.000 Km/H vor einer Reihe numerierter Mess-Skalen vorbeibrettern und das ganze mit entsprechend kurzen Belichtungszeiten gefilmt werden, siehst du ein verschmiertes Szenario, wo irgendwie was fehlt. Wäre die Belichtungszeit des Einzelbildes länger, z.B 30ms könntest du ein Stottern des Bildes feststellen und an der Skala ablesen, das immer ein paar Meter zwischendurch fehlen. 1 Sek / 30 ms ergibt ungefähr 33 FPS, die noch als ununterbrochener (unverschmierter) Film wahrgenommen werden können, das Fernsehen sendet z.B. mit 25 FPS (= Herz) |
Zitat:
Wie schnell kann diese eigentlich Bilder berechnen? Wo nimmt der Flusi seine Frameratenmessung? Doch nicht "hinter" der Grafikkarte, oder? |
Zu
"Hier würde ich eher darauf tippen, dass durch "Unendlich" die zweite Zahl irrelevant wird, da die ganze Begrenzungsroutine abgeschaltet wird." Schöner Satz, sehe ich nämlich im Prinzip mittlerweile genau so. Nur weist Du auch was dieser Satz eindeutig aussagen würde. Er sagt dann nämlich aus, dass dieser Tipp genau aus diesem Grunde nie funktioniert haben kann. Denn wenn die untere Zahl LOD_Target_Frames= bei UPPER_FRAMERATE_LIMIT= 0 (Stellung unendlich) irrelevant ist, dann braucht sie auch niemand gemäß damaligen Tipp manuell auf einen gewünschten Wert zu setzen um damit in irgendeiner Art und Weise ev. unscharfe Bodentexturen zu vermeiden. Dieses Verhalten habe ich wie gesagt jetzt ausgiebig bei beiden FS Versionen getestet. Es ist nicht nachweisbar und untermauert das LOD_Target_Frames bei UPPER_FRAMERATE_LIMIT= 0 nicht aktiv ist. Das ist das eine. Das andere ist wie gesagt, dass ich generell keine Regelung aufgrund der LOD_Target_Frames erkennen kann. Auf Bodentexturen definitiv nicht. Eigentlich sollte so ein Parameter einen Sinn ergeben. Ev. ist es etwas ganz anderes, was wir bisher immer übersehen haben. Die Frage ist nur auf was dieser Parameter Einfluss haben könnte. Für diesen Test könnte man ev. noch mal Zeit investieren. Zu "Vielleicht kommt das "Stottern" bei der Einstellung dann mehr von der Verarbeitung in der Grafikkarte - bei höchst unregelmäßigen Berechnungsdaten" Auch da stimme ich Dir zu, habe das oben auch schon mal stehen gehabt. Lässt man den FS freien Lauf kann er machen was er will. Je nach Scenery, AI- Traffic, Wolken, sagen wir doch am besten Gesamtbelastung ist die Berechnung der Daten aufwendig oder eben nicht. Das führt dazu das die Frames je nach Belastung durch die Berechnung stark schwanken. Wenn einer im Auto auf einer innerstädtischen Straße während einer Grünphase (grünen Welle) zu schnell fährt, muss er auch vor jeder roten Ampel nahezu abbremsen. Da wird auch jeder der ihn sieht sagen, dass er einen sehr ruckeligen unrythmischen Fahrstil hat. Der Fahrer der genau die Geschwindigkeitsvorgaben einhält, erwischt jede Ampel bei grün und flutscht schön harmonisch weich durch. Da wird niemand sagen das er ruckelig fährt. Ich denke genau hier ist das Problem. Bei meinem starken P4 3,4GHz kann ich es mir erlauben alle Regler rechts zu stellen, der FS schafft auch mit hoher Wolkendichte fast immer über 15 Frames. Wenn ich dem FS hinsichtlich Frames freien Lauf lasse also UPPER_FRAMERATE_LIMIT= 0 (unendlich) einstelle dann habe ich aber heftigste Frameschwankungen, da Wolken und auch Scenery bzw. AI- Traffic eine stark schwankende Last sind. Die Frames schwanken dann zwischen 15 und über 100 Frames. Das ist grob vergleichbar als wenn ich diese Stadtstraße mit dem Formel1 Fahrzeug abfahre und immer maximal rauszuholen versuche was möglich ist. Ich komme zwar ev. über zwei oder drei Ampeln weg, werde aber dann umso heftiger an der vierten Ampel abgebremst. Das Fahren wird besonders ruckelig und unharmonisch. Genau dieses Unharmonische nimmt mein Auge als ruckelig wahr. Baue ich dem Formel 1 einen Geschwindigkeitsbegrenzer ein (ich setze die Framebegrenzung im Displaymenü auf einen festen nicht zu hohen Wert) wird auch er harmonisch weich wie in der Boxengasse der Formel 1 gefordert, harmonisch die grüne Ampelphase nutzen. Ganz anders sieht das bei meinem Notebook aus. Er ist die lahme Ente die eh nicht viel mehr als 80 schafft. Mit ihm sind die Höchstgeschwindigkeiten eh nicht erreichbar. Bei Ihr habe ich gar keine Möglichkeit. Ich kann selbst bei durchgetretenem Gaspedal(Framebegrenzung im Displaymenü auf unendlich) halbwegs harmonisch die grüne Welle der Ampeln mitnehmen. Ergo wird eine Außenstehender auch sagen der fährt flüssig und sinnvoll. Was der Außenstehende ev. nicht weis, ist das meine Ente auch garnichts anderes her gibt. Genau diese vergleichbaren Effekte kann ich exakt bei meinen beiden PCs feststellen. Bei meinem Notebook muss ich nicht die Frames begrenzen hier kann ich auch auf unendlich setzen, es bleibt trotzdem halbwegs harmonisch da er eh nie solche Frameschwankungen schafft. Man muß auch die dynamische Steuerung beim Mesh und den Bodentexturen beachten. Bei einem schwachen PC sind die Frames alleine deshalb konstanter weil er des öfteren überhaupt nicht nachkommt mit der Meshberechnung. (Er fährt öfters an seinen Leistungsgrenzen) Die Frameschwankungen liegen dabei aber dichter beisammen. Dem starken PC macht das bei unendlicher Framestellung nichts aus. Er schafft das locker. Nur diese Dynamik im Mesh und andere Steuerungen der Scenery lässt die Frames stark schwanken mit der Folge die oben erwähnt wurde. Zu "Wie schnell kann diese eigentlich Bilder berechnen?" Das hängt natürlich von der Grafikkarte und dem Gesamtsystem ab. Das ist ja auch der Grund warum wir früher wohl diesen Tipp für voll genommen haben. Zu den FS2002 Zeiten hatten wir noch gar nicht so starke Systeme. |
Zu
" Wo nimmt der Flusi seine Frameratenmessung? Doch nicht "hinter" der Grafikkarte, oder?" Keine beweisbare Ahnung wo der Wert den der FS anzeigt genau herkommt. Aber alles andere als hinter der Grafikkarte wäre Schwachsinn. Ich gehe daher davon aus, dass es ein Wert ist der generell aus der Grafikkarte ausgelesen werden kann. Denn viele Benchmarks und Programme zeigen Frames an. Diese decken sich eigentlich sehr gut mit denen des FS. Da kann man wie gesagt schon aufgrund der Logik davon ausgehen das es sich um einen Wert handeln muss, der aus der Grafikkarte auslesbar ist. Wenn man bedenkt das der ganze Renderprozess, Filtertechniken usw. in der Grafikkarte abläuft, dann wäre jede interne Vorberechnung der Frames innerhalb des FS in keinster Weise aussagekräftig. Man sieht ja auch wie stark ein Game in die Grafikkartensteuerung über den Treiber eingreift. Es werden Steuerparameter wie Filtertechniken an die Grafikkarte gesendet. Mal werden fertige Texturen inkl. MIP Level geliefert, dann mal wieder nicht. Nun muss die Grafikkarte ev. MIP Level generieren. Man schaue in die Display.CFG hier sieht man oft genau die passenden Treibernamen zu der Grafikkarte. Auch das hier direkt auf den Treiber eingewirkt wird. |
Hm... hätte ich nicht gedacht, dass der Wert direkt von der Grafikkarte kommt. Sinn machen tut's auf jeden Fall.
Zu den LOD_Target_Frames beim nicht-unendlich: Vielleicht zielt dieser Parameter auf genau das, was er beinhaltet. LOD. Level of detail wird aber laut MS immer auf das Gittermodel bezogen. Sowohl bei Flugzeugen (hier sicher nicht relevant) als auch bei Objekten und Mesh. Das würde aber bedeuten, dass hier nicht irgendein Texturemechanismus dahinter steckt. Ich würde (ohne es getestet zu haben) eher - wenn dahinter überhaupt etwas steckt - auf eine Umschaltschwelle zu höher/niederwertigen LODs bei Mesh und/oder Objekten tippen. |
Ist mir heute auch schon den ganzen Tag durch den Kopf gegangen. Ev. ist es Regler der sich nur auf die LOD Modelle bezieht. Das ganze frameabhängig.
Sozusagen eine Art reiner Performanceschoneffekt. Ich habe mich in den letzten Tagen/Wochen noch mal sehr intensiv mit Mesh beschäftigt. Zunächst würde ich aber mal sagen mit Mesh wird es wenig zu tun haben. Ist aber noch keine gesicherte Aussage. Nur wenn ich mir mal anschaue wie kompliziert die ganzen entfernungsabhängigen Regelprozesse bei Mesh eh schon sind, dann kann ich mir nicht vorstellen das Microsoft dem noch eine zusätzliche Krone aufsetzt. |
Hm... dann bliebe nur noch die Idee mit den Objekten selbst. Man müsste also nachforschen, ob die MS Standard-Objekte verschiedene LOD-Level haben. Ich denke mal eher nicht.
|
Meine Tests bezüglich LOD_TARGET_FPS haben bisher hinsichtlich LOD Leveln von Objekten nichts ergeben.
Ok ich denke was soll man an normalen Gebäuden schon an LOD Leveln nutzen. Ergibt keinen Sinn. Deshalb habe ich mal Flugzeuge beobachtet. Da sähe das anders aus. Daher eine Frage an die Leute z.B Sergio die sich mit den Multi-Resolution Modellen von G-MAX beschäftigt haben. Sergio schreibt in der FXP 8 Juli/August 2004 das man bei Addons selten solche Modelle findet. Maximal 3 LOD Level wenn es gut geht. Er schreibt aber auch das Microsoft 6 LOD Level empfiehlt und das bei einigen der Default Flieger auch 5 bis 6 Modelle nachweisbar sind. Bei einigen AI Fliegern gar 15 bis 19 LOD Modelle. Sergio beschreibt auch das sich Microsoft nicht äußert in welchem Abstand bzw. wie überhaupt geregelt ist ab wann die LOD Modelle zum Einsatz kommen. Sergio erwähnt die Aussage von Louis Sinclair (FS Designstudio). Demnach wäre das LOD_100 Modell horizontal Bildschirm füllend, LOD_50 50% füllend. Ich habe ernsthafte Probleme die Verwendung von LOD Modellen im FS Betrieb nachzuweisen. Ich kann wenn ich mich an einem Defaultflieger oder AI Flieger ranzoome so das er formatfüllend ist mir genau die Details betrachten. Zoome ich mich gestuft weg kann ich nicht erkennen das irgendwelche Details nachlassen. Eine Verwendung von LOD Modellen mit weniger Polygonen sehe ich nicht. Ich habe mich auch schon extrem weit weggezommt einen Screenshot erstellt und den vergrößert. Was ich sehe ich das nachlassen von Details allein aus dem Grund das dem Objekt bei der eingestellten Bildschirmauflösung zu wenig Pixel zur Verfügung stehen. Jetzt könnte es natürlich sein das der erste Level LOD_100 ist und der nächste LOD_10, dann könnte man diesen Nachweis kaum erbringen. Das wäre in meinen Augen aber auch nicht ganz logisch. Auf jeden Fall konnte ich so eine Form der Default B747-400 welches Sergio in dem Beitrag auf Seite 72 unten links zeigt im FS nie nachweisen. Laut Sergio das vorletzte LOD Level Modell. Kann bitte jemand der weis wovon ich spreche mal versuchen das im FS nachzuvollziehen. Ich denke hier könnte ev. auch mit ein Schlüssel für manche Flimmerprobleme von komplexeren Objekten liegen. Zuviele Details bedeutet ab einer gewissen Entfernung auch das Problem das die Grafikkarte entscheiden muss welches Teil der außenliegenden Struktur dargestellt werden muss. Bei Bewegung schwankt der Entscheidungsprozess, so das es flimmert. Bei so extremer Entfernung denke ich dürfte eine Kantenglättung wie AA nichts mehr auslösen. Sollte von denen die sich angesprochen fühlen keiner eine Erklärung haben, dann komme ich wohl nicht drum hin Testobjekte zu erstellen mit denen ein eindeutiger Nachweis möglich ist. Das einzigste wo ich LOD Modelle nachweisen kann ist Mesh. Ich meine hier nicht die LOD Level des produzierten Meshfiles sonder die interen LOD Level Bildung z.B innerhalb eines LOD11 Mesh. Nur diese Geschichte ist ein unabhängiges anderes Verfahren was mit LOD Level Modellen bei Objekten nichts zu tun hat. |
Dank Bruno seinem Versuch G-Max Objektbäume über ein Autogenfile zu positionieren konnte ich LOD Level nachweisen.
Danke Bruno. Allerdings kann man leider auch erkennen, das reine Autogentechnik der generierten Bäume wie sie Microsoft bei Ihren Waldlandclass verwendet wohl doch vorerst der Stand der Dinge bleiben wird. Alles andere zwingt die PCs zu stark in die Knie. Dichte Wälder sind wohl mit Objekttechnik nicht machbar. Sind einfach zu viele Polygone. Aber auch hier ist bisher kein Zusammenhang oder Auswirkung durch den Parameter LOD_TARGET_FPS nachweisbar. Allerdings schaffte mein Notebook mit Brunos Files noch nicht mal die UPPER_FRAME_RATE von 10 die ich eingestellt hatte. Muss auf dem anderen PC noch mal testen. Auf jeden Fall wurden meine Bodentexturen während des Anfluges aus weiter Ferne dabei nicht unscharf, obwohl schon die minderwertigsten LOD Level der Bäume den PC sehr früh hinsichtlich Frames einbrechen liessen. Von daher ist für mich dieser damalige Tipp mit UPPER_FRAMERATE auf unendlich und LOD_TARGET_FPS auf einen unteren niedrigen Wert bezüglich Verhinderung unscharfer Boden Texturen Legende. Das hat nichts miteinander zu tun. Das scheint ein allgemeines Überlastungsproblem des FS zu sein (Speicher, Performance allgemein?) welches nichts mit den beiden Parametern zu tun hat. Kurz zur Info. Habe mich auch hinter einen AI Traffic Flieger gesetzt und mal den reinen Flugabstand variert. Auch dort ist jetzt LOD nachweisbar. Mal sehen woran es gelegen hat das es mit reinen Zoomen nicht geklappt hat. Diese Aussage von Louis Sinclair mit LOD_100 bei voller Belegung der Bildschirmbreite, passt zumindest bei Brunos Technik nicht. Bei MIP Leveltechnik von Texturen an Objekten habe ich eindeutig nachweisen können, dass es hier ein Pixelverhältnis gibt. Nämlich: Wie groß ist das Verhältnis von Texeln der Textur zu den Pixeln die der Textur auf dem Bildschirm bei der eigenstellten Grafikkartenauflösung zur Verfügung stehen. So kann es dann im Extremfall bei schrägen Objekten durch die Texturverzerrung dazu kommen, dass auf einer schrägen Objektfläche ein MIP Levelwechsel erfolgt. Das bedeutet das MIP Level Verhalten ist auch abhängig von der Grafikkartenauflösung. Ich denke genau so wird es sich bei LOD Leveln von Objekten verhalten. Es gab mehrere Theorien die ähnliches über Mesh aussagen. Das kann ich nicht bestätigen. Hier sehe ich das anders. |
Hallo Jobia,
was ich für dich mal heute erstellen könnte ist ein gmax-Flugzeugmodel aus einem 10 M³ Würfel, LOD-Level farblich unterscheidbar. Dann hast Du was zum experimentieren. Bei den Objekten/Autogen: Was ich gerne hätte wäre eine definitive Aussage darüber, ob Autogen von der Performance auch besser ist, wenn man bei den Objekten Libraries nutzt. Dadurch gibt es nämlich gegenüber explizit positionierten Objekten einen Performancevorteil. Natürlich werden die Nicht-Autogen Objekte genauso Polyschonend aufgebaut wie die Autogen Objekte. Ich habe auch einmal testweise Würfel in die Umgebung verteilt um die Reichweite von LOD-Objekten fest zu stellen. Habe es aber versäumt das Reglerabhängig einmal zu testen. http://pics.flightxtreme.com/LOD.jpg |
Ok... anbei ein mdl File zum Testen.
"Flugzeug" ändern Farbe und Gestalt. Größe 10 Meter. Kurzer Test bei Zoom 1.00: LOD 400: bis 46 Fuss Abstand Quarder LOD 150: bis 93 Fuss Abstand Kugel LOD 75: bis 200 Fuss Abstand Zylinder LOD 35: bis 467 Fuss Abstand Torus LOD 15: bis 1800 Fuss ??? Abstand Kegel (Wechsel zur Teekanne nicht wirklich ausmachbar) LOD 5: bis ? Fuss Abstand Teekanne |
Hi Michael,
Zitat:
Alles aber nur mit FS2004-SDK. Ciao, Rainer. |
Zu
Zitat:
Nimmst mir Arbeit ab, das ist gut. Oben bei Brunos Dateien ist ein Fehler in meinem Text. " obwohl schon die minderwertigsten LOD Level der Bäume den PC sehr früh hinsichtlich Frames einbrechen liessen." Das ist was die LOD Level betrifft korrekt. Da die verschieden LOD Level aber kaum Polygonunterschiede haben ist natürlich keine große Performancesteigerung bei Entfernung zum Objekt zu erwarten. |
Danke Rainer, das hatte ich eigentlich auch erwartet und entspricht so meinen eigenen Tests. :)
Jobia, keine Ursache. :) |
Noch mal ein bischen Nebenanmerkungen zu dem Thema.
Der FS benötigt zunächst die Parameter UPPER_FRAMERATE_LIMIT und LOD_TARGET_FPS für den Start des FS nicht. Man kann diese Zeilen in der FS9.CFG ganz löschen. Der FS generiert sie dann wie das bei anderen Einträgen auch der Fall ist neu. Die meisten wissen ja das der FS2004 die FS9.CFG bei Erstinstallation erstellt. Oftmals ist hin und wieder auch das löschen der FS9.CFG ein Notnagel den FS bei Störungen wieder zum laufen zu bewegen. Nicht jeder Tipp in den Foren ist sinnvoll. Die Defaulteinstellung bei Generation ist bei UPPER_FRAMERATE_LIMIT=0 und LOD_TARGET_FPS=25 Löscht man einfach nur die LOD_TARGET_FPS und hat UPPER_FRAMERATE_LIMIT anstatt 0 auf 30 stehen, wird die LOD_TARGET_FRAMES als der bekannte 70% Wert generiert. Da der Parameter bei fehlen immer neu generiert wird, müsste man eigentlich davon ausgehen das er einen Sinn ergeben sollte. Mittlerweile fällt mir aber nichts mehr ein worauf der LOD_TARGET_FPS noch Einfluss haben könnte. Auf das MIP Level Verhalten von Texturen/Bodentexturen scheint er keinen Einfluss zu haben. Ich habe alle möglichen Einstellungen und Lastzustände durchgespielt es ist nichts nachzuweisen. Bliebe noch das zum Schluss angesprochene Verhalten von LOD Leveln von Mesh und Objekten. Mesh konnte ich im Vorfeld schon ausschliessen, da hier generell andere Steuerverfahren bezüglich LOD Level verwendet werden. Bleibt nur noch Objektcode übrig der Multi-Resolution Modelle in Form von LOD Leveln enthält. Ein Multi-Resolution Modell ist z.B ein Aircraft welches im Nahbereich sehr detailiert dargestellt wird inkl. virtuelles Cockpit, Antennen usw. Dadurch benötigt es sehr viele Polygone und damit zwangsweise sehr viel Performance. Umso mehr Polygone der FS bzw. das komplette PC System berechen muss umso stärker bricht die Performance und damit die Frames also die Bilder pro Sekunde die der PC darstellen kann ein. Wir bekommen ein ruckeligen Flug. Hat man viele solcher detailierten Aircrafts z.B bei künstlichen AI Traffic dann zwingt das den FS in die Knie. Der Sinn solcher Multi-Resolution Modelle ist es innerhalb eines Flugzeuges mehrere Qualitätsstufen (LOD-Level) dieses Fliegers anzubieten. Ist der Flieger weit weg, werden Antennen virtuelles Cockpit und andere Details nicht mehr dargestellt, die Grafikkarte könnte in hoher Entfernung diese Details bei der eingestellten Grafikkartenauflösung eh nicht darstellen. Das Verfahren bewirkt weniger Flimmerneigung des Objektes, weniger Polygone die zu berechnen sind und damit letzendlich höhere Frames. Damit nicht beim wegbewegen von so einem Objekt der urplötzliche Verlust von Details auffällt bringt man mehrere unterschiedlich gut aufgelöste Modelle (Multi-Resolution Modelle) des Basisfliegers in einem Flugzeugmodell unter. Das Verfahren wo welches qualitative LOD Level Modell räumlich verwendet wird, hängt von dessen Größe im Verhältniss zu dem Platz ab, den es auf dem Bildschirm in Form von Pixeln belegt. Dieses Verhältniss kann man jedem einzelnen LOD Level bei der Programmierung im Designprogramm mitteilen. Das bedeutet hinterher beim Anwender entscheidet nur noch der Sichtabstand zum Objekt und was man unbedingt wissen sollte, auch die verwendete Grafikkartenauflösung darüber, wann welches LOD Modell zur Anwendung kommt. Ähnlich verhält es sich bei MIP Leveln von Texturen (bei diversen Scenerytechniken, nicht bei allen) Ich schreibe hier etwas ausführlicher, weil ich mir dann den Beitrag den ich zuvor in meiner Doku verfasst habe, sparen kann. Ich verlinke dann in der Doku ev. direkt auf das Forum. Dann sehen nämlich andere auch gleich das offensichtlich bisher niemand bei genauer Betrachtung erkennen kann, dass dieser Tipp jemals etwas beweisbares ausgelöst hat. Der etwas üble Beigeschmack an der ganzen Geschichte ist, dass auch dieser Sachverhalt den die offizielle Hilfe zum Simmulator äußert nicht nachvollzogen werden kann. Zumindest hat sich bisher niemand gefunden, der den dort geschilderten Sachverhalt eindeutig bestätigen kann. Übrigends sind diese Muli-Resolution Modelle auch mit einer der Gründe warum man sich die ganzen Diskussionen und Vergleiche von Frameraten bei den üblichen Performancediskussionen und PC Vergleichen sparen kann. Denn jedes installierte Addon oder schwankender AI Traffic, anderes Wetter andere Einstellungen in der FS9.CFG, andere Grafikkartenauflösungen andere Grafikkartentreiber usw. haben Einfluss auf die Performance. Wer kann hier schon für identische Verhältnisse garantieren. Niemand. Kommen wir auf unsere Multi-Resolution Modelle zurück. Wir wissen durch Verwendung niederwertiger LOD Level von Multi-Resolution Modellen müssen weniger Polygone verarbeitet werden. Das wiederrum bedeutet eine höhere Performance. Normalerweise erfolgt diese Regelung der LOD Level im FS entsprechend der eingestellten Grafikkartenauflösung (optisch ausgelegt) anhand der Entfernung zum Objekt. |
Da wäre es doch logisch, wenn man hier einfach eine Möglichkeit schafft bei Performanceproblemen generell ein umschalten zu niederwertigen LOD Modellen zu erzwingen. Auf diese Weise könnte man Performance gewinnen.
Eigentlich kann man so etwas auch aus der Hilfe des FS2004 interpretieren. Da oft die Bodentexturen als erstes unscharf werden wenn die Performance schwach wird, würde sich jetzt hier der Kreis zu dem damaligen Tipp ev. wieder schliessen. Allerdings nur wenn man diese anhand durch LOD_TARGET_FPS erzwungene Umschaltung der LOD Level nachweisen kann. Danke noch mal Andragar und Bruno für die Multi-Resolution Modelle. Das erspart mir die Programmierung eigener Modelle. Mittels dieser Modelle ist ein Nachweis optisch besser möglich. Es könnte nämlich sein, dass der FS diesen Eingriff nur bei sehr niederwertigen LOD Modellen macht, damit ein Anwender diesen Kunstgriff nicht sofort bemerkt. Durch diese speziellen Testmodelle ist gewährleistet, dass man auch bei sehr niederwertigen LOD Modellen die Änderung nachweisen kann. Von LOD Level zu LOD Level verändert sich Form und Farbe der Objekte. Brunos Modelle sind statische Objekte am Boden die zusätzlich den FS schön belasten. Andragars Modell habe ich mit den Flugeigenschaften der Beechcraft Baron 58 verknüpft. Es fliegt im höchsten LOD Level ein Lila Würfel durch die Luft. Im nächsten eine rosa Kugel, danach ein cyan farbener Zylinder usw. Ich habe mich zum testen so hinter dem Würfel positioniert, dass er auch bei Schrägflug gerade noch nicht ins nächste LOD Modell zur Kugel umschlägt. Dieses Verfahren habe ich später auch für die nächsten LOD Level getestet. Nun bin ich mit dem guten Stück und halbwegs konstant belastenden Testscenerien durch die Gegend geflogen. Dabei immer die Frameraten im Auge. Anhand dieser Werte wurde dann der Framevorgaberegler so eingestellt das jeder Zustand während der Testflüge durchgespielt wurde. Mal lagen die Frames eindeutig über der LOD_TARGET_FPS, dann deutlich darunter. Mal näher darunter, mal näher darüber. Auch Frames über der UPPER_FRAME_RATE wurde simmuliert. Sowohl bei Andragars GMAX Flugmodell als auch bei Brunos GMAX Scenery konnte kein einziges mal eine Änderung des LOD Level erzwungen werden. Ich habe das ganze dann noch mal bei der Defaultbeechcraft, bei AI Traffic und den Wolken beobachtet. Ganz zum Schluss habe ich direkt die Polygonmodelle beim testen betrachtet. Fazit bei meinen beiden PCs kann ich trotz ausführlichen Tests keinerlei Auswirkungen bezüglich LOD_TARGET_FPS entdecken. Der Paramter löst bei meinen beiden PCs nichts nachweisbares aus. Auswirkungen habe ich bei meinen PCs nur bei dem Parameter UPPER_FRAME_RATE. Hier aber auch nur in der Form, dass der Parameter in der Lage ist die Frames auf den voreingestellten Wert zu beschränken, insofern er es schafft die Framevorgabe zu erreichen. Da diese Begrenzung der Frames nach oben ständig starke Frameschwankungen durch unterschiedliche Lastzustände verhindert, läuft speziell mein P4 3,4GHz flüssiger wenn ich die UPPER_FRAME_RATE in einen Bereich lege, der dem Wert entspricht den die Frames bei mittlerer bis starker Last haben. Bei meinem schwachen Notebook gibt es diese starken Frameschwankungen nicht, von daher wirkt sich eine Framebegrenzung nicht so positiv wie beim 3,4GHZ PC aus. Dieser Tipp bezüglich der Einstellung dieser beiden Parameter (der unter anderem unscharfe Bodentexturen verhindern sollte) gehört für mich ab heute definitiv zu den Mythen. Unscharfe Bodentexturen sind ein allgemeines Performanceproblem durch hohe Systembelastung (Speicher, Auslagerungsdatei, CPU, Grafikkarte usw.) Wobei es mit Sicherheit bei den Anwendern Schwankungen geben kann was gerade die Probleme auslöst. |
Hi!
Habe mal Eure mühen getestet. Wie Joachim schon schrieb,der Regler hat bei mir keinerlei auswirkungen auf die Bodentexturen. Dieser thread wäre kurz zusammengefasst mal etwas für die FXP. Dort erreicht er mehr Leser und vor allem diejenigen,die immer noch glauben irgendwelche abgehoben Werte verbessern den FS Ablauf. |
Hallo Joachim,
Habe dies jetzt nur "überflogen"! Werde dies jedoch noch genauer lesen. Der Schieberegler steht bei mir bei 19. Warum? Keine Ahnung ist eine schöne Zahl ;) Auswirkungen habe ich eigentlich nie gesehen. Hier ebenfalls eine aktuelle Diskussion (ohne die Veränderung der LOD Target Werte): http://forums.avsim.net/dcboard.php?...5663&mode=full Aber was der "Schieber"(oder die Eintragung in der cfg) tatsächlich bewirkt, bzw. bewirkt hat? Mein System bricht bei anderen, vielleicht wichtigeren Vorgängen, ein. Horst |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 18:32 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag