Totaler FPS fresser
 

Hallo,

ich habe mal ne frage ich fliege die Level-d in verbindung mit dem fs2004.

Ich habe den fall das wenn ich normal im Reiseflug bin immer so fps zwischen 20-40 habe. (Cockpit ansicht)

Schalte ich jetzt das Cockpit weg mittels der W Taste. Steigen die FPS sofort auf über 100.

Es kann doch nicht sein das ein normales Cockpit so viel FPS frisst.

Oder ist das normal ?

Grüße
Lukas

Hi,

scheint normal zu sein. Fliege gerade die Level-D über den UL211F (South Atlantic Crossing und damit nur Wasser um mich herum). Mit eingeblendetem Panel habe ich um die 35 fps, ohne Panel 70-100. Hmm.

Das ist durchaus normal, ein ausgereiftes Cockpit nimmt einiges an FPS in Anspruch.



Gruß


Olli

Ich vertsehe nicht, über was ihr euch so aufregt... mehr als 25 fps kann man eh nicht sehen. Kinofilme haben noch weniger!

richtig, einfach mal die frames auf 25 bis 30 begrenzen und alles ist schön. viele würden sich über konstante 30fps freuen!

MfG Ben

Begrenzt auf 24fps, mehr kann das menschliche Auge nicht wahrnehmen.

Auf die Level-D 767 lasse ich, wie der ein oder andere vielleicht mal mitbekommen hat, nix mehr kommen und möchte daher zumindest erwähnen, dass die Level-D zumindest mit dem 2D Cockpit in Bezug auf den Funktionsumfang sogar noch sehr frameratefreundlich ist. Bei mir läufts mit der Level-D z.B. deutlich Besser als mit der PMDG 737.

dem kann ich nur zustimmen!!



Gruß

Olli

Das mag bei Filmen stimmen, bei einem Spiel aber nicht- denn um wirklich flüssig zu erscheinen, müssten die 24 Frames in der Sekunde exakt im gleichen Abstand folgen.

Beim FS zum Beispiel sind die Frames aber eben ein Durchschnittswert, so kann es (extremer Fall) auch vorkommen, dass die erste halbe Sekunde nur ein Frame gezeigt wird, die nächste halbe dann die restlichen 23. Der Ruckler wäre deutlich zu sehen.

In der Praxis ist sowas aber natürlich selten, und für den Flusi braucht man auch gar keine so flüssige Darstellung wie beispielsweise für einen Shooter. Ich selbst fliege nun schon seit langem auf 20fps limitiert und empfinde das als sehr gut fliegbar.

Ich kann euch nur beneiden meine Frames liegen

etwa bei 10.

Gruß Thomas:eek:

Gilt generell für den FS2004 so nicht.

Zum einen aus den erwähnten Gründen, da die normal angezeigten Frames ein Mittelwert sind, es sind also keine konstanten Frames.

Kann man auch sehr schön sehen, wenn man den FS so einstellt, dass man auch die aktuellen Spitzenwerte sieht.

Der Hauptgrund ist aber ein anderer.

Hat man beim FS schnelle Sichtschwenks dann wird der ein oder andere feststellen, dass man zunächst auf unscharfe Bodentexturen trifft.

Grund die Scenery muss da es sich um komplett neue Sichtperspektiven handelt neu berechnet werden.


Bei dieser Berechnung wie schnell die abläuft, kommt es zu einem großen Anteil auf die erreichte Framerate an.

Hat man wenig Frames dauert es lange bis man scharfe Scenery hat. Hat man hohe Frames geht das sehr schnell.

Diese Unterschiede kann der Betrachter natürlich sehr wohl wahrnehmen.


Bei einem Film welcher ja ein ganz anderes Medium ist, ist das alles nicht so wichtig, da bestimmt ja vereinfacht gesagt der Regisseur was der Betrachter sehen soll.



Nicht aber im FS wo Ihr entscheidet was Ihr sehen wollt. Der FS kann das also vorher nicht wissen.


Darum kann man Games zum Teil je nachdem um was für eine Art Game es sich handelt und wie Ihre Engine ist nicht mit Filmen vergleichen.

Hier bei einem Game bekommt die Framerate eine ganz andere Wichtung.

Hallöchen zusammen,

die Aussagen 24 f/s oder 24 Bilder/s sind weder identisch noch haben sie etwas gemeinsames.

Zunächst zu den Bildern/s. Hier ist es nicht so, dass beim Film 24 Bilder gezeigt werden. Durch einen einfachen Trick wird dem Auge eine Bildfrequenz von 48 Bildern vorgegaukelt, indem jedes Filmbild im Projektor angehalten wird und dem Betrachter durch Abdunkeln zweimal gezeigt wird. Dadurch wird gerade die Flimmergrenze von etwa 60 Hz unterschritten und wenn sehr helle Filminhalte gezeigt werden, sieht man das Flimmern doch stark.
Beim Fernsehen wird es ähnlich gemacht. Hier werden zweimal 25 Halbbilder in der Sekunde übertragen. Erst durch Zwischenspeicherung kommt man dann auf 100 Hz für flimmerfreie Bilder.

Die Frames/sec sind aber nicht mit der Bildfrequenz gleichzusetzen. Selbst bei 5 f/s wird das Bild flimmerfrei dargestellt, weil die Bildfrequenz nach wie vor 60 oder 85 Hz beträgt, je nach Einstellung. Bei 5 f/s wird ein Frame eben 12 mal (bei 60 Hz) dargestellt, was dazu führt, dass das Bild scheinbar ruckelt.

FRAGE:

also wenn ich meine FPS auf 25 begrenze ..was bring das...wird dann übrige mmmm ja leistung fuer andere prozesse zur verfügung gestellt?

Genau, so ist hier im Forum die allgemeine Theorie. So richtig bewiesen hat es jedoch noch niemand. Es ist halt logisch.

ok gracias:-)

ZU

Doch sie sind hier bei Games ein und dasselbe. Wir dürfen nicht verschiedene Medien wie Film / Fernsehen mit PC Technik oder Games vergleichen.

Wer würde z.B den Begriff FPS (Frames per Second) ins deutsche mit dem Begriff "Rahmen pro Sekunde" übersetzen, dass würde für die meisten so gut wie "Nichts" aussagen und trifft hier auch nicht den Nagel auf den Kopf.

So finden sich in englischen Wörterbüchern bei der Übersetzungen von Frame wenn dieser Begriff in Bezug zu Fotos oder ähnlichen steht hier der Begriff "Einzelbild" für die Bezeichnung "Frame".


Genau das sagt er bei Games aus....... Einzelbilder pro Sekunde.

Ich denke ob jemand Einzelbild pro Sekunde oder Bild pro Sekunde benutzt sollte man nicht so pingelig auslegen.

Genau genommen müsste man bei Games von berechneten Einzelbildern der Grafikkarte pro Sekunde reden. Man könnte da noch mehr ins Detail gehen, da es noch bestimmte techniken gibt, aber lassen wird das.

Wir müssen bei PC Technik, Fernsehen und Film komplett unterscheiden.

Die Technik ist Grund verschieden, es geht hier auch um ganz andere technische Aspekte.

Beim Film ist übrigens zusätzlich zur zweimaligen Dunkeltatstung auch die dreimalige Dunkeltastung üblich. Wir können also auch auf eine ich will es mal fiktive Bildwechselfrequenz von 72 Hz kommen.

Wie es bei aktuellsten Kino Filmtechniken aussieht keine Ahnung.

Beim Fernsehen ist es wieder etwas anderes. Unsere Pal Norm wird ja auf Hochfrequenzseite gerade durch DVB-T komplett ersetzt. Im Bereich der Videoebene ist sie vermutlich noch länger aktuell.

Hier werden wie Du schon sagst 25 Vollbilder pro Sekunde in Form von 50 Halbbilder pro Sekunde übertragen.

Bei diesen 25 Voll Bilder sprechen wir von Bildwechselfrequenz. Nur allein Bilder pro Sekunde wäre hier ja eigentlich auch nicht ganz korrekt.

Diese 25 Vollbilder waren damals quasi ein Kompromiss an die Technik, da alles andere technisch aufwendiger gewesen wäre.


Mit den 25 Bilder pro Sekunde hätten wir die Dunkeltastung während der Zeilenrücklaufphase aufgrund der nur 25 Bilder als flimmern wahrgenommen. Daher der Umweg über 50 Halbbilder im Zeilensprungverfahren in der (Rasterfrequenz/ Vertikalfrequenz/ Bildkippfrequenz)

Bei 100Hz Technik dann noch über Speicherung der Bildinhalte.

Nur welche dieser frequenzen setzt man jetzt der pc technik gleich?




Um den Sprung zum pc zu schaffen müssten wir die 50 hz des pal tv beim pc der v synch frequenz des monitors / graka gleichsetzen also
der bildwechselfrequenz.



die 25 hz (vollbilder) des pal tv den frames pro sekunde also den einzelbildern die die grafikkarte pro sekunde berechnet unabhängig zu der eingestellten bildwechselfrequenz der graka.

eigentlich dürften wir dabei natürlich nicht vernachlässigen, dass die verfahren pc und tv hinsichtlich synchronisation komplett abweichen.

ich denke also man kann fps in der gametechnik eindeutig mit einzelbildern / bildern pro sekunde gleichsetzen zumal es hier auch um belastung ging und nicht um bildflimmern.

so ist sogar die offizielle aussage in der microsoft hilfe. auch ein entwickler hat das so ausgesagt.

ich hatte damals mal einen thread und eine untersuchung dieser aussage gestartet, kann ihn jetzt aber nicht raussuchen da ich unsere kleine auf dem arm habe.


ich sehe das nämlich anders. ich habe alles mögliche über diverse techniken untersucht, es war nichts nachweisbar außer das der onlineflug als externer prozess etwas profitiert.

der fs intern nicht...... zumindest nicht nachweisbar.

Eine frage zum letzten Beitrag....PAL...mm sagt mir gar nichts ist das das Deutsche video System?WEil du hattest davon oefters gesprochen. ich kenne nur NTSC.Von PAL habe ich auch mal gehoert ..will jetzt nicht nach unterschieden fragen wollte es nur mal wissen.

Anderes gefragt,

was bringt es mir in FL350 mit 100fps rumzufliegen :lol:??

Ich fliege mit 24fps genauso präzise wie mit 100fps.

Operationell spielt es wirklich keine Rolle. Begrenzt ruhig auf 24fps. Das Bild bleibt ja trotzdem flimmerfrei, die Hz (Bildwiederholfrequenz) des Monitor haben ja nichts mit den fps des FlightSim zu tun!

Und hier sind 24fps wirklich mehr als ausreichend. Selbst mit 20fps ist ein ruckelfreies - "weiches" - fliegen noch möglich.

Wenn man dagegen nicht begrenzt fällt es umso negativer auf wenn man z. B. im Approach noch 70fps hatte, dann im Final 20fps und auf dem Apron 15. Dann bemerkt man den Unterschied wirklich. Wenn man aber konstant nicht mehr als 24/20fps hat gewöhnt sich das Auge an diese Frequenz und es fällt weitaus weniger auf wenn man mal 4-5 fps abfällt.

Das habe ich jetzt inzwischen mehrere Monate an mir selbst getestet, und bin der Meinung das 20fps die sinnvollere Wahl darstellen.

Womit wir wieder den Bogen zur MS-Default Einstellung hätten.

Die 20 Bilder pro Sekunde ;) nehme ich (subjektiv) als absolut flüssig wahr. Und ich sehe ehrlichgesagt keinen Grund eine höhere Zielframrate einzustellen.

Vielleicht wäre ein Grund der Sichtwechsel. Aber ich bin ein Airlineflieger und hauptsächslich in IFR Conditions unterwegs. Da erübrigt sich das nach links/rechts rausschauen....

Bei Circlings schaue ich eh einmal grundsätzlich nach links/rechts um alle Texturen zu laden. Dann habe ich später keine Probleme mehr mit irgendwelchen Hängern beim Nachladen.


So - und jetzt macht mich fertig :D

@Marc
So sehe ich das auch. Grundsätzlich sind 25 f/s (nicht Bilder/s !) ausreichend. Auch hierzu gibt es im Forum Aussagen, dass eine unendliche Framezahl der Sichtweite gut tun soll. (Siehe meinen Thread weiter oben wegen des Nachweises)

@JOBIA
Okay, mann kann nicht alles wissen.
PAL ist eine (deutsche) Fersehnorm, DVB-T (ebenso wie DVB-S und DVB-C) ein Übertragungsverfahren mit dessen Hilfe es möglich ist grundsätzlich jede Norm zu übertragen.
Im Übrigen arbeit ein PC-Monitor exakt wie ein Röhren-TV. Daher kommt er nämlich. Im Laufe der Zeit haben sich allerdings die Anforderungen an einen Röhrenmonitor sehr geändert. Kein TV-Monitor musste zunächst z.B. 85 Hz Bildfrequenz darstellen können, ein Monitor schon. Später änderte sich das auch bei den 100-Hz-TV´s. Durch die LCD´s und TFT´s haben sich allerdings auch hier Änderungen ergeben, denn hier reichen durch die Vollbilddarstellung locker 60 Hz zur flimmerfreien Darstellung. Ach ja, und PAL spielt hier natürlich keine Rolle.

Aus meiner Erfahrung heraus gibt es nur einen Grund die FPS zu begrenzen, und das ist das Online-fliegen. Der Grund scheint das Senden (Empfangen?) von Datenpacketen zu sein, die dann die empfangenden PCs nicht mehr verarbeiten können und so die Mitflieger springen lassen. Es reicht dabei aus, wenn ein Mitflieger die FPS nicht begrenzt hat. Scheinbar ist das Versenden der Datenpackete mit den FPS verknüpft.

Einen anderen Grund für eine Begrenzung kann ich - wie Jobia auch - nicht erkennen.

Ja PAL war bisher die im europäischen Raum am meisten verbreitete Norm der TV / Videosignalübertragung.

NTSC kommt aus dem amerikanischen Raum.

wesentliche Unterschiede sind z.B die Bildwechselfrequenzen bei PAL 50 HZ, bei NTSC 60 HZ.

Weiterhin wie die Chroma / Farbinformation im Signal abgelegt und dessen Stabilität gesichert ist.

Wie gesagt mittlerweile dürfte bundesweit nur noch auf DVB-T terristrisch Fernsehen empfangbar sein, über normalen Tuner seit letzte Woche nicht mehr.

Da spielt PAL nun keine Rolle mehr.

Wohl aber bei den meisten die noch die üblichen Röhren Fernseher besitzen, die keine RGB oder andere aktuellen Signalformen verarbeiten.

Denn der nun nötige DVB-T Receiver muss diesen ein Video Signal über die Video Cinch Buchse bzw. die beiden Scart Videopins liefern. Dieses hat Signal noch PAL Norm.



Ansonsten

Ja ein Röhrenmonitor arbeitet aus Sicht der Röhre selbst exakt wie eine TV Röhre, auch die Strahlablenkung. Nur das wir halt nicht an feste Ablenkfrequenzen beim PC Monitor gebunden sind, weiterhin wir hier eine höhere Auflösung darstellen können, was beim PAL TV keinen Sinn ergeben hätte, da die Übertragungsbandbreite begrenzt ist.

Siehe
http://steve-lacey.com/blogarchives/...blurries.shtml
und
http://www.steve-lacey.com/blogarchi...stutters.shtml
(auch die Kommentare!)

Die Begrenzung (target frame rate) ist "locked" in "Fullscreen" (Monitor) und im "Windows Modus" nicht.

Es hat schon einen Sinn es zu begrenzen. (Fibers)!

Aber im Prinzip auch abhängig von der Hardware und Treiber, also dem System des Anwenders.
Und vor allem auch der Verwendung von diversen "Addons", die mit ihren "Tricks" auch einiges wieder "aushebeln"

Siehe auch:
http://forums.avsim.net/dcboard.php?...id=3398&page=2
oder für multi core:
http://blogs.msdn.com/sebby1234/arch...06/567438.aspx

Das in der Hilfe steht, man soll auf seinem eigenen Geräte sein Limit finden, ist IMO korrekt, da es ja von sehr vielen Faktoren abhängt.

Horst

nicht ganz richtig Deine Aussage. Es geht hier wie gesagt nicht um das Thema Flimmern,

Du sagts ja selbst:

die Hz (Bildwiederholfrequenz) des Monitor haben ja nichts mit den fps des FlightSim zu tun!



Es geht um die erreichte FPS Rate, also die Rate der von der Graka berechneten Einzelbilder.


Gerade bei Bodentexturen verwendet die FS Grafik- und Terrainengine ein spezielles Verfahren um die MIP Level also die verschiedenen Qualitätsstufen der Bodentexturen zu laden.

Für dieses Verfahren gibt es einen ganz speziellen Grund.

Der Grund waren Custom Fotoscenerien, dessen Speicherbedarf während des Fluges. Da Custom Fotoscenery und normale Landclasscenery nach identischen Verfahren arbeiten, ist dieses das generelle Verfahren
was der FS bei der meshkompatiblen Bodentexturierung anwendet.

Ich möchte die genauen Gründen hier nicht erläutern.


Dieses Verfahren erfordert ein ständiges nachladen von Bodentexturen während der Bewegung. (auch von Texturinformationen die zuvor schon mal aktiv waren)

Genau dieses Verfahren hat eine Kopplung zu den erreichten Frameraten.

Habe ich sehr wenig Frames und viele nachzuladenden Informationen weil ich schnell fliege, kommt der FS nicht mehr nach. Wir alle kennen das die Bodenscenery wird mit der Zeit immer unschärfer.

Haben wir aber hohe Frames können mehr Informationen nachgeladen werden. Es wird ev. nur langsam unscharf.


Wenn jetzt jemand seine Frames begrenzt dann ist das in der regel nicht immer schlimm. Wehe aber er hat eine abwechslungsreiche Landclasscenery oder Fotoscenery, dann hat er mit begrenzten Frames sehr häufig unscharfe Texturen trotz eines guten PCs.

Man sollte also nicht unbedingt auf niedrige 20 Frames begrenzen.

Ich hatte mal eine Messkurve dieses verhalten im Forum gezeigt ist schon länger her. Dort kann man die Frameabhängigkeit sehen.

wohl gemerkt diese ist bei ein und dem selben System unabhängig ob es sich um reale Last oder Framebegrenzung handelt.

Werde sie nachher mal suchen.

In meiner DOK werden die Vorgänge genauert erklärt.


Achtung ich gebe zu das wenn man hohe Frames zulässt oder gar auf unendlich stellt Frameschwankungen stärker auffallen sogar in Form von Ruckeln.

Aber Achtung das wird oft durch störende Prozesse verursacht wie z.B Virenscanner siehe auch anderen Thread.

Ihr müsst diese störenden Prozesse nur ermitteln und beenden.

Werden störende Prozesse beendet dann läuft der Fs trotz wilder Frameschwankung ganz smooth.

Probiert es aus.

Zu der Target Frame Rate und LOD Target siehe diesen Link der übrigens vor den Microsoft Blocks entstanden ist.

http://www.wcm.at/forum/showthread.php?threadid=159653


Auch das einem Zeitmultiplex Verfahren ähnliche verhalten also die Stutters hatte ich früher vor den Blogs schon mal erläutert.

Hat mich dann selbst verblüfft, dass sich meine Ergebnisse die ich durch Versuche usw. ermittelt habe exakt mit denen der späteren Blogs decken.

Allerdings kann ich das mit LOD Target trotz offizieller MS Aussagen egal ob Vollbild oder Fenstermodus nicht bestätigen.

Wer weis, ev. ist hier im FS2004 etwas faul. Ev. war es so im FS2002 und im FS2004 arbeitet es nicht so wie von den Entwicklern vorgesehen.

Ich denke da z.b auch an LOD11 Mesh im FS2004 (FS9.0) was ja auch nicht ging, bestimmt aber so nicht gedacht war.


Das mit der Messkurve und den Frames findet sich in diesem Thread.



http://www.wcm.at/forum/showthread.php?threadid=168928

Zu dieser Messkurve müsste ich noch etwas erläutern, muss jetzt aber weg. Ev. später mehr.

hat mit dem Frames im Computer nix zu tun, aber das ist falsch ;)

Das PAL-System ist für die Farbwiedergabe zuständig, genau wie NTSC oder SECAM (sonst hätte man im Osten früher kein Westfernsehen gehabt). DVB-T ist nur eine neue Übertragungstechnik (eben digital).
Aber es wurde ja schon genügend durcheinandergebracht mit den ganzen Begriffen...so richtig läßt sich das wohl nie "ausmerzen" (genau wie die immer "empfohlenen Werte in der FS9.cfg
:-) ).

Ich hatte oben aber geschrieben, dass PAL auf dem Wege der Übertragungstechnik in der HF Ebene keine Rolle mehr spielt.


Auf Video Ebene hinterher schon noch.

Ich habe nicht geschrieben, dass PAl bei unseren bisherigen Fernsehern keine Rolle mehr spielt.

Wenn ich bei meinem System die Frames-Begrenzung von 20 auf 30 hochsetze, bekomme ich an den vielen Stellen, an denen die 20 eh nur knapp erreicht werden verwaschene Texturen.

Da ich hauptsächlich im Flusi "Linie" fliege konnte ich das immer schön nachvollziehen.

Also stimmt das schon, was Microsoft sagt, und funktioniert, und der Unterschied ist sichtbar. Wenn er bei euch nicht sichtbar ist, dann sind vielleicht eure Rechner zu schnell ;-)

Was das PAL Verfahren betrifft. Zu dieser analogen Technik der Farbsignal Unterbringung im ursprünglichen schwarz / weiss Videosignal könnte man natürlich noch sehr viel mehr sagen.

Nur ich denke nicht, dass hier jemand Interesse an solchen Geschichten wie Farbträgerburst, Farbkreis, R-Y, B-Y Signal, Phasenumtastung usw. hat.

Eine etwas kuriose Aussage.

Denn, die Framebegrenzung ist ja nur eine künstliche Begrenzung nach oben die dann in keinem Fall überschritten wird.


Beispiel:

Setze ich die Framebegrenzung auf 30 Frames, dann wird selbst der stärkste PC der hier sonst ev. 100 Frames erreicht dort nur mit 30 Frames arbeiten. Er wird dann bei störenden anderen Prozessen übrigens unempfindlicher hinsichtlich ruckeln.

Habe ich aber ein PC der aufgrund von Performanceproblemen eh nur 20 Frames erreicht, dann wird hier die Framebegrenzung auf 30 keine Frameveränderung auslösen. Der PC bleibt bei seinen durch Performance bedingten niedrigen 20 Frames hängen.

Den jetzt gesetzten oberen Anschlag von 30 Frames erreicht er nicht.



Deshalb funktioniert es ja auch nicht, wenn jemand bei einem eh schon schlappen PC bei Fotoscenery die Framebegrenzung von z.B 20 auf 90 hochsetzt. Das nützt einem schwachen PC nicht, der kommt da ja eh nicht hin.

Also ich habe einen schnellen Tower PC mit 3,4GHz und einen langsamen PC ein Notebook mit 2,53 GHZ der natürlich unter gleichen Sceneryverhältnissen arge Probleme hat.

Anhand beider kann ich diese Sachverhalte eindeutig nachvollziehen auch in Sicht Upper Frame Rate Limit und LOD Target.

Auch bei einigen Bekannten bei denen ich das an deren PCs getestet habe ist das nachvollziehbar.



Auch die Blogs der Microsoft Entwickler spiegeln dieses wieder.

Bis auf diese besondere Geschichte mit den Auswirkungen von LOD Target.

Als letzte Möglichkeit bleibt aus meiner Sicht nur noch der LOD bei Mesh übrig der hier unter LOD Target beieinflusst werden könnte.

Egal wie LOD Target steht es wird allerdings bei mir immer der höchstwertige LOD Level erreicht der im aktiven Mesh vorliegt.

Allerdings benötigt auch der höchste LOD Level eine Zeit bis dieser geladen ist.

Ev. gibt es hier eine Beeinflussung der Zeit wie schnell das abläuft entsprechend eingestellten LOD Target und erreichter Frames.

Hier habe ich mir ein paar Testmöglichkeiten ausgedacht.


Ok lassen wir diese Thematik. Ev. gibt es bei dem ein oder anderen doch Unterschiede die auf den PCs auf die ich bisher Zugriff hatte nicht aufgetreten sind.




Achtung, etwas was ganz wichtig bei solchen Aussagen wie Deiner ist, ist folgendes.

Innerhalb einer abwechslungsreichen Landclasscenery gibt es extrem unterschiedliche Belastungszustände. Wer jetzt ohne spezielle Testscenery eindeutige Vergleiche anstellen möchte, müsste sicherstellen, dass er beim Vergleich exakt die selben Flugzustände vorliegen hat.

Also identische Uhr / Tageszeit bei frisch aufgesetzten FS. Exakt gleiche Fluggeschwindigkeit, gleiche Höhe, gleiche Flugrichtung, gleiche Wolken, Sichtbedingungen, AI Traffic usw. identisches Laden von Addons, weiterhin keinerlei den FS störenden externen Prozesse.

Ich waage es zu bezweifeln, dass ein normaler Anwender dies alles bei seinen Aussagen berücksichtigt. Er wird also kaum stabile Zustände haben.

Ich habe dieses bei meiner Messreihe berücksichtigt.

Ich habe weiterhin mit einem Testmesh und einer speziellen Landclasstestscenery gearbeitet die im Gegensatz zu normaler Landclasscenery eine eindeutige Beurteilung über den aktiven MIP Level zulässt.


Es wurden zunächst alle anderweitigen Prozesse beendet. Nur noch der FS zeigte während der Messungen Aktivität.


Autogen AI Traffic und veränderliches Wetter usw. waren bei dem Test des Upper Frame Rate deaktiv. Keine anderweitigen Addons waren aktiv.

Es wurde auch nicht geflogen.

Der FS wurde im Slewmodus über eine gespeicherte Flugsituation aufgerufen.

Dann wurde ein extern eingeleiteter dauerhaft reproduzierbarer Koordinatensprung an immer die selbe Koordinate ausgelöst.

Die Bodenscenery ist dann schlagartig unscharf. Jetzt wurde gemessen wieviele Sekunden der FS benötigt um den höchsten MIP Level je nach eingestellten Upper Frame Rate zu erreichen. Diese Werte kamen in die Kurve.

Bestimmte Upper Frame Rate Werte und zugehörige Ladezeiten habe ich mir rausgepickt.

Nun wurden weiter Testa mit Upper Frame Rate auf unendlich bzw. auf begrenzten 90 Frames gemacht.


In dieser Messreihe wurden reale relativ konstante Lasten über geschlossene Wolkenschichten erzeugt. Geschlossene, da alles andere keine halbwegs stabilen Frames gewährleistet.

Über Anzahl der Wolkenschichten und dessen Höhe wurden Frameraten erzeugt die auch in der vorigen Messkurve auftauchen.


Es ergaben sich unter realen Lasten erstaunlich identische Ladezeiten, was aus meiner Sicht den Sachverhalt eindeutig bestätigt.

Anschliessend wurde das dann bei realen Flügen mit unterschiedlichen Fluggeschwindigkeiten getestet. Das selbe Ergebnis wie bei der Messreihe allerdings logischerweise nicht mit ganz so stabilen sauberen Kurvenverläufen.

Der Grundverlauf war aber identisch.

Dieser Kurvenverlauf selbst sollte bei allen Anwendern ähnlich sein. Sie verschiebt sich allerdings je nachdem wie die Gesamtperformance ist, bzw. wie andere Addons zu dem Zeitpunkt X das System gerade belasten.

Selbstverständlich wird dieses auch durch andere Prozesse die ev. nur hin und wieder laufen beeinflusst.

Der normale Anwender kann so etwas an der gemittelten angezeigten Framerate natürlich nicht beurteilen. Microruckler bekommt er an der Framerate nicht mit.
Er bemerkt sie aber optisch ev. im Flug.



Die Tests bezüglich LOD Target sahen anders aus.

Dazu konnte man einiges in diesem anderen Thread lesen. Ich habe später noch anderes ausprobiert speziell auch zu den 3D Wolken die keine sind. Alles ohne nachweisbare Funktion des LOD Target.

Naja, kurios ist da eigentlich nix. Außer dass ich mich nicht exakt ausgedrückt habe. Die Blurries erscheinen nicht nur da, wo ich eh nur 20 Bilder pro Sekunde bekomme, aber da fällts besonders auf. Es passiert auch anderswo.

Klar ist jeden falls eins: Es steht bei einer Reduzierung der Max Framerate mehr Leistung für die Schönheit zur Verfügung (mal abgesehen davon dass ich weniger "auffällige Ruckler" bekomme). Die Begrenzung tut damit genau was sie soll.

Ich glaube das ist für die allerallermeisten hier selbstverständlich, dass man nicht Äpfel mit Birnen vergleicht. Ich schätze deine Antworten sehr, dennoch: Unterschätze nie den "normalen" Anwender. Auch der ist nicht immer aus Dummsdorf.

Eine "spezielle Testszenerie" braucht man auch nur für ganze spezielle Zwecke... wenn man z.B. verschiedene Implementierungsmethoden testen möchte u.ä.

Hallo Joachim,

die von Dir gepostete Messkurve find ich so frappierend, dass ich mich frage, ob du anhand dieser nicht zu weitergehenden Empfehlungen kommen kannst. Das erscheint mir doch eine lösbare Rechensumme: wie schnell kann ich maximal in einer Photoscenery fliegen bei einer bestimmten Framerate, ohne dass die Texturen unscharf werden? Du hast ja sehr viel experimentiert, und hast wahrscheinlich eine genaue Vorstellung davon, wieviele Texturkacheln bei einer bestimmten Radius-Einstellung im höchsten MIP-Level zu sehen sind.
Dass Problem ist in der Praxis doch vor allem, dass wenn ich wie Steven Lacey empfiehlt die Framerate vorgebe, ich langsamer bin dann ich sein koennte. Auf meinem alten XP1800+ erreiche ich z.B. bei Switzerland Pro am Bodem etwa 40fps, waehrend im Fluge 50-60fps moeglich waeren. Setze ich die Framerate also auf 40, verspiele ich Leistungspotentiale, setzte ich sie dagegen auf 60fps, gelingt das Nachladen nicht immer gut. Wenn ich jetzt wuesste, wie schnell ich bei gegebener Framerate (und Radiuseinstellungen) fliegen koennte, koennte ich (möglicherweise sehr ernüchtert) mich dann für das eine oder andere entscheiden.

Gruesse,

Thomas

Nun zunächst etwas zu diesen Blogs der Microsoft Entwickler die Horst verständlicher Weise auch immer gerne setzt.


Es ist natürlich prinzipiell eine schöne Sache.

Für mich persönlich ist es allerdings eine ganz dumme Geschichte.

Jahrelang hat man von offizieller Seite eigentlich bezüglich Parameter im FS nur das bekommen, was in den offiziellen Hilfetexten steht.

Das ist zum Teil nicht sehr aussagekräftig und lenkt des öfteren sogar ganz von deren eigentlichen Funktionen ab.

Von den speziellen Parametern die nicht über das FS Menü selbst gesteuert wurden gab es überhaupt keine offiziellen Informationen.

Was es gab, waren private Erklärungen bzw. Einstell Empfehlungen die erkennen liessen, dass der oder die Tippgeber oftmals überhaupt nicht das Wissen besitzen, wie die Parameter arbeiten.


Irgendwann im Zuge meiner LC Dok bin ich dann wegen anderer Meshproblemgeschichten auf die Idee gekommen, dass man diverse Parameter der FS9.CFG mit aufnehmen kann. Diese für den Anwender einleuchtend erklärt weiterhin Beweismaterial mitliefert welches eindeutig demonstriert was dort genau wie abläuft.


Zum Teil mit speziellen Testscenerien, dass es jeder auf seinem eigenen PC nachvollziehen kann.

Leider ärgere ich mich aus heutiger Sicht, dass ich nicht vor zwei Jahren begonnen habe, die Doku in Teilen zu veröffentlichen die so gut wie komplett abgeschlossen waren.

Anstatt dessen habe ich mich immer weiter verstrickt und neue Sachen mit aufgenommen, ohne die alten zunächst auf einem Niveau abzuschliessen welches man veröffentlichen konnte.




Tja und irgendwann kamen auf einmal diese Blogs der Entwickler. Auf einmal wurde locker über FS Interna gequatscht wie diverse Sachen im FS ablaufen.

Alles Sachen bei denen ich die genaue Funktion erst ermitteln musste bzw. an deren Beweismöglichkeit (Testscenerien, Verfahren, Ideen usw.) ich mehrere hundert Stunden oder mehr gearbeitet habe.

Zum Teil ist diese Arbeit aus meiner Sicht jetzt verpufft.

Was mir bleibt, ist das ich natürlich auf sehr vieles verweisen kann, was ich damals schon angedeutet habe. Auch einige Screenshots der Doku die ich selten mal in einem Thread eingeblendet habe zeigen das.

Das hat auch Horst erkannt siehe z.B diesen Thread

unter

Links

http://www.wcm.at/forum/showthread.p...blog+AND+jobia

Das wird man dann auch noch an anderen Dokustellen wiedersehen können. Ich denke trotz Blogs wird doch noch einiges überbleiben was man an Information wo anders noch nicht gesehen hat.

Die bekannten Blogs sind nur Texte, bei mir wird man auch noch sehen, warum das ein oder andere damals so realisiert werden musste.


Irgendwann hatte ich ein Stadium erreicht wo aus meiner Sicht eine Teilveröffentlichung nicht mehr sinnvoll erschien.


Der ein oder andere wird fragen ja wo bleibt denn das Ding.

Durch die Geburt unserer zweiten Tochter vor 6 Monaten habe ich so gut wie keine Zeit mehr für den FS.

Mag aufgrund meiner Forenbeiträge komisch klingen, ist aber so. Vieles schreibe ich in meiner Frühstücks oder Mittagspause als Reaktion auf Forenbeiträge vor.

Was die Doku betrifft, da benötige ich aber fast immer den FS. Das geht nur zu Hause, wo mir jetzt die damals noch vorhandene Zeit fehlt.

Von daher lief in Bezug Doku in den letzen 6 Monaten nicht mehr viel.

Jetzt habe ich momentan Urlaub. Da geht auch nichts, außer hin und wieder mal ins Forum schauen.

Das nur dazu, weil ich denke da gibt es einige die bestimmt sagen,der Spinner, da sollte doch eigentlich schon längst etwas vorliegen.

Der ein oder andere dem ich per Mail oder hier im Forum bei Problemen weitergeholfen hatte, wird auch erkennen wo diverse Zeit verpufft ist.

Denn das stand bei mir immer vor der Doku.

Wie gesagt man wird einige der Beweisbilder die ich zum Teil vor zwei Jahren bei bestimmten technischen Zusammenhängen schon gepostet hatte aber in der Doku wieder erkennen. Mit der Doku irgendwann dann auch die damals für den ein oder anderen noch nicht ganz klaren Zusammenhänge.



Auf die jetzige Frage von Thomas möchte ich nicht direkt antworten, weil es schlicht und ergreifend nicht so einfach zu beantworten ist.

Man kann speziell bei einer Fotoscenery wenn man die eingestellten FS9.CFG Parameter des Anwender kennt eine Aussage machen bei welcher Fluggeschwindigkeit wieviel Texturinformationen pro Sekunde geladen werden müssen um scharfe Scenery zu haben.


Jetzt kommen dann aber weitere Unwägbarkeiten dazu wie andere Addons andere Sceneryelemente, andere Prozesse, PC Performance und noch vieles mehr, so dass die Belastungen auch nicht konstant sind. Von daher ist es nahezu unmöglich hier eine eindeutige Aussage zu treffen, z.B Du musst generell jetzt 50 oder z.B 60 Frames einstellen.


Es wird mit der Doku aber Information geliefert, die hilft die technischen Aspekte im FS zu verstehen.

Hat man die verstanden, dann denke ich kann man seinen FS auf die eigenen Belange sinnvoller einstellen.

Es sind wie gesagt auch Testscenerien vorhanden mit denen man z.B auch bei einer Fotoscenery im europäischen Raum stabile Aussagen machen kann welche MIP Level wo aktiv sind. Die Belastung der Fotoscenery selbst bleibt dabei erhalten.

Nur wann ich damit endlich fertig bin möchte ich nicht mehr sagen. Einige Punkte wollte ich für mich persönlich noch klären, weiterhin bin ich etwas hin und hergerissen. Momentan ist die Doku nur in HTML.

PDF oder Word wäre ev. praktikabler, falls mal jemand etwas ausdrucken möchte.

Einen PDF Editor werde ich mir aber nicht kaufen.

Es kommt ev. eine Konvertierung mit Freeware Konvertern in Frage. Da die Doku aber auch Links zu anderen HTML Dateien in anderen Pfaden der Doku setzt, weis ich noch nicht wie ich das intern in einer PDF überhaupt realisieren kann.

Vermutlich müsste alles umstrukturiert werden um dann mit so einer Art Textmarken innrehalb einer einzelnen PDF zu arbeiten.

Ev. hat da ja von euch einer eine Idee wie man die HTML Geschichte ohne weitere Kosten sinnvoll in PDF bekommt, bzw. ob man auch innerhalb einer PDF andere aufrufen kann, wobei jederzeit ein Rücksprung in die Stamm PDF möglich sein sollte.

In der HTML geht so etwas sehr schön.


Mit Beendigung der Doku werde ich mich wohl auch aus der FS Szene zurückziehen, da ich nicht mehr so die richtige Lust verspüre.

Aber wer weis eine Meinung kann sich ja so schnell ändern.

Auf jeden Fall werde ich nicht den sterbenden Schwan machen.

Hallo Joachim,

ich kann mir gut vorstellen das du frustiert bist, auch ich habe schon jahrelang an Sachen gearbeitet die recht schnell in den Mülleimer der Geschichte gelangt sind. Was mich allerdings schon wundert, ist dass du dir scheinbar deines Impacts auf die Flusiszene nicht so recht bewust bist. Und dann denke ich nicht nur an all die konkreten Problemlösungen und Patches von deiner Hand. Und ehrlich gesagt denke ich dass dir deine Doku aus den Händen gerissen wird, egal ob HTML, Doc oder PDF. Ich würde mich jedenfalls freuen, meine obige Fragestellung anhand deiner Erkenntnisse etwas genauer zu untersuchen - natürlich ist es kein triviales Problem, aber ich bin mir ziehmlich sicher das in deiner Doku genug steht um etwas rationaler an diese Frage heranzugehen. Meinen Respekt hast du jedenfalls.

Grüsse,

Thomas