FS9.CFG hier UPPER_FRAMERATE_LIMIT & LOD_TARGET_FPS - Seite 3

frank072 · 16.02.2005, 21:28

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? ;-)

JOBIA · 16.02.2005, 21:46

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.

Skywalker · 16.02.2005, 22:15

Zitat:

Original geschrieben von frank072
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? ;-)

1.

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)

Andragar · 16.02.2005, 22:53

Zitat:

Mache ich aber bei beiden FS Versionen einen sofortigen Wechsel im Displaymenü auf unendlich, dann wird UPPER_FRAMERATE_LIMIT=0 gesetzt.
...
Man kann es durch gezielte Einstellung auch direkt im Displaymenü einstellen.

Hier würde ich eher darauf tippen, dass durch "Unendlich" die zweite Zahl irrelevant wird, da die ganze Begrenzungsroutine abgeschaltet wird. Vielleicht kommt das "Stottern" bei der Einstellung dann mehr von der Verarbeitung in der Grafikkarte - bei höchst unregelmäßigen Berechnungsdaten.
Wie schnell kann diese eigentlich Bilder berechnen? Wo nimmt der Flusi seine Frameratenmessung? Doch nicht "hinter" der Grafikkarte, oder?

JOBIA · 17.02.2005, 05:45

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.

JOBIA · 17.02.2005, 05:50

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.

Andragar · 17.02.2005, 09:29

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.

JOBIA · 17.02.2005, 16:14

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.

Andragar · 17.02.2005, 18:04

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.

JOBIA · 20.02.2005, 21:36

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.

16.02.2005, 21:28	#21
frank072 Veteran Registriert seit: 25.01.2003 Alter: 49 Beiträge: 222	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? ;-) ____________________________________ Viele Grüße, Frank J. www.virtual-skyways.de

16.02.2005, 21:46	#22
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	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.

17.02.2005, 05:45	#25
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	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.

17.02.2005, 05:50	#26
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	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.

17.02.2005, 09:29	#27
Andragar Inventar Registriert seit: 19.04.2001 Alter: 55 Beiträge: 3.606	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.

17.02.2005, 16:14	#28
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	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.

17.02.2005, 18:04	#29
Andragar Inventar Registriert seit: 19.04.2001 Alter: 55 Beiträge: 3.606	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.

20.02.2005, 21:36	#30
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	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.

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)