besseres Erscheinungsbild der Bodentexturen im FS2002
 

In letzter Zeit häufen sich bei mir Anfragen von Usern die meine Tipps zur optimalen schärferen Bodentexturdarstellung im FS2002 bei Ihren NVIDIA Grafikarten genutzt haben. Mittlerweile sind viele auf ATI Radeon Karten bzw. auf neue PCs mit Radeons umgestiegen und können das positive Erscheinungsbild der Nvidia Karten einfach nicht mehr erreichen.
Ich hatte auf Anfrage schon mal was im Hardwareforum dazu geschrieben. Aufgrund der Nachfragen in letzter Zeit habe ich ist es in Kurzform auch in dem damaligen Beitrag aufgenommen. Wer das noch nicht kennt die komplette Info gibt es hier. www.jobia.de

Für diejenigen die wissen was in der FS2002.CFG und den Grafikeinstellungen zu ändern ist, hier in Kurzform was bezüglich Radeon Grafikkarten zu beachten ist.

Das "Ansitropische Filtern" bei den Radeons lässt sich direkt unter den Windows 3D Einstellungen aktivieren. Das haben die meisten auch gemacht. Was bei den Radeon Karten aber ganz wichtig ist, dass niemals in den FS2002 Anzeigeeinstellungen zusätzlich das "Trilineare Filtern" aktiviert wird (bilinear ist erlaubt). Ein aktivieren der "Trilinearen Filterung" im FS2002 deaktiviert das "Ansitropische Filtern" der Grafikkarte, so das es wieder zu diffusen Bodentexturmatsch kommt.

Gruß Joachim

Hallo Joachim,

Deine Ausführungen habe ich aufmerksam gelesen, aber ich fahre "triliniares Filtern" im Flusi u. habe Hardwareseitig Anisitropisches Filter auf 16-fach und kann bei "Biliniares Filtern" keinen Unterschied erkennen.

Also kein defusen Texturmatsch, siehe Bild im Anhang.

Habe zudem meine FS 2002.cfg Einstellungen wie folgt verändert:

[TERRAIN]
TERRAIN_ERROR_FACTOR=3.850000
TERRAIN_MAX_VERTEX_LEVEL=20
TERRAIN_TEXTURE_SIZE_EXP=8
TERRAIN_AUTOGEN_DENSITY=5
TERRAIN_USE_GRADIENT_MAP=1
TERRAIN_EXTENDED_TEXTURES=1
TERRAIN_DEFAULT_RADIUS=60.000000
TERRAIN_EXTENDED_RADIUS=40.000000
TERRAIN_EXTENDED_LEVELS=4

Gruss

...Bild 2

...Bild 3

Wenn ich deine eingeblendete rote Schrift sehe deutet dieses aber auf die Verwendung einer NVIDIA Karte bei Dir hin, kann mich täuschen das Schriftbild sieht aber so aus, kann natürlich auch durch die Komprimierung der jpgs kommen. Bei Nvidia gab es auch kein Problem mit trilinearen Filtern und ansitropischen Filtern. Das oben erwähnte gilt speziel nur für Radeons.

Alle die mich angeschrieben haben, haben dieses Problem bei Radeons gehabt. Bei allen funktioniert es nur mit bilinear nicht aber die Kombination ansitropisch und trilinear. (Natürlich muss die Funktion Mip Level aktiviert sein, sonst hätte man eh keinen Texturmatsch, dafür aber an den Häusern flimmern).

Habe mal in deinem Profil nachgeschaut Du hast eine 9700. Im Notebook habe ich eine Mobility 9000. Die anderen hatten glaube ich auch kleinere Modelle. Vielleicht gibt es das Problem bei den besseren Modellen nicht.

Fakt ist diejenigen die mich angeschrieben haben, konnten das Problem so beseitigen.

Hallo Joachim,

da hast Du Recht, ich habe eine ATI Radeon 9700 Pro.
Aber wo Du das Problem mit dem Texturflimmern speziell bei Häusern anspríchst, daß ist bei mir in geringeren Flight-Levels schlechter, als vorher mit meiner Geforce4 Ti 4600

Was kann ich dagegen machen?

Wie findest Du subjektiv die Qualität meiner Bilder, würde mich sehr interessieren...! Könnte man da noch mit speziellen Einstellungen etwas verbessern?

Gruss

Muss ich mir noch mal genau anschauen. Bei komprimierten JPGs kann man das eh schlecht beurteilen. Ich habe auch das Problem, das ich momentan nur mit dem TFT des Notebooks arbeite. Da ist eine Beurteilung eh nicht so prall. Der Notebook ist zwar schnell aber kein High End Gerät daher ist das Bild eh nicht so gut. Muss jetzt leider weg vielleicht später dazu noch was.

Habe jetzt mal eine Datensicherung gemacht und die neusten Treiber aufgespielt. (ich bin da bei der Radeon gebrantes Kind. Wollte neulich bewusst eine schlechte Darstellung haben, so das man jedes einzelne Pixel der Bodentextur als Quadrat sehen kann, wenn man nah genug dran ist. War bei der Radeon einfach nicht hinzubekommen. Da hilft nur abschalten der 3D Unterstützung. Nur leider war der Menüpunkt zum aktivieren hinterher nicht mehr vorhanden, das war übel)

Auch mit neuesten Treibern geht bei mir die Kombination trilienear und ansitropisch nicht. Daher meine Vermutung. Es ist bekannt, das sich mit dieser Kombination theoretisch optisch das beste Bild erreichen lässt. Nur es ist auch das Performance fressende Verfahren. Sollte ATI ev. bei den einfacheren Radeon Chipsätzen diese Funktion einfach gesperrt haben um höhere Frames zu haben, ohne das der Kunde was merkt. Zutrauen würde ich denen das schon.

Beispiele für Kundenveräppelung gibt es viele auch in anderen Bereichen. Habe neulich einen Opel Zafira gekauft. Erstzul. 09.2002 , der erste Wechsel weg von VW. Ist heute mittlerweile eh egal die Teile kommen zum Teil eh aus dem Ausland von irgendwelchen geknechteten Zulieferern. Wo dann ev. kein Geld mehr für eine anständige Endkontrole überbleibt, so das die Fahrzeuge dann wie beim VW Touran aufgrund defekter Lüftersteuerung schon im Werk abbrennen.

Wie dem auch sei, eigentlich ein gutes Radio mit CD und 4 Ausgängen drin. Nur nach dem ich hinten gesessen habe, habe ich gemerkt hier hört sich doch was anders an, da fehlt doch was. Und so ist es auch aus dem Gitter für die Hochtöner hinten hört man nichts. Kaputt?

Bei Schwiegervater gleiches Modell 2 Jahre älter kommt da was. Taschenlampe her durch das Gitter geleuchtet, bei Schwiegervater prangt da ein Hochtöner. Bei mir nur dezenter Durchblick in die Leere. Was gibst sonst noch zu sehen, nichts als Blech. Bei Opel angerufen. Nach einem Tag das Ergebnis. Das tut uns Leid das hat Opel geändert. Es kommen jetzt hinten nur noch normale Lautsprecher zum Einsatz. Nur noch wenn sie ein Radio mit CD Wechsler haben gibt es das komplette System. Sie können sich das bei uns auf dem Microfilm anschauen es ist wirklich so. Nachrüsten hätte zur Folge, das hinten kompett gewechselt werden müsste, da die Frequenzweichen am Basslautsprecher sitzen. Die sind bei mir natürlich auch einfacher ausgeführt.

Ja so ist das heutzutage, da sitzt einer und überlegt sich was wie man sparen kann ohne das der Kunde was bemerkt.

Zurück zur Grafik. Ich habe leider kein Zugriff auf meinen Athlon mehr. Aber vom reinen Gefühl her würde ich sagen Du hast recht es bleibt ein minimales Restflimmern zurück, welches bei den Nvidias nicht war. So in der Art haben sich andere auch schon ausgedrückt. Eine Lösung dafür habe ich aber auch nicht, zumindest habe ich da nicht weiter gesucht. Ich war damals schon froh, das ich das mit dem trilinearen bei mir bemerkt habe. Das sah am Anfang grauselig aus.

Super Tipp das! In Verbindung mit dem 44.03 und meiner NvidiaFX ein traumhaftes Ergebnis, sowohl Framerates als auch Optik!

Ich kann aber an Stefans Terrain Einstellungen keine wesentlichen neuen (optische Verbesserungen auslösenden) Einstellungsveränderungen zu denen finden die ich damals im Sommer 2002 empfohlen hatte.

Bei TERRAIN_DEFAULT_RADIUS hatte ich 8,5 empfohlen, weil Werte darüber zwar zulässig sind aber optisch nichts mehr auslösen. TERRAIN_EXTENDED_LEVELS hatte ich mit 8 empfohlen da darüber sich auch nichts gross ändert. Hat man den TERRAIN_EXTENDED_LEVELS auf 8 stehen, bewirkt eine Änderung beim TERRAIN_DEFAULT_RADIUS noch weniger.

Sprich Stefan hat zwar andere Werte, optisch verändern sie aber nicht viel wenn überhaupt was zu meinen damaligen. Alle anderen oben stehenden Parameter sind übrigends keine direkten Geheimnisse bis auf den TERRAIN_MAX_VERTEX_LEVEL. Dieses sind Parameter die Ihr selbst im FS Menü einstellt. Sie werden entsprechend eurer Einträge im FS hier gesetzt. Allerdings in einer anderen Dimension. Der Wert TERRAIN_EXTENDED_TEXTURES ist z.B ein Schalter. Es ist nur 0 oder 1 zulässig. Dahinter verbirgt sich im FS Menü die Schaltfläche "Erweiterte Geländestrukturen". Also wieviele Bodentexturen der FS überhaupt lädt. Quasi aus der Vogelperspektive extreme Höhe z.B 30000Fuß die kreuzförmige Darstellung der Bodentexturen. Entweder viele oder wenige Texturen. Diesen Faktor hatte ich damals als Tipp bei Fotoscenerien empfohlen. Man muss halt nur die Sichtweite auf 30Meilen begrenzen, damit es nicht blöd aussieht, da man ausserhalb des Bereiches irgendein Standardweltmodell sieht, wo ich selbst nicht weis wo das abgelegt ist. Löscht man nämlich alle Bodentexturen bleibt dieses trotzdem erhalten.
TERRAIN_ERROR_FACTOR verbirgt sich z.B hinter dem Schieberegler Geländemusterkomplexität. Dieser ist meiner Meinung nach sowieso von MS falsch erklärt. So wie Ihn Microsoft beschrieben hat passt es eigentlich genau zu dem undokumentierten TERRAIN_MAX_VERTEX_LEVEL der nicht über das FS Menü erreicht werden kann. Der TERRAIN_
ERROR_FACTOR also die Geländemusterkomplexität stellt man am besten im FS Menü auf 70%. Dieser Faktor hat nämlich so gut wie keinerlei Auswirkung auf die Auflösung des gesamten Mesh so wie man das in der Hilfe interpretieren könnte, sondern mehr auf den Hintergrund also das Mesh in der Tiefe des Raumes. Unterhalb 70% erleidet man in der
Tiefe des Raumes also da wo das Gebirge weiter entfernt ist Auflösungsverluste im Mesh (wird auf niedrigen LOD Level geschaltet).Das Gebirge wird runder, die Performance geringfügig besser. 70% ist optimal, auch weiter hinten wird das Mesh sehr gut aufgelöst. Umso mehr man sich gen 100% bewegt umso rapider nimmt die FS Performance ab. Theoretisch wird jetzt auch das Mesh im Hintergrund besser aufgelöst, also optisch nehmen die Feinheiten im Gelände zu. Aber wie gesagt die Performance nimmt rapide ab. Dadurch wird aber je nach PC Performance ev. eure Frameratevorgabe in den Anzeigeeinstellungen bei weitem nicht erreicht. Dann kommt es dazu das der FS Details runterfährt und dadurch natürlich auch die Meshauflösung. Daher ist bei 100% das Erscheinungsbild sogar oftmals schlechter als bei 70%. Da habe ich neulich Bilder von gemacht, welche eigentlich für eine andere Doku in Bezug zu Meshqualitäten von ADDONS gedacht war. Der wesentliche Unterschied zu meiner FS2002.CFG Empfehlung bei Stefan ist der TERRAIN_MAX_VERTEX_LEVEL dieser steht bei ihm auf 20. Default ist 19.
15 bis 35 kann man einstellen, alles außerhalb wird automatisch zu 19 zurückgesetzt. Es ist kein linearer Wert. Mit diesem Faktor hatte ich damals als ich die Doku zum verbessern der Bodentexturen geschrieben habe schon rumgespielt und wusste das er Auswirkungen auf das Mesh hat nur nicht genau welche. Er war damals selbst in
ausländischen Designerkreisen relativ unbekannt. Bei einigen wenigen Scenecracks die sich damals schon mit Mesh beschäftigt haben muss er aber schon länger bekannt sein.
Hier kann man ihn bis Frühjahr 2002 zurückverfolgen. Ev. gab es ihn sogar schon beim FS2000. Mittlerweile Dank dem Tool Ground2K ist er relativ bekannt. Dieses ist der entscheidende Wert mit dem man an der Schraube des maximal darstellbaren Mesh im FS drehen kann. Ich hatte ja des öfteren drauf hingewiesen, das der FS Meshfiles besser
LOD9 also ca. alle 76m eine Höhenpunkt nicht darstellt auch wenn sie mit z.B LOD11 ca. alle 19m ein Höhenpunkt programmiert wurden. Mit diesem Faktor bekommt man auch höher aufgelöste Meshfiles angezeigt. Dieses wäre übrigends auch meine Globallösung für das Flackerproblem bei Taxiways gewesen. Bei meiner DOKU zu den eigentlichen Ursachen des Problemes sind sämtliche Screenshots mit TERRAIN_MAX_VERTEX_LEVEL=35 gemacht worden. Denn da kann man sehr schön die Ränder von LWM Flattenfiles sehen. Das Mesh stürzt
hier spektakulär steil ab. Das Flackerproblem ist übrigends mit dem Wert 23 offensichtlich behoben. Ich konnte es zumindest bei mir nicht mehr nachweisen.
Nur wie gesagt hat man dann als negative Ursache das Problem, das im Bereich von LWM Flatten, also bei Küsten und quasi auch bei allen Seen mit Höhenangabe diese je nachdem wie die das umliegende Mesh dazu passt ev. in einem extrem abstürzenden Tal liegen. Auch die remesh Funktion von Ground2K leidet darunter. Fehler in der Meshprogrammierung tauchen eher auf, so wie vor ca. 2 Monaten mein Screenshot von Süddeutschland wo bei einem Meshfile eine Art Welleneffekt erkennbar war. Hier hatte ich mit Faktor 21 gearbeitet um das gezeigte LOD11 Mesh überhaupt darstellen zu können. Daher kommt es als Globallösung bei den meisten auch nicht in Frage. Wie gesagt mit Faktor 19 bleiben Details eines LOD10 oder LOD11 Mesh auf der Strecke. Der Wert 21 sollte die absolute Obergrenze sein. 20 ist in jedem Fall OK. LOD10 wird so dargestellt. Also z.B das Lago
Mesh. Nur da nützt es wie gesagt nichts da es mit LOD11 oversampeld ist, die Rohdaten offensichtlich aber eine viel schlechtere Auflösung gehabt haben als z.B beim Austria Prof. Mesh. Optisch tut sich daher am Lago Mesh nichts.

Ende Teil1

Teil2

Der TERRAIN_MAX_VERTEX_LEVEL und der TERRAIN_ ERROR_FACTOR beinflussen sich gegenseitig. Hohe Werte bei TERRAIN_MAX_VERTEX_LEVEL haben zur Folge, das im Hintergrund die
Auflösung bei hoch aufgelösten Meshfiles je nach Performance des PC extrem im LOD Level runtergefahren werden. Gut sichtbar bei einem extremen Testmesh wie ich es hier in der Grösse eines popeligen LOD 13 Quadranten mit extrem wechselnden Höhensprüngen von 500m erzeugt habe. Der FS ist aufgrund der vielen Vertex Points nicht mehr in der Lage dieses im Hintergrund darzustellen. Dies sieht dann so aus. Im hinteren Bereich des LOD13 Quadranten ist das Mesh nur noch auf einer festen Höhe. Die Meshspitzen wie sie im Vordergrund sind werden nicht mehr dargestellt. Ein Wert der das Aussehen des Mesh extrem beeinflusst. Also nicht über 21 gehen.

[quote][i]Der wesentliche Unterschied zu meiner FS2002.CFG Empfehlung bei Stefan ist der TERRAIN_MAX_VERTEX_LEVEL dieser steht bei ihm auf 20. Default ist 19.

Der Wert "20" ist auf Empfehlung von PTSIM den Machern von Madeira 2003 entstanden, damit werden die Boden-Rasen Flächen auf LPMA sauberer dargestellt.

Gruss

Nun, das Thema ist für mich erst interessant geworden als ich meine neue Graka bekam - daher hatte ich auch noch die Standardeinstellungen. Verständlich dass der Effekt dadurch umso stärker war!

Wie gesagt der TERRAIN_MAX_VERTEX_LEVEL ist ein schlimmes Ding in positivem als auch negativem Sinne. Leider lassen sich alle ADD Ons oder sonstige Leute die halbwegs über die Sache bescheid wissen eigentlich nur über das Wissen von Richard Ludowise aus. Der Mann weis extrem viel, nur da kann manch einer nicht mithalten und dann bleibt etwas auf der Strecke. Deshalb findet man leider diesen Faktor oft nur in Verbindung zu LWM oder remesh also alles was mit Seen, Flüssen oder einebnen von Defaultairports usw. zu tun hat. Nur leider können die wenigsten damit etwas anfangen. Das Mesh wird leider immer vernachlässigt. Denn gerade hier gibt es noch erhebliche Verbesserungsmöglichhkeiten in Verbindung mit diesem Faktor. Ob ich mich da weit aus dem Fenster lehnen darf wird sich demnächst (können allerdings auch Monate werden) zeigen. Dank auf jeden Fall an Patrick Bernhard den Ersteller von Toposcan und auch Real Germany 1 der Fotoscenery. Sein Tool könnte die Basisgrundlage sein. Rechte sind zu klären. Ich werde auf jeden Fall kein externes Tool zur endgültigen Rohdatenerzeugung nutzen um die resample.exe zu füttern, denn da kann nichts gutes bei rauskommen, das habe ich schon bei Tests bemerkt.

Leider ist mir der vorige Text zu früh rausgerutscht. Er hätte eigentlich komplett so aussehen sollen. Man wird halt alt.
Hier der richtige Text.

Stefan an ich denke die Angabe 20 ist aufgrund Ground 2k entstanden, denn meine bisherige Korrespondez sieht danach aus, als wenn sich die meisten auf Richard seine Angaben stürzen was auch OK ist. Nur der Sachverhalt ist bisher nicht aufgenommen worden.
Wie gesagt der TERRAIN_MAX_VERTEX_LEVEL ist ein schlimmes Ding in positivem als auch negativem Sinne. Leider lassen sich alle ADD Ons oder sonstige Leute die halbwegs über die Sache bescheid wissen eigentlich nur über das Wissen von Richard Ludowise aus. Der Mann weis extrem viel, nur da kann manch einer nicht mithalten und dann bleibt etwas auf der Strecke. Deshalb findet man leider diesen Faktor oft nur in Verbindung zu LWM oder Remesh also alles was mit Seen, Flüssen oder einebnen von Defaultairports, Küsten usw. zu tun hat vor. Nur leider können die wenigsten damit etwas anfangen. Das Mesh wird leider immer vernachlässigt. Denn gerade hier gibt es noch erhebliche Verbesserungsmöglichhkeiten in Verbindung mit diesem Faktor. Ob ich mich da weit aus dem Fenster lehnen darf, wird sich demnächst (können allerdings auch Monate werden) zeigen. Dank auf jeden Fall an Patrick Bernhard den Ersteller von Toposcan und auch Real Germany 1 der Fotoscenery. Sein Tool könnte die Basisgrundlage für ein norddeutsches Mesh sein. Rechte sind zu klären. Ich werde auf jeden Fall kein externes Tool zur endgültigen Rohdatenerzeugung nutzen um die resample.exe zu füttern, denn da kann nichts gutes bei rauskommen, das habe ich schon bei den Vortests mit Experimentalmesh files bemerkt. Zum interpolieren ist die resample.exe tödlich. Wenn alles klar geht würde ich ein Mesh für den leider bisher vernachlässigten norddeutschen Raum anbieten. Nicht mit einer High End Auflösung sondern einer Auflösung die realitätsnah der man mag es nicht sagen, der Realität in angemessenen Rahmen entspricht. Also vermutlich nicht LOD 10 oder 11 sondern LOD9 bis ev. dem Harz. Hier könnte LOD10 Sinn machen. Mal sehen Niedersachsen, Bremen, Hamburg, Schleswig steht mir als Rohdaten zur Verfügung der Osten leider nicht. Wie gesagt das Mesh von Patrick und die 90% von Austria Prof. sind der Masstab, daran gilt es sich zu messen. Wenn jemand Beweise für die Qualitäten dieser beiden Mesh Files haben möchte, ich kann sie in Form von dekompilierten Graudatenbitmpas bzw. auch den vorliegenden Fehlern bei Austria Prof. jederzeit liefern, insofern meine Stichpunktmessungen nicht zufälliger Weise die positiven Stellen betonen sollten. Ein Beispiel Screenshot mit dem Unterschied Lago Mesh/Austria Prof. im Anhang. Links Lago Mesh, diffus schlechte Auflösung offensichtlich bereits der Rohdaten. Rechts, Austria Prof. Mesh nur die halbe Auflösung optisch aber wesentlich neutraler auch im Vergleich zu Messungen anhand der realen Topografie. Aber nicht das jetzt jemand den Screenshot extrem vergrößert es handelt sich um eine stark komprimierte JPG Datei bei der man die Auflösung eh nicht sehen kann, das Problem aber schon. Ein spezielles Landclassfile(welches bei mir erhältlich ist) inkl. Texturen bei aktivierter T&L Einheit kann bei jedem das Ergebnis beweisen, so dass es jeder selbst bei sich im FS beurteilen kann. Wie gesagt Lob an Patrick und an das Austria Prof.Team. Der Beweis kann auch anhand der realen TOP 50 Karten und FSUIPC Auswertung für jedermann erbracht werden. Das Wissen dazu gebe ich gerne weiter. Aber ich denke da sollte man sich beim FS2004 Gedanken machen, denn hier beginnt die Zeitrechnung von neuem.
Viel was neues wird wohl bis dahin nicht kommen.



Hier das Foto links Lago, rechts Austria Prof. Mesh


Gruß Joachim

Da wir in zwei anderen Threads ja das Thema FSUIPC und das diese zukünftig nicht mehr kostenlos sein wird zum Thema hatten, hier mal als Demo wie ich über FSUIPC ein Meshfile hinsichtlich Genauigkeit der umgesetzten Höhen anhand der Realität beurteilen kann. Denn viele sehen immer nur die FSUIPC als ein Tool welches irgendwo im
Hintergrund läuft, und vielleicht mal ein paar Daten liefert oder in den FS schickt. Allenfalls noch ein paar Joystickoptimierungen und ein bischen auf das Wetter Einfluss nehmen kann. Dem ist aber nicht so, es werden ca. 600 Werte über FSUIPC aus dem FS ausgelesen. Bei 300 hatte ich keine Lust mehr zu zählen, aber der Scrollbalken war ca. auf der Hälfte des Bereiches. Das was ich beim Mesh vorher anhand der Graubitmaps gezeigt hatte, stellt eigentlich nur eine optische Übersicht über das Mesh dar. Es sagt noch nichts über die Höhengenauigkeit aus. Als Masstab nutze ich wie gesagt die TOP50CD Serie mit digitalen topografischen Karten. Diese sind eigentlich das genaueste was man so zu halbwegs akzeptablen Preisen ca.50 Euro für ein Bundesland (Ausnahme Bayern dieses besteht aus zwei CDs) erhalten kann. Die aktuellsten Versionen Nummer3 enthalten auch ein hochgenaues digitales Höhenmodell. Im Anhang ein Screenshot mit dem Messverfahren. Hätte ich die Version 3 für Baden Württemberg könnte man im linken Bereich unten im TOP50 Fenster (beim braunen Pfeil) bei ALTm eine Höhenangabe sehen, dann wäre alles noch einfacher gewesen. Da meine Baden Würtemberg aber Version2 ist steht hier nichts. Daher habe ich bei meinen Versionen3 die Höhenlinien in den topografischen CDS mit dem hinterlegten digitalen Höhenmodell verglichen. Fazit die Höhenlinien haben null Fehler. Aus diesem Grund habe ich mich zum testen im Bereich Baden Württemberg bzw. Bayern als ich das Lago Mesh und Austria Prof. getestet habe, immer direkt auf diese Höhenlinien positioniert. Soll heissen die Maus wurde genau auf eine Höhenlinie positioniert. Die entsprechenden Koordinaten wo der Mauszeiger steht sieht man im TOP50 Fenster unten in der Statusleiste (der blaue und der schwarze Pfeil). Neben das TOP50 Fenster wurde das FS2002 Fenster positioniert. Sicht Vogelperspektive. Da der FS selbst keine 100%tige Höhenangabe herausgibt (Das Flugzeug müsste immer auf den Boden abgesenkt werden, zusätzlich müsste die Referenzhöhe des jeweiligen Flugzeuges herausgerechnet werden)kann dieses keine Lösung sein. Misst man über das Barometer müsste zusätzlich der Luftdruck als Fehler eliminiert werden.

Der FS zeigt standardmäßig das Koordinatenformat Grad:Minute an. Man kann über die FS2002.CFG auch auf Grad:Minute:Sekunde umstellen, meines Wissens aber nicht direkt auf Dezimalgrad. Dieses ist aber bei Mesh das verwendete Koordinatensystem. Eigentlich generell beim Scenerydesign. Wenn irgendwo etwas anders angegeben wird, wird es in der eigentlichen kompilierten BGL wieder in Dezimalgrad angegeben. Um also an die genauen Angaben aus dem FS zu kommen, habe ich die FSUIPC genutzt. Auch um die Bugs beim Flackerproblem bei den Airports auszumessen. Im FSUIPC SDK gibt es das Tool FS Interrogate über dieses kann man an die Daten die FSUIPC aus dem FS ausliest herankommen. Das FS Interrogate Fenster ist unten links. Zu den ausgelesen Bytes muss man z.T noch eine Formel eingeben, damit z.B die Höhe direkt in Metern angezeigt wird. Das habe ich gemacht. Was passiert nun. Über den Screwmodus fahre ich das Flugzeug direkt an die Koordinate bei der ich bei der TOP50CD die Höhe ermittelt habe. FS Interrogate macht diese Veränderung des Flugzeuges natürlich mit. Man sieht auch anhand des blauen und schwarzen Pfeiles das die Koordinaten von FS Interrogate und TOP50 identisch sind. Weiterhin meldet mir FS Interrogate direkt die aus dem FS an dieser Position ausgelesene Bodenhöhe.

In diesem Falle 725,01563m im FS. Bei Top50 werden hier genau 720m gemessen. Das Mesh hat also an dieser Stelle einen Höhenfehler von ca 5m. Der Screnshot hier ist nicht aus dem Lago bzw. dem Austria Prof Mesh. Wie gesagt beim Austria Prof. Mesh waren die Fehler bis auf die fehlerhaften ca 10% Fläche eigentlich immer kleiner ca 10m. Ein hervoragender Wert bei gebirgigem Gelände und einer Auflösung von LOD9 also ca. alle 76m ein Höhenpunkt. Beim Lagomesh mit LOD10 und einer Auflösung von ca. 38m also doppelt so viele Höhenpunkte wie bei Austria Prof. (welche wie gesagt im FS ohne Manipulation eh nicht zur Anzeige kommen) lagen die Fehler (auch mit Manipulation so das alles an programmierten Höhendaten angezeigt wird) in Bereichen über die ich mich lieber nicht äussere.

Es ist halt einfach so.


Das auch noch mal zum Thema Nutzen der FSUIPC wobei ich hier nur 3 von ca. 600 Werten genutzt habe. FSUIPC überdeckt ja quasi alles im FS von Scenery, Wetter usw. bis zum Flugzeug.

Hallo Joachim (JOBIA)!

Ich lege mich hier mal ganz offen fest: Wenn du an einem Mesh für den norddeutschen Raum mitarbeitest, dann kaufe ich es auch!

Ich denke, alle, die sich die Mühe machen, deine rekordverdächtig langen Beiträge zu lesen, wissen deine Bemühungen um ein besseres Verständnis der FS2002-Szenerieengine zu schätzen. Mich hat selbst sehr überrascht, wie viel da noch im argen liegt.

Alles Gute, Felix

Hallo Joachim (jobia; ich hoffe, Du liest das),

ich habe bei meiner Grafikkarte Radeon 9600TX die von Dir angegebenen Einstelltips
durchgeführt (einschl.des Nichtaktivierens des trilinearen Filterns und mit 16facher aniso-
tropischer Filterung) und habe ein "eigenartiges" Ergebnis erzielt:

Bei einem Testflug über Belgien, Holland und England erzielte ich die versprochenen
sehr zufriedenstellenden Ergebnisse, beim Einfliegen über deutsches Gebiet (Lüttich
Richtung Frankfurt) jedoch wurden nach und nach (ab ca.Mendig) die geladenen Texturen
(vor allem in der senkrechten Sicht nach unten) immer unschärfer und schärfere wurden auch nicht nachgeladen.
Dazu muß ich sagen, daß ich in Deutschland die fm_allemagne mesh installiert habe, in
den anderen genannten Ländern jedoch nichts dergleichen.

Könnte dieser Effekt daran liegen?

Auch die Ladezeiten für eine Szenerie aus dem Menü heraus stiegen ins unendliche.

Jedenfalls habe ich daraufhin alle Einstellungen unverändert gelassen- bis auf "Mip
Mapping".
Das habe ich abgeschaltet.
Und siehe da - die Texturen blieben auch über Deutschland verhältnismäßig scharf (die
verbliebene Unschärfe lag wohl an der Flughöhe von ca. 30000 ft); nur die Nachladezeit
der schärferen Texturen erhöhte sich zunehmend mit zunehmender Flugzeit, aber
dagegen kann man wohl leider nichts machen.
Und der Texturenmatsch in größerer Entfernung blieb mir auch weiterhin erspart und das
durch deaktiviertes Mip Mapping entstehende Flimmern der autogenen Texturen hat ein
nur sehr geringes Ausmaß.
Des weiteren gingen auch die Ladezeiten aus dem Menü heraus wieder auf normale
Werte zurück.

Sind das jetzt für mich die richtigen Einstellungen oder gibt es noch Verbesserungs-
möglichkeiten ?
Liegen die unscharfen Texturen wirklich an einer "Inkompatibilität" des hochauflösenden
mesh mit der Mip Zuordnung?

Danke für die Antworten,

Norbert

Eigentlich dürfte das aktivierte Mip Mapping nicht solche Auswirkungen (sprich das immer unschärfer werden der Texturen haben). Das sie ohne Mip Mapping beim FS2002 generell schärfer bleiben ist klar. Dafür flimmern sie in der Regel sehr stark. Das Problem ist natürlich das sich die Karten und Treiber immer mehr weiter entwickeln und sich daher das Erscheinungsbild sehr stark verändert.

Siehe z.B auch Nvidia 5600 beim FS2004 (schwarze Panels, das habe ich jetzt schon öfter gelesen. Wobei dieses mit Sicherheit nicht die offizielle Version war, sondern die von Kumpel E.Mule aus den Staaten wie es Marc so schön umschrieben hat)

Ich habe natürlich keinen Zugriff auf alle Karten, da im Bekanntenkreis momentan verstärkt noch NVIDIA im Einsatz ist. Ich nutze wie gesagt nur noch meinen Notebook der hat eine Mobility Radeon 9000. Nicht der Weisheit letzter Schluss, aber was soll man machen in einem Notebook. Ich kann daher unmöglich sagen wie es sich bei jedem verhält bei der Radeon Generation. Bisher hat es bei denen die mich über E-Mail angesprochen haben ganz gut geklappt bei Ihren verschiedenen Radeons. Sicherlich belastet ein gutes Mesh den PC mehr. Dann kann es schon sein, dass hier nicht mehr der höchste Mip Level geladen wird.

Wobei eigentlich die Mip Level Funktion dafür keine Schuld tragen dürfte. Meiner Meinung nach ist diese sowieso im FS2002 falsch ausgewiesen bzw. programmiert. Beim FS2004 soll sie vom Verhalten jetzt logisch sein. Sprich der Schieberegler soll je nach Stellung nur minderwertige Texturen mit wenig Pixeln bis zu der Maximalauflösung von 256x256 Pixel steuern bzw. begrenzen. Hoffentlich ist es bald soweit mit dem FS2004.

Danke für Deine Antwort, auch wenn Sie (kein Vorwurf) keine Erklärung
für mein eigenartiges Phänomen aufweist.
Anscheinend gibt es doch immer wieder "ungeklärte Rätsel".
Ich werde halt erst einmal bei meinen neuen Einstellungen bleiben und
hoffen, daß sie weiter so funktionieren.

Gruß, Norbert

Wo ich gerade dabei bin, Joachim...

Bei einem gestrigen Flug über Eifel und Ardennen (beides mit der
hochauflösenden mesh von N.Faitmain und Deinen Textur-Einstellungs-
tips) stellte ich zwei Dinge fest:

Erstens war das ganze ein optischer Genuß, aber zweitens geht dann
selbst bei meiner guten Grafikkarte Radeon 9600TX die framerate ganz
schön herunter (denn ich filtere ja auch noch 16fach anisotropisch).

Deshalb meine Frage:

Kannst Du mit Deiner "Kenne" mir und anderen die Deines Erachtens
optimalen FS-Grafik-Einstellungen nennen, denn bekanntermaßen ist
ja nicht überall die Reglereinstellung "voll rechts" sinnvoll.

Danke,

Norbert

P.S.: Die Frage geht natürlich auch an andere, die sich da genausogut
auskennen, wie "jobia"....

Hallo Norbert,

nach deinem Profil fliegst du noch mit einem PII 350 MHz, das wäre reichlich wenig. Aber auch bei besserer Ausstattung schalte den Flusi mal auf Pause(am Flughafen) und stelle die Auflösung hoch und runter bis du siehst wo die max FPS erreicht werden. Dieses ist dann was die CPU leisten kann und alle weiteren Grafikverfeinerungen zur Auflösung und Antialiasing muss die Grafikkarte leisten.

Grundsätzliche Gedanken zu den Flusi-Einstellungen findest du hier:
http://www.wcm.at/vb2/showthread.php?s=&postid=835369

Wobei aber deine Grafikkarte mit der 32Bit Farbdarstellung keine Verschlechterung der FPS zeigen sollte.

Edit:
Damit der Test aber auch richtige Werte anzeigt solltest du die FS2002.cfg ändern

[GRAPHICS]
...
LOD_TARGET_FPS=10 // Untergrenze für FPS individuell festlegbar

[DISPLAY]
...
UPPER_FRAMERATE_LIMIT=0

Der zweite Eintrag bewirkt das der Flusi die FPS so schnell darstellt wie Resourcen frei sind und erst bei 10 FPS anfängt die Grafik runter zu schrauben.

Weiterhin sollte man für optimale Texturendarstellung diese Werte von www.Jobia.de (dort ist eine ausführliche Erklärung) übernehmen:

[TERRAIN]
...
TERRAIN_DEFAULT_RADIUS=8.500000 // Orginal 2.5
TERRAIN_EXTENDED_RADIUS=4.000000
TERRAIN_EXTENDED_LEVELS=8 // Orginal 1


Gruß Heinz

hi heinz,

das profil ist leider nicht mehr aktuell!

ich ab aber die erfahrung gemacht, das auch die radeon 9xxx karten mit 16x anisotropischer filterung überfordert sind. ich würde den wert auf 8x heruntersetzen, die optischen verluste sind ignorierbar, der fps gewinn aber zu merken.

ausserdem sollte man daran denken, den fs im vollbild in der gleichen auflösung laufen zu lassen wie den win-desktop, das spart rechenzeit.

Sorry, mein Profil war nicht mehr aktuell.
Danke aber erst mal für die Tips.....

Norbert

P.S.: Hallo Börries; ist das nur eine Vermutung mit dem geringen
Qualitäts- aber hohen framerate-Unterschied zwischen 8facher und
16facher anisotropischer Filterung oder hast Du das selber schon
ausprobiert ?

selber probiert, mit ner getweakten radeon 9500

Das mit den ansitropischen Filtern kann ich bestätigen 8fach ist schonender. Anti Alias ist auch ein Framekiller. Da ich beim Notebook mit 1400 x 1050 Auflösung arbeite brauch ich dieses eh nicht. Es gibt kaum gezackte Kanten zu sehen. Ev. solltes Du daher dieses in Betracht ziehen. Dann habe ich die Bodenscenerieschatten generell abgeschaltet, sieht meist eh doof aus. Was auch ganz wichtig ist in Bezug zu Mesh und Performance stelle die Geländemusterkomplexität nie über 75%. Ich habe diverse Tests mit verschiedenen Meshauflösungen gemacht. (siehe unter anderem auch den Meshbeitrag mit Screenshot von mir heute morgen in diesem Forum) Geht man über 75% hat dieses nie Vorteile gehabt. Es wurde im Vordergrund nicht besser. Ich konnte im Überlagerungsverfahren der Screenshots mit verschiedenen Einstellungen der Geländemusterkomplexität keine Verbesserung im Vordergrund im Mesh feststellen, dafür in der Tiefe des Raumes gravierende Meshverluste aufgrund dessen das der FS hier die Auflösung runterfahren musste.

Dann ev. die Wolkendichte auf 75%.

Bei Bedarf halt die Erweiterten Geländestrukturen abschalten. Dann muß der FS flächenmäßig nur noch ein Viertel der Bodentexturen verwalten. Jetzt sollte man aber die Sichtweite bis in die Flughöhen die man fliegen möchte auf 30 Milen begrenzen.

Die Funktion maximale Sichtweite habe ich eh schon immer auf 60 Milen begrenzt gehabt. (Bedeutet stelle ich im Wettermenü unendlich ein komme ich nie über 60, das ist für mich auch OK)

Mit diesen Einstellungen und denen die andere hier schon erwähnt haben läuft es bei mir ganz gut. Der Rest den ich hier nicht erwähne steht bei mir ganz rechts.

Man könnte noch den AI Traffic runterregeln je nachdem was man vorhat.

Sollte man FSScene nutzen würde ich eine Wandlung ins DXT1 Format empfehlen, da diese ursprünglich nur als 8 Bit rausgebracht wurden. Ich kann mich nicht mehr dran erinnern ich meine es fehlten sogar die Mip Level. Dann muss der FS bzw. die Grafikkarte auch noch Zeit für deren Berechnung verschwenden. (Das er dieses tut habe ich damals bei Texturversuchen festgestellt)

Joachim,
alles, was recht ist - das kann ich nicht bestätigen. Ich habe deutliche Unterschiede gesehen - zumindest bei APro. Da gibts in mittlerer bis weiter Entfernung (den Vordergrund sieht man eh' nicht, wenn man fliegt - und ich fliege immer noch, anstatt Meshs zu vermessen ;) )plötzlich mehr 'Kanten' und 'Spitzen', d.h. das ganze ist weniger 'abgeschliffen'. Aber der PerformanceNachteil ist so groß, dass sich das wirklich nicht lohnt. Von daher hast du wieder recht :)

HansJürgen

Danke, Joachim, das war genau das, was ich gemeint habe und damit die
Antwort, die ich erwartet habe.

Börries, ich habe das mit den verschiedenen Stufen bei der aniso-
tropischen Filterung ausprobiert und kann das von Euch gesagte
bestätigen; sie bleibt jetzt bei 8fach.
Mip Mapping bleibt ausgeschaltet (ist offensichtlich ein performance-
Fresser) und anti-aliasing hatte ich schon immer "Off".
Das ganze habe ich gestern zusammen mit den jobia-FS2002.cfg-Tips und
den Faitmain meshes (allemagne/austria + italie) über den Alpen aus-
probiert und kann nur sagen - der Hammer !
Und das dank nur 8facher anisotropischer Filterung bei mehr als akzep-
tablen Framerates (selbst bei überflogenen Zusatzszenerien).
Bezüglich meines statements weiter oben habe ich festgestellt, daß
die völlig unscharfen Texturen im senkrechten downview entweder etwas
mit der Flughöhe zu tun haben oder mit der landclass (von F.Barth) und
weniger mit Mip Mapping; denn das Problem entsteht nur in Flughöhen
über 25000ft bzw. über Gegenden mit dieser landclass.
Frag mich aber keiner warum....

Danke für die Hilfen und Tips,

Norbert

Hallo Hans Jürgen

Mit welchem Wert hast Du denn getestet?

Aber wie Du schreibst ging es stark auf die Performance, das ist schon mal negativ. Zusätzlich gehe ich auch ganz stark davon

aus, dass das Mesh in weiterer Ferne negativ bei Dir beeinflusst wurde. Ich muss mal schauen ich habe irgendwo Screenshots

von den damaligen Tests gemacht (waren für die Meshdoku vorgesehen). Ich meine die waren auch mit dem ATP Mesh gemacht. Man

konnte auf jeden Fall bei mir erkennen das bei 100% ein Verlust von Meshinformation in der Tiefe des Raumes aufgetreten ist.

Im vorderen bis mittleren Bereich war kein Unterschied erkennbar. Optimal was der Verhalten wie gesagt bei 75% bis 80% soll

heissen gute Performance und optimale Meshdarstellung ohne große Verluste. Ich habe die Tests einmal während des Fluges

gemacht und zusätzlich statisch, also so wie in einem der vorigen Postings beschrieben mit Überlagerung der Screenshots um

nicht irgendwelchen Trugschlüssen zu unterliegen. Denn wer kann sich das während des Fluges alles im Kopf behalten.
Man muß nämlich eines noch erwähnen, befinden sich mehrere Meshpoints nahezu auf einer Höhe oder in Linie zu anderen scheint

dieses den FS weniger zu belasten. Er muß diese Information zwar verwalten die Grafikengine bzw. die Grafikarte scheint

dieses aber beim berechnen unter den Tisch fallen zu lassen. Ich konnte bei meinen Testfiles bemerken, das bei gleicher

Fläche und LOD Level des Mesh (gleiche Anzahl von Meshpoints pro Fläche) ein Mesh mit starken Höhendifferenzen zwischen den

einzelnen Meshpoints den FS wesentlich stärker belastet als bei geringfügigen oder gar keinen Abweichungen zwischen

Meshpoints. Man kann also getrost sagen das alles eine dynamische Sache ist und generell stark vom Gelände abhängt.

Vielleicht sollten die jenigen die Performanceprobleme haben mal nach oben erwähnten Verfahren an die Sache rangehen um das

beste Ergebniss für sich zu erreichen, also möglichst gute Optik. Nur wie gesagt ich persönlich habe mit 75% die besten

Erfahrungen. Auch kann ich sagen, dass bei dem Meshtest die Höhen bei 75% Ok waren.

Die Performance war bei mir übrigends auch bei Tests mit 100% in dem Bereich, dass man nicht sagen konnte der FS schaltet

jetzt aus Performancegründen was ab. Dieser erwähnte Einstellwert hat bei meinen künstlichen Testmeshfiles bei mir auch

ergeben, dass er meist stärkere Auswirkungen in der Tiefe des Raumes hatte. Mal sehen ob ich die Screenshots hier

veröffentlichen kann. (Ist immer so ein Problem mit den nur ca. 122KB als Anhang, wie gesagt auf die Homepage möchte ich

wegen so etwas nicht verlinken). Ev. könnte ich auch die Testmeshfiles liefern falls ich die noch habe, da könnte dann jeder

Testen wie die Auswirkungen bei Ihm sind.

So ich habe die Aufnahmen des Mesh mit den 4 verschiedenen Einstellungen der Geländemusterkomplexität im FS Menü auf meine Homepage gelegt und es hier verlinkt. Hat jetzt ca. 288KB aber anders hätte man nichts vernünftig erkennen können. Man kann zwischen 0%, 50%, 75% noch eindeutige Unterschiede erkennen. Akzeptabel ist es aber eigentlich schon mit 50% wenn es jemanden absolut an Performance mangelt. Es entspricht zwar nicht ganz der Realität dessen wie es programmiert wurde. Ich finde aber das Feeling von dem Gebirge kommt ausreichend gut rüber. Ein gut umgesetzes Mesh sieht mit diesen Einstellungen auf jeden Fall besser aus als ein schlechtes Mesh.
Fliegbar ist es mit 50% hinsichtlich Performance sehr gut. Bei 75% sieht alles sehr gut aus. Zwischen 75% und 100% finde ich muss man schon ganz schön suchen um hier Unterschiede zu finden. Daher habe ich mal rote Markierungsstriche gemacht die Unterschiede zeigen.

Hättet Ihr die Stellen auf Anhieb gefunden?

Ich denke man kann fast sagen das geht hier von der Optik 1 zu 1 aus. An manchen Stellen hat 100% Vorteile an anderen wieder 75%. Nur bei 75% ist es so das man wenn man auf die Stellen zufliegt weniger ein schalten in der Darstellung erkennen kann, also den Moment wenn der FS den LOD Level hier hochfährt und den Meshpoint auf den Wert setzt der programmiert wurde. Denn dieses geschieht in der Regel in weiter Ferne. Bei 100% passiert es wenn man näher dran ist, welches einem eher auffällt. Und was wichtig ist und Hans Jürgen gesagt hat, die Performance ist bei 75 bis 80% besser. Sicherlich mag dieses Verhalten je nach darzustellendem Gelände etwas schwanken. Mein Tipp bleibt aber 75%.

Hier das Bild.


http://jobia2.bei.t-online.de/bilder/gmuster.jpg

Hallo,

mal wieder ein SUUUPERTIP!! Endlich auch aus 30000 Fuß ein ordentliches Bild.

Danke Jobia:ja: :ja: :ja:

Ein:bier: für den Meister!!

Fritz

Nach mittlerweile so einigen Flügen mit den neuen Einstellungen kann
ich folgendes sagen:

Das Fehlen des früheren Texturenmatsches in größeren Entfernungen ist
eine einzige optische Wohltat und auch sonst sieht das ganze um
einiges besser aus.

Mit einem Problem:
Nach ca. 30 Minuten Flugzeit (vor allem in größeren Höhen)nimmt die
Nachladezeit für die schärferen Texturen zu.
Dies wird nach und nach immer schlimmer, bis irgendwann die unscharfen
Texturen bestehen bleiben, weil die Nachladezeit für die scharfen
gegen Unendlich läuft.
Dies läßt sich besonders in der senkrechten downview gut erkennen.

Ist das ein Problem des "zugemüllten" Arbeitsspeichers(immerhin 512KB)
oder der überlasteten Grafikkarte (immerhin 128MB) ?

Außerdem hat -zwar bei einem Framerate-Durchschnitts von über 20 trotz
Faitmain meshes und einiger anderer "Bonbons"- die "Ruckelhäufigkeit"
(d.h. die Fälle, bei denen die Framerate für Sekundenbruchteile auf
unter 6 heruntergeht oder der FS für 1-2 sec sogar komplett stehen-
bleibt) extrem zugenommen.

Was kann man gegen beides machen ?


Gruß, Norbert

Kann ich nicht bestätigen. Nicht schlimmer als vorher auch im FS2002.
Zumindest bei mir. Hängt aber auch mit den verwendeten ADDONS zusammen und in welche Richtung man fliegt, sprich was er laden muß wenn er in ein Gebiet einfliegt viele Objekte oder wenig.
Er ist ja bekannt dafür, dass er sich irgendwie zumüllt und langsamer wird.

Der FS2004 knabert übrigends mehr Speicher weg als der FS2002. 512MB sind schon ein Grenzfall unter XP. Da bleibt nicht viel übrig.

Um das Thema nochmal aufzugreifen:

Ich habe nach wie vor das Problem mit den im nahen und mittleren
Entfernungsbereich entweder extrem spät nachladenden oder sogar
unscharf bleibenden Texturen.

Dieser Effekt ist komischerweise mal stärker und mal schwächer
und zwar bei unveränderten "jobia"-Grafikkarten und cfg-Einstel-
lungen und unabhängig von den Lichtverhältnissen.

Das einzige, was festzustellen ist, ist, daß dieser Effekt in den
Bereichen mit besonders komplexer mesh zusammen mit der Landclass
von Frank Barth besonders extrem zu sein scheint.

Und genauso extrem nervt das dann, weil der ganze positive Effekt
der mesh, der landclass und er jobia-Grafikkarten-Einstellungen
damit "beim Teufel" ist !!!

Nun meine Frage: Kann es also wirklich sein, daß eine komplexe mesh
oder die Barth-landclass oder etwa die Kombination aus beidem diesen
Effekt verschlimmert und was kann man dagegen tun, ohne eins von
beidem oder gar beides zu deaktivieren ?

Oder bin ich der einzige, der diese Add-ons verwendet und diese
Beobachtungen gemacht hat ?

Gruß, Norbert

Zu den Barth Landclassfiles kann ich nichts direkt sagen da ich sie bestimmt nicht nutzen werde. Ich hatte schon was dazu geschrieben. Sie sind äußerst uneffizient programmiert, daher vermutlich auch deine Probleme.

Bei ihm findet man in ca. über 400 Files das vor was man problemlos in ein File bekommt. Unnützer Verwaltungs, Ladevorgangsbremsung und Speicherverschwendung da jede Datei ihre eigenen Header mitschleppt. Für den FS offensichtlich doch stark belastend.

Hallo Joachim,

nachdem ich jetzt Deine Antwort gelesen habe, ist mir -wie bei Dir
gewohnt- ein Licht aufgegangen.
Ich habe nämlich auch dem Start des FS oder auch beim Neuladen
von deutscher Szenerie nach Standort- oder Uhrzeitwechsel mittler-
weile (seit F.Barths landclass files) irrsinnige Ladezeiten und
-wie schon von mir beschrieben- hat die Häufigkeit zugenommen, mit
der der FS zehntelsekundenlang stehenbleibt.
Und da hat es offensichtlich dann auch nichts genutzt, daß ich für
jedes seiner Bundesländer einen eigenen Ordner in die Szeneriebiblio-
thek aufgenommen habe, sondern alles in eine einzige gepackt habe.

Du meinst also, daß auch die langen Ladezeiten für die scharfen
Texturen von diesen F.Barth-landclass files kommen ?

Das wäre natürlich schade, denn eine korrekte Verteilung der deutschen
Wälder und Ortschaften ist bzw.wäre schon eine schöne Sache.
Oder gibt es da zu den o.g. "Übeltäter"-landclass files eine
Alternative ?

Wenn Du mir aber jetzt nochmal bestätigst, daß nach meinen ganzen
Schilderungen diese landclass files wahrscheinlich wirklich der
"Übeltäter" sind, dann werde ich Deine Bestätigung wohl schweren
Herzens als Anlaß nehmen, um sie aus meiner Szeneriebibliothek zu
entfernen, denn diese unscharfen Texturen sehen total ätzend aus und
zerstören den positiven Effekt der fm_allemagne-mesh und Deiner
Grafikkarten-Einstelltips total.
Und auch die o.g. Ladezeiten sind abartig.

Also, was meinst Du dazu, Joachim ?

Vielen Dank für Deine Antwort,

Norbert

Hallo Leute!

Ich denke, das Problem liegt nicht nur an dem "zerstückelten" Aufbau der Landclass-Dateien von F. Barth. Ich habe mir vor längerer Zeit (da gabs noch kaum Freeware-Landclass) von FSLandclass Europa besorgt. Da befindet sich meines Wissens nach alles in einer Datei. Trotzdem konnte ich erhöhte Ladezeiten und unscharfe Texturen feststellen.
Ich denke, dass allein schon die vielen Übergänge zwischen unterschiedlichen Texturen, die schiere Anzahl der Texturen und ähnliche Dinge bei komplexen Landclass-Files ganz unweigerlich solche Folgen haben.
Aber ich bin mir sicher, dass man trotzdem natürlich besser fahren würde, wenn man nicht 400 Landclass-Files für halb Deutschland benutzt.

Gruss, Felix

Selbstverständlich benötigt ein Landclassaddon mit seiner Vielfalt wesentlich mehr Performance als diese Defaultwüste. Nur wenn dann anstatt eines großen Files 400 und mehr kommen dessen Informationen verwaltet der Header ausgelesen werden muß. Tja dann ist das halt noch mal einen Tuck schlimmer. Je nach Größe der Einzeldatei wird zusätzlich Festplattenkapazität verschwendet. Auch der Header jeder Datei ist geladen zusätzlich Speicher verschwendet.

Ich hatte schon mal was geschrieben. Man könnte die Barthfiles auch nachträglich in ein File unterbringen. Nur sinnvoll wäre das er das selbst macht. Denn er hat die Rohdaten. Alles andere ist noch mehr Arbeit.

....aber was ratet ihr mir nun (ohne daß ich das jetzt selber durch
umständliches Herumprobieren austesten muß); die unscharfen Texturen
bzw. hohen Ladezeiten (entstehen sie also jetzt wirklich duch die
landclass-files ??)in Kauf zu nehmen und dafür korrekte Wälder usw.
zu haben oder scharfe Texturen bzw. geringe Ladezeiten zu haben, aber
dafür "falsche" Wälder und Ortschaften ?

Norbert

Hat's noch keiner gelesen...?