Zu

"Das mit dem Nachladen der Texturen von der Festplatte ist eine ganz gute Erklärung für die Effekte, die bei meinem Szenario auf meinem Rechner auftreten. Bewegt man sich in der Spot-Plan um das Flugzeug herum und sieht fast senkrecht nach unten, dann werden irgendwann die Texturen unter dem Flugzeug scharf abgebildet. Wenn man dann fast waagrecht den Blick auf die Wolkenfronten im Norden richtet, dann fängt die Framerate zu stottern an. Blickt man danach nach unten, dann ist häufig die Textur wieder unscharf."




Bis hierhin ist der beobachtete Effekt von Dir korrekt.

Aber das hängt damit zusammen, dass die Terrainengine die MIP Level weitgehend abhängig von der Sichtposition des Anwenders steuert. Ebenfalls beim Mesh.

Was sehr sinnvoll ist. Gründe sind in der Dok.




Zu"

D.h., der FS9 wirft die scharfe Textur aus dem Speicher und muss sie erst wieder von der Platte laden."

Nein glaube ich eigentlich fast nicht.


Wenn ich eine großflächige LC Scenery nur mit einer LC Nummer definiere bezieht der FS alle MIP Level aus dem Speicher. Es erfolgt kein erneuter Zugriff auf Festplatte. Habe ich gestern geprüft. Nur wenn die Terrainengine ein Wechselspiel zu verarbeiten hat, werden MIP 0 und 1 von Festplatte bezogen.

Zu
"Das unschärfere MIP-Level behält er im Speicher und stellt es dar."

Allerdings ist das kein statischer Zustand. Auch hier muss man bedenken das jede größere Veränderung erneuten Zugriff auf die Texturen im Speicher bedarf.

Plus eben diese 2 Mips von Festplatte.


"Die Logik dahinter kann ich ansatzweise sogar nachvollziehen. Die höheren MIP-Levels werden bevorzugt im Speicher gehalten, damit der FS9 wenigstens irgendwas darstellen kann. Sonst wären ja im Hochlastfall nur weiße Flecken zu sehen."



Nicht schlecht, aber in diesem Fall hätten wir Farben ähnlich des vereinfachten Weltmodells was wir im Hintergrund sehen. Habe rausgefunden das im vereinfachten Weltmodell noch ein komplexes Verschiebe man könnte es auch Verwischungsverfahren nennen stattfindet. Weiterhin eine Rauschfilterung mit der selben Steuerdatei die auch LC Texturen rauschfiltert.


"Nur warum schmeißt er die scharfen MIP-Levels überhaupt aus dem Speicher, wenn eigentlich genügend RAM vorhanden ist?"


Ich hatte ja neulich einen Verdacht geäußert, habe mittlerweile einen zweiten.

Es könnte künstlich getürkte Performance für den Default FS2004 sein.


Dazu ev. später mal mehr.

Auf jeden Fall habe ich einiges über das Verfahren und die Probleme herausbekommen.


Hätte wir z.B ein LC File mit gleichmäßiger homogener LC Verteilung, dann hätten wir trotzdem ohne weitere äußere Einflüsse je nach Position im LC File unterschiedliche Ladeprobleme bei den Texturen.


Das bedeutet wenn viele ungünstige weitere Belastungen an so einer ungünstigen Koordinate eintreffen, dann trifft uns das Problem besonders hart.

Auch unsere Flugrichtung kann sich stark auswirken.

Werde auf jeden Fall noch ein paar Messungen machen.

Moin Joachim,

leider nicht Joachim. Kann viele Deiner Dinge einfach nur bestätigen, weil mir Deine Erläuterung strukturiert und klar vorkommt und z.T. sich mit aber nicht näher untersuchten Beobachtungen meinerseits deckt. Wenn man Airports und Gegend zusammenbaut, dann hat man notgedrungen andere Prioritäten.

Die Sache mit dem Nachladen der Texturen ist sehr interessant. Mal gespannt, was Du noch rausbekommst. Wie wäre es denn mal, solche Texturen in eine Ramdisk zu packen?

Ciao,
Rainer.

Wäre ev. eine Möglichkeit. Ich glaube aber nicht das hier das Hauptproblem liegt.

Das Hauptproblem ist das Datenabfrage vom FS. Ich denke die Texturen stehen bei den meisten System auch von Festplatte ausreichend schnell zur Verfügung.

Habe gestern diverse Tests gemacht.

Zu Rainer

"Die Sache mit dem Nachladen der Texturen ist sehr interessant. Mal gespannt, was Du noch rausbekommst. Wie wäre es denn mal, solche Texturen in eine Ramdisk zu packen?"


Habe das mal ausprobiert. Monströse Landclasstestscenery die alle möglichen LC Nummern die es gibt zuweist genutzt. (im Lieferumfang der DOK). Dieser habe ich einen einen lokalen Texturordner mit allen Steuermasken und allen Autogenfiles weiterhin natürlich alle Texturen zugewiesen.


Zwei Varianten geprüft..... einmal auf Festplatte einmal auf Ramdisk.





Ladezeiten waren auf RAM Disk schneller.

Der eigentliche Betrieb geschah unter extremer Last (vier Wolkenschichten). Bei meinen momentanen Einstellungen ergab das ca 18 bis 19 Frames. Leider bei beiden Varianten ....obwohl definitiv bei der einen die Texturen von der RAM Drive nachgeladen wurden, kamen keine messbaren Unterschiede während des Fluges zustande.


Hat also nichts gebracht. Kann natürlich bei anderer Hardware auch anders aussehen.


Was wieder aufgefallen ist, dass Wolken wie bekannt, der Framekiller Nr.1 sind.

Ev. wäre es sinnvoll diese in eine RAM Disk zu packen.
Die Frage ist nur wie. Man kann ja leider nicht wie bei Scenerien einen Pfad in einer datei wie der Scenery.cfg eintragen. Ich habe es noch nicht ausprobiert, aber ich vermute der FS wird nicht selbst danach suchen
.

Fotoscenerien in eine RAM Disk würde eh fast nicht möglich sein, die sind einfach zu groß.

Den FS komplett in einer RAM Disk ist auch nicht vernünftig denke ich.


Damit der Anwender keine Probleme (Registry) bekommt wäre dann eine Installation des FS direkt in die RAM Drive sinnvoll, so muss er sich um nichts kümmern.

Nur das Dumme ist, dass man sich diesen Zustand der RAMDrive irgendwo sichern müsste. Nach einem Neustart dew PCmuss diese Sicherung zunächst in die Ram Drive kopiert werden.


Ich habe 2GB RAM ich denke darunter sollte man keine Gedanken an eine RAM Drive verschwenden.


Die Windows XP Ramdrive die man sich laden kann kommt aufgrund der winzigen maximalen Größe eh nicht in Frage. Es gibt eigentlich nur teure Payware.

Ich habe daher eine Demoversion die keine wesentlichen Einschränkungen hat downgeloaded. Die würde als offizielle Version unter 10 Euro kosten.

Nur wie gesagt bei meinem PC sieht es ao aus als wenn ich aus einer RAM Drive vermutlich keinen nutzen ziehen kann.

Hallo Joachim,

aha. Fein, dann wäre das ja auch zumindest ausgeschlossen.

Wobei... zu den Wolken.
Ich hatte massive Einbrüche, wie ich noch meine ATI9800pro drinnen hatte. Jetzt mit ATI X800XT sind mir Wolkenschichten (bei vergleichbaren sonstigen Einstellungen) völlig egal. Keinerlei Einbrüche mehr. Auflösung 1280x1024, maximal Einstellungen für Qualität und Filterung bei Grafikkarten-Treiberoptionen in XP).

Ob dies jetzt am größeren internen Speicher (128MB -> 256MB RAM der 9800pro zur x800xt) oder einfach an der Geschwindigkeit beim Zeichnen von Polygonen liegt - keine Ahnung.

Ciao,
Rainer.

usw.

Ja, aber nun haben wir immer noch das Problem beim Online-Fliegen.
Ich hatte darauf ja schon hin gewiesen, du hast damals verständlicherweise nicht näher nachgeforscht, da du nicht online fliegst.

Zum Problem: Steht der Regler auf unendlich gibt es den Effect der springenden Mitflieger. Es reicht dabei wenn ein Mitflieger diesen Regler auf unendlich (oder einen hohen Wert (?) ) stehen hat um dieses Problem zu verursachen.

Untersuchungen (nicht von mir) haben ergeben, dass der Flusi in diesem Zustand beständig Packete versenden und damit die Mitflieger-PCs überfordert. Die Flusis scheinen sich zu verschlucken und es kommt zu den Sprüngen.

Ein Zurücknehmen auf z.B. 25 fps bei allen PCs (müssen nicht auf der gleichen Stellung stehen) löst das Problem.

Es scheint also hier auch noch einen Zusammenhang zu geben und den Regler auf unendlich zu stellen ist für den Onlineflieger keine Lösung.

Warum dieses Verhalten an den Tag tritt ist mir aber schleierhaft.

Liebe Grüsse,
Micha

Ich fürchte, das ist ganz einfach schlecht programmiert.

Gerade bei Online-Spielen sollte großes Augenmerk auf die verfügbare Bandbreite und Latenzzeiten des Netzwerks gelegt werden. Bei manchen Autorennspielen werden die Positionen der anderen Mitspieler nachträglich aufgrund der jeweiligen Ping-Zeiten verändert, damit die gegnerischen Fahrzeuge auf dem eigenen Rechner wirklich dort sind wo sie wegen der Zeitverzögerung sein sollten.

Auch bei First Person Shootern wird damit gearbeitet, damit man auch im Netzwerk mit Vorhaltewinkeln "arbeiten" kann.

Ich habe zwar keine dementsprechenden Tests gemacht aber meine Vermutung ist, dass beim Flusi gar nicht soviel Augenmerk auf guten Netzwerk-Code gelegt wurde. Die übermittelte Position sollte auf jeden Fall komplett unabhängig von der Framerate des eigenen Rechners übermittelt werden was sie offenbar nicht wird.

Genau, diese Verknüpfung ist richtig komisch.

Ich vermute man hat an solche Dinge wie Vorhaltezeit gedacht und das anhand der Frameraten irgendwie zu berechnen wann und wie oft das aktualisiert wird.

Was der Flusi aber eindeutig macht, das ist zumindest zwei Positionen der Mitflieger zu nehmen und dann eine weitere Bewegung zu berechnen.

Das merkt man, wenn mal wieder Flieger langsam in den Boden versinken. (Neben dem Problem eines Versatzes. Da scheint es auch noch zu Rundungsfehlern beim Übertragen zu kommen.)

Aber das ist jetzt schon wieder offtopic. :D

Wollte nur damit ausdrücken, dass das Texturproblem auch nicht durch "unendlich" gelöst wird. Zumindest nicht im Onlineflug.

Ok für Onlineflieger käme es demnach nicht in Frage. Ich gehe aber davon aus, dass wenn man alle Anwender zusammenfasst und deren FS Stunden aufsummiert, dass dann nur ein sehr kleiner Anteil Online Stunden sind.


Wie gesagt es nützt so wieso nichts die Framevorgabe hochzusetzen wenn der FS das nicht schafft. Denn dann löst das hochschieben der Frames rein garnichts aus.