|
Fs9.exe, Nocd, Fs9.cfg
Bezüglich FS9.EXE, NOCD Patch und FS9.CFG
Ich beziehe mich eigentlich auf folgenden Thread wo unter anderem kuriose Werte in der FS9.CFG vorliegen. Sag mir wo sind die Strommasten hin? Hier solche Geschichten in der FS9.CFG Der Wert steht auf: TERRAIN_USE_VECTOR_OBJECTS=552448608 oder so etwas "Meiner Meinung nach kommt das vom Patchen. Bei mir hat der Patch die Terrain_Extended_Levels auf über eine Million hochgeknallt. Kann also sein,dass er das manchmal auch mit den Vector Objects macht". was dann so aussieht TERRAIN_EXTENDED_LEVELS=1242456 bei sehr vielen sieht das nämlich so aus TERRAIN_EXTENDED_LEVELS=0 Zu dieser Geschichte kann ich zumindest was das letztere also (TERRAIN_EXTENDED_LEVELS=) betrifft für meine beiden PCs eine 100% Aussage machen. Es ist die NOCD FS9.EXE Version bzw. die original FS9.EXE Wie fast jeder Wissen dürfte erstellt der FS2004 die FS9.CFG erst nach der Installation der 4 CDs wenn der FS das erste mal gestartet wird. Das kann man aber auch simullieren wenn man bei einem FS einfach mal die FS9.CFG unter anderem Namen sichert. Der FS erstellt dann eine jungfräuliche FS9.CFG wie nach Erstinstallation des FS. Das kann auch mal ganz sinnvoll sein wenn man Probleme mit dem FS hat. So mancher Tipp bezüglich Trickserei zwecks Optimierung des FS ist nicht immer sinnvoll. Bei mir habe ich jetzt folgendes definitiv nachweisen können. Handelt es sich um den Zustand das der FS2004 noch nicht auf den FS9.1 gepatcht ist, dann bekomme ich bei Betrieb mit der original FS9.EXE (die die CD4 abfragt) bei Erstellung der FS9.CFG den Wert TERRAIN_EXTENDED_LEVELS=1242456 Nutze ich die NOCD Version erhalte ich den Wert TERRAIN_EXTENDED_LEVELS=0 (Habe ich mehrfach auf beiden PCs getestet. Ist nachvollziehbar. Patche ich jetzt den FS2004 von FS9.0 auf FS9.1 und nutze die neue NOCD Version bleibt es dabei TERRAIN_EXTENDED_LEVELS=0 Nutze ich die original FS9.EXE des FS9.1 Patches (die wieder die CD 4 abfragt bekomme ich bei Neuerstellung folgendes TERRAIN_EXTENDED_LEVELS=248 Letzteres habe ich nur bei meinem neueren PC getestet. Nun ist es ja so das Microsoft schreibt das man vor Patchinstallation die original FS9.EXE nutzen soll damit der FS9.1 Patch sich sauber installiert. Ich möchte den FS nicht noch mal neu installieren aber für mich ist es eindeutig woher diese Werte kommen. Ich kann es jederzeit zumindest mittels Test über Löschung der FS9.CFG und anschließender Neuerstellung der FS9.CFG durch den FS nachvollziehen. Andere Änderungen hat es bei mir nicht gegeben ich schliesse aber nicht aus das es je nach Hardware bei anderen anders aussehen kann. Übrigends eine sehr schöne Erkennungsmöglichkeit um zu sehen ob ein Anwender eine NOCD Version nutzt. Was hier im Forum leider fast komplett untergegangen ist, ist dieser Thread. Herkunft der NOCD.EXE Sollte etwa die NOCD Version direkt von Microsoft kommen? Was diesen Wert TERRAIN_EXTENDED_LEVELS=1242456 betrifft. Alle obigen geschilderten Varianten lösen rein gar nichts aus. Erst wenn der Anwender zusätzlich den Wert TERRAIN_EXTENDED_RADIUS=0.000000 ändert hat dieses Einfluss. |
Joachim,
das heisst dann aber doch nur, dass MS in einigen fs9.exe-Versionen (den 'Originalen' mit CD-Abfrage) die Variable TERRAIN_EXTENDED_LEVELS uninitialisiert lässt, da sie ohne gesetztem TERRAIN_EXTENDED_RADIUS sowieso keine Rolle spielt. In anderen fs9.exe-Versionen ((den 'Originalen' ohne CD-Abfrage) scheint das zufällig oder mit Absicht 'sauberer' zu sein, ändert aber auch nichts. Die spannende Frage wäre nun: wird durch den FS9 in einigen Situationen (PC, CPU, Ram, GraKa, ...) TERRAIN_EXTENDED_RADIUS doch initial gesetzt - und was ist dann mit TERRAIN_EXTENDED_LEVELS ? wieder mal mehr zum Grübeln ;) |
Zu
"das heisst dann aber doch nur, dass MS in einigen fs9.exe-Versionen (den 'Originalen' mit CD-Abfrage) die Variable TERRAIN_EXTENDED_LEVELS uninitialisiert lässt", Nein ist ja genau anders bei den originalen mit CD Abfrage kommt bei mir diese schwachsinnige Zahl 1242456 Bei der NOCD die ev. auch auf Microsoft basiert der Wert 0 "da sie ohne gesetztem TERRAIN_EXTENDED_RADIUS sowieso keine Rolle spielt. In anderen fs9.exe-Versionen ((den 'Originalen' ohne CD-Abfrage) scheint das zufällig oder mit Absicht 'sauberer' zu sein, ändert aber auch nichts". Das ist ja das was mich verwundert logischer wäre der Wert 0. Man hat einen Defaultzustand. Denn auch die beiden anderen Parameter darüber stehen auf 0. Ist sowieso komisch im FS2002 waren die Parameter gesetzt. Egal was immer es soll, es hat auch ohne Änderungen bei beiden Versionen im FS2004 einen festen Grundzustand. Ich habe die 3 Funktionen was sie genau bewirken (diesmal auch die Dimensionen) usw. alle noch mal durchgecheckt. Auch die Defaultwerte des FS2002 scheinen schwachsinnig gewesen zu sein. Nachkommastellen sind absolut unwirksam und unlogisch. |
Joachim,
genau das sag' ich doch :) "uninitialisiert lassen" bedeutet, diese schwachsinnigen Werte (uninitialiserte Variableninhalte) reinzuschreiben - "sauber initialisiert" steht dann eben 0 drin. Ob das sinnvoll ist oder nicht, spielt solange keine Rolle, wie TERRAIN_EXTENDED_RADIUS nicht auf einen Wert > 0 gesetzt wird. |
Hi Jobia und HJOrtmann,
kann man eigentlich eure Diskussion so zusagen für Nichtsblicker wie mich zusammen fassen ? Meine Frage ist: Soll ich jetzt die original FS9 CD einlegen und nutzen oder nicht ? Oder ist es doch gänzlich egal, weil sich eh nichts ändert ? Danke für die Antwort. |
Vergiss das ganze erst mal ist zwar alles etwas kurios aber hier ist es nicht so tragisch.
Zumal die meisten an diesen Parametern eh schon was verändert haben. Schlimmer ist halt das Problem im anderen Thread das bei manch einem wohl bei anderen Parametern ähnlicher Quatsch drin steht der etwas auslöst. Zu diesen drei Parametern TERRAIN_DEFAULT_RADIUS TERRAIN_EXTENDED_RADIUS TERRAIN_EXTENDED_LEVELS wie sie genau funktionieren wird man demnächst von mir noch was hören. Ich hatte sie ja damals auf meiner Homepage in einem Beitrag. Nur damals kannte ich die Dimensionen noch nicht, auch nicht die 100% tige Funktion halt nur das man damit erreichen konnte das der FS in der Tiefe des Raumes höherwertige MIP Level der Bodentexturen verwendet. Aber man muß da doch ein bischen mehr ausholen. |
Andy,
in allerKürze: nöö - zur Zeit spricht nix gegen die richtigen(!) NoCD-Version. |
Klare Antwort. Danke dafür.
|
Ich glaube sicher ist man nur wenn man mal über seine FS9.CFG drüber wegschaut und nach utopischen Werten schaut.
|
Zitat:
TIPP: zum eigentlichen Thema: vor einigen Monaten wurde das Thema "Werte in der *.cfg" im FXP-Magazin abgehandelt. Wer sich dafür interessiert, was da mit Beispielen vorgeschlagen und erklärt wurde, wird vielleicht im Archiv fündig. Auch im www.fsc-ev.de Forum (Lesen kann man dort auch ohne Anmeldung!) wurde dieses Thema durchgekaut, wobei ein Szenerie-Designer aufgrund seiner Erfahrungen Werte nannte, die in etwa denen aus FXP glichen. Abweichungen sind durch unterschiedliche Hardware-Konfigurationen und deren Zusammenspiel (Board<=>Graka) zu erklären. Leider ist es tatsächlich so, dass die *.cfg im FS teils mit unsinnigen Werten initialisiert wird. Es empfiehlt sich daher immer, die infrage kommenden Werte "manuell" nach Angaben von FXP oder FSC zu bereinigen. Geht mit einfachem Editor. Flusi neu starten. (Eventuell zwei Mal)! rico |
Zitat:
|
Hallo JOBIA und all die Anderen,
folgendes sollte etwas mehr Licht in das Dunkel der FS9.CFG bringen (Terrain, Texture etc.). Terrain_error_factor=96.000000 //Wert von 0-100 gibt den DEM Radius an. Terrain_Min_Dem_Area=10.000000 //Niedrigster Wert basierend auf dem Terrain_error_factor. Terrain_max_Dem_Area=100.000000 //Höchster Wert des DEM Radius Terrain_max_vertex_lavel=19 // DEM Auflösung: 18=150m DEM,19=75m DEM,20=37m DEM, // 21=19m DEM. Bei FS9.1 sollte also 21 gewählt werden. Terrain_Texture_Size_Exp=8 // Texturformat. 8=256x256, 7=128x128, 6=64x64 Terrain_Extendet_Textures=1 // 1=On, 0=off Setzt den Ext.Textur-Ring >/< 40 Meilen Terrain_Default_Radius=4.000000 // Radius für alle Ringe. Startet bei 0 endet bei 40nm. // > 9.9000000 kein Effekt mehr. Terrain_Extendet_Radius=4.50000 // Erweiterung den Default-Radius wenn Ext. Texture=1 // bis etwa auf max 100nm (4-4.5). Terrain_Extendet_Levels=1 //1/0 Zusätzlicher Ring wenn Ext. Texture=1 Noch einige andere interessante Parameter: Unter [Display.Device...] kann mit "TextureAGP=0" das AGP abgeschaltet werden. Der Effekt ist der, dass die CPU-Auslastung im FS9 nicht mehr in allen Fällen 100% ist. Z.B. wenn man auf der Rnwy nur steht sind es auch schon mal 0% (wie einst beim FS2002). Die FPS ist allerdings auch um ca.4 FPS geringer. Interessant als info. Unter [Diplay] der Parameter "Texture_Bandwith_Mult=40 steuert die Transferrate in Richtung GRAFKA. Hoher Wert=Hohe Rate. Z.B. 400 sollte nicht gesetzt werden wenn die GRAFKA < 128MB besitzt. Kann jeder mal testen. Unter [Graphics] der Parameter "Texture_Max_Load=512 // Max.Größ der AC/Objects bmp. //Kann sein 1024,512,256,128. Ein SDK für die FS9.CFG sollte es halt geben !! FlightXPress könnte sich einmal darum bemühen. Diese CFG ist in allen Foren immer wieder ein Rätzelraten (für viele, nicht alle Parameter) Nun kann das o.g. jeder mal bei sich ausprobieren. Gruss Fox |
Hallo Fox,
also deinen Betrag drucke ich mir jetzt aus, und dann ab ins Flusi-handbuch damit! ;) Woher hast du die Infos? Noch etwas zu dem Thema "TERRAIN_EXTENDED_LEVELS": Bei mir stand der Wert nach frischer Installation des FS2004 (ohne CD-Patch!) auf 1307992, nach dem Aufspielen von Hong Kong und GA1 unverändert. Auch keine Änderung nach Update auf 9.1 (weiterhin ohne CD-Patch!), auch nach weiteren AddOns (Sceneries) keine Änderung. Generell habe ich noch keine augenfällige Änderung der cfg nach dem Update auf V. 9.1 entdecken können - das Update ist aber definitiv drauf (keine Fehlermeldung, kein NoCD vorher, neue Versonsnummer im Menü, darstellung der neuen Brücken usw.). Gruß Roland |
Zitat:
Happy Landings |
Hallo
@ Fox Ob du mehr Licht ins Dunkel bringst?? - „Nun kann das o.g. jeder mal bei sich ausprobieren.“ Hast du deine "Weisheiten" auch bei dir ausprobiert, oder nur abgeschrieben? - „Ein SDK für die FS9.CFG sollte es halt geben !!“ Gebe ich dir völlig Recht. Darum hat auch Microsoft im Spiel: Setting oder Einstellung, wo man diese Werte verändern kann. Manche kann man nicht, und dies ist gut so! Die fs9.cfg, kann man ändern, wenn man weiß, was man ändert und deren Auswirkungen kennt. Diess nimmt einen großen Einfluss auf andere verwendete Techniken und Performance (Frames)! Daher sollten die meisten Anwender die Finger davon lassen. Was du zum Teil hier interpretierst und empfiehlst, stimmt leider nicht! Verzeihung, kein konstruktiver Beitrag Horst |
Zitat:
CPU ist in beiden Fällen 100% und mehr Frames hab ich auch nicht, egal ob ein- oder ausgeschaltet. |
Egal wo das her ist
"Terrain_error_factor=96.000000 //Wert von 0-100 gibt den DEM Radius an. Terrain_Min_Dem_Area=10.000000 //Niedrigster Wert basierend auf dem Terrain_error_factor. Terrain_max_Dem_Area=100.000000 //Höchster Wert des DEM Radius Terrain_max_vertex_lavel=19 // DEM Auflösung: 18=150m DEM,19=75m DEM,20=37m DEM, // 21=19m DEM. Bei FS9.1 sollte also 21 gewählt werden. Terrain_Texture_Size_Exp=8 // Texturformat. 8=256x256, 7=128x128, 6=64x64 Terrain_Extendet_Textures=1 // 1=On, 0=off Setzt den Ext.Textur-Ring >/< 40 Meilen Terrain_Default_Radius=4.000000 // Radius für alle Ringe. Startet bei 0 endet bei 40nm. // > 9.9000000 kein Effekt mehr. Terrain_Extendet_Radius=4.50000 // Erweiterung den Default-Radius wenn Ext. Texture=1 // bis etwa auf max 100nm (4-4.5). Terrain_Extendet_Levels=1 //1/0 Zusätzlicher Ring wenn Ext. Texture=1" ob irgendwo abgeschrieben oder nicht. Sehr genaues sagt der Text in einigen Punkten ja nicht aus. Ich habe ähnliches schon bei AVSIM gelesen. Bei einigen Parametern bin ich ganz anderer Meinung sie werden hier wenn mich meine Tests nicht trügen eindeutig falsch wiedergegeben. Zu "Terrain_error_factor=96.000000 //Wert von 0-100 gibt den DEM Radius an. Terrain_Min_Dem_Area=10.000000 //Niedrigster Wert basierend auf dem Terrain_error_factor. Terrain_max_Dem_Area=100.000000 //Höchster Wert des DEM Radius Was ist der DEM Radius? Den reinen DEM (Mesh) Radius gibt es nicht an da sprechen meine Tests dagegen. Was ich mit Sicherheit sagen kann das man es nicht als Radius sehen kann wie weit ein Mesh reicht das könnte man hier zunächst vermuten. Aus meiner Sicht ist dieser Punkt ein Parameter wie weit ein Mesh in seinem jeweiligen Unter LOD Leveln reicht. Man muß wissen das auch ein LOD10 Mesh mit seinen ca. alle 38m ein Höhenpunkt in der Tiefe des Raumes dynamisch in der Auflösung heruntergefahren wird. Dieser Parameter "Terrain_error_factor=" scheint Auswirkungen auf diese Dynamik zu haben. Haben wir hohe Werte haben wir auch in der Tiefe des Raumes mehr Details. Haben wir niedrigere Werte haben wir in der Tiefe des Raumes weniger Details. Zu Terrain_max_vertex_level= "Bei FS9.1 sollte also 21 gewählt werden". Kein guter Tipp. Ok wenn jemand ein LOD11 Mesh hat und dieses in seiner höchsten Auflösung sehen will dann kommt er nicht drum hin den Parameter auf 21 setzen zu müssen. Aber bewegt man sich außerhalb eines LOD11 Mesh dann hat der Wert 21 sehr viele negative Auswirkungen. Remesh Technik über LWM funktioniert nicht mehr. So erhält man z.B in der Hamburg Freeware Scenery (ob es bei der in SG2 integrierten Variante auftritt weis ich nicht) an der Elbe auf einmal Kunstpyramiden. An den meisten Airports bzw. Seen , Küste treten extrem steile Meshkanten auf. Das fällt unnatürlich auf. Durch diese Steigung löst in der Regel der Automatismus bei Landclass aus, wir bekommen jetzt Landclass- und damit Bodentexturwechsel. Auf ein mal sehen wir im Airportumfeld wo vorher ev. eine Stadt war jetzt Wald bzw. gar Gebirge. Das selbe an Seen und Küsten. "Terrain_Extendet_Textures=1 // 1=On, 0=off" Setzt den Ext.Textur-Ring könnte man grob so stehen lassen ist im Prinzip richtig. Genau genommen ist es eine Schaltquelle bis wohin wir Landclassbodentexturen sehen. Außerhalb diesem Bereichs sehen wir das vereinfachte Weltmodell. Was das vereinfachte Weltmodell ist wie es generiert wird steht auch in meiner Dok. Zu dem Rest bin ich in einigen Punkten auch ganz anderer Meinung. So habe ich bei mir z.B nie nachweisen können das diese Aussage "Terrain_Extendet_Radius=4.50000 // Erweiterung den Default-Radius wenn Ext. Texture=1" korrekt ist. So eine Antwort findet man auch wo anders. Ich erkenne bei diesem Parameter "Terrain_Extended_Radius" keinerlei Einfluss auf den Schalter Extended Textures=1. Er hat damit nichts zu tun auch wenn es sich zunächst so anhört. Bei mir arbeitet der "Terrain_Extended_Radius" egal wie der Schalter Extended Textures geschaltet ist. Auch kann ich das nicht bestätigen "// > 9.9000000 kein Effekt mehr" Der Effekt hört bei mir viel früher auf. Nachkommastellen lösen bei mir schon garnichts aus. Ich bin da selbst in dem Beitrag den ich mal für den FS2002 geschrieben habe drüber gestolpert weil beim Default FS2002 wenn ich mich recht erinnere auch Nachkommastellen existierten. Auch geht es hier eigentlich nicht um Radien. Ok könnte man sich noch drauf einigen das es grob Radien sind. Mit nautischen Meilen hat es aber nichts zu tun. Diese Dimensionen also z.B eine 3 bei Terrain_Extendet_Radius=" ergibt bei mir einen Sinn der nachweisbar ist. Wenn Microsoft da Meilen als Dimension vorgesehen hätte dann hätten sie das tun können. "Terrain_Extendet_Levels=1 //1/0 Zusätzlicher Ring wenn Ext. Texture=1" Die Möglichkeit hier 1/0 kann ich auch nicht bestätigen bei mir haben auch andere Werte nachweisbar Auswirkungen die einen Sinn ergeben. Nur das der Sinn ein anderer ist als der jenige der hier geschildert wird. Ich weis nicht wo Du das her hast aber meine Tests sagen in einigen Teilen doch etwas anderes aus. Dazu mehr in der Dok. Es sei denn meine beiden PCs haben beide den selben Fehler so das es sich nur bei mir anders verhält. |
Zu
"Terrain_Texture_Size_Exp=8 // Texturformat. 8=256x256, 7=128x128, 6=64x64" Das ist korrekt wird hier einem Anwender aber vermutlich nicht viel sagen. Man muß wissen das jede Landclassbodentextur bzw. Custom Fotoscenerytextur als Basis aus 256 x 256 Pixeln besteht da kann man die Erdoberfläche schon halbwegs vernünftig aufgelöst erkennen. Um Texturflimmern zu verhindern bzw. Performance zu sparen gibt es in so einer Basistexturdatei minderwertigere Unterformate die natürlich die Erdoberfläche nicht so scharf darstellen. Diese verwendet der FS in der Tiefe des Raumes. Man nennt diese Unterformate MIP Level. 256 x256 Pixel ist MIP Level 0 der nächst schlechtere ist MIP Level 1 mit 128 x 128 Pixeln usw. Terrain_Texture_Size_Exp=8 mathematisch bedeutet dieser Faktor (weis jetzzt nicht genau wie ich das über die Textur richtig schreiben kann daher in Schrift) 2 hoch 8 = 256 hat dann zur Folge das wir nahe bei unserem Flugzeug Texturen mit 256 x 256 Pixeln sehen also MIP Level 0. Weiter in der Ferne 128 x 128 noch weiter weg 64x64 usw. Setzen wir ihn auf 7 2 hoch 7 = 128 hat zur Folge das in nächster Nähe nur noch der Mip Level 1 als höchstwertige Texturvariante gesehen werden kann. Alle anderen MIP Level in der Tiefe des Raumes verschieben sich qausi in der Qualität. |
Hallo Joachim,
Zitat:
Nur müssen dann halt in den Designprogrammen durch die Ersteller auch genau diese deutlich mehr Geländepunkte eingetragen werden. Sind diese nicht da, so siehst Du meiner Ansicht nach die "lustigen" Auswirkungen wie von Dir beschrieben. Auch die SG2 funktioniert ausschließlich mit der 19er Einstellung wie von den Designern vorgesehen. Würde also aber auch empfehlen, den TML auf 19 zu belassen, weil es einfach Standard ist und man sich unnötig Probleme ausserhalb dieser genauen Meshs einhandelt. Auch muß betrachtet werden, dass Einstellungen der terrain.cfg und der fs9.cfg oftmals gewissermaßen "zusammenspielen". Beispielsweise führt ein TML von 21 dazu, dass bei einer Nicht-Anpassung der terrain.cfg in gewissen Parametern ein lustiger Schlucht-Effekt bei den Microsoft-Bächen auftritt. Auch Flatten-Bereiche werden deutlich "besser" sichtbar. Also Obacht. Dies hatte ja auch Joachim oben schon beschrieben. Bin andererseits sowieso immer kritisch, was andere so an Weisheiten loslassen und kann jedem nur empfehlen, die hier auf Seite 1 losgelassenen Tipps zumindest nicht ohne vorherige Sicherheitskopie der fs9.cfg auszuprobieren. Und bei Problemen mit Addons immer zuerst dann an dieser Schraube wieder drehen, bevor man heulend an ein fehlerhaftes Addon glaubt. In diesem Sinne. Ciao, Rainer. |
Hallo JOBIA,
danke für Deine kostruktive Antwort auf meinen Beitrag. Woher ich das habe ? Sammlung von Beiträge aus verschiedenen US-Foren und natürlich auch alles selber getestet. Die Effecte sind mehr/weniger sichtbar. Was Du sagst über Vertex-Level=21 stimmt. Die Mesh-Kanten sind ziehmlich steil. Ein Wert von 20/19 sieht ggf. besser aus. Vielleicht kann uns FlightXPress in dieser CFG-Problematik mal helfen und an MS eine Anfrage stellen. Sollte doch mehr bewirken als wenn einer von uns bei MS anfragt. Ich habe an die Redaktion einen Brief geschrieben, mit einer entsprechenden Bitte. Ich hoffe auf eine Antwort und werde das Forum dann informieren. Gruss Fox |
@Fox
Die fs9.cfg Datei, ist eine wichtige Steuerungsdatei!!!! Nicht nur für den FS, sondern auch abhängig von deiner Hardware und den Addons, die du besitzt. Sie bewirkt globale Einstellungen!!! Nur ein Beispiel zu deinen z.B. - Terrain_error_factor=96.000000 //Wert von 0-100 gibt den DEM Radius an. Nein, dies reduziert nur Punkte, in den bis zum Horizont verschieden dargestellten und aufgelösten Lod Level Meshfiles. Ändern kannst du es in im FS unter: Settings/Display/Scenery/Terrain/Terrain mesh complexity (Verzeihung, ich habe nur die US "Blechdose") (Wenn du es getestet hast, wirst du ja wissen, wann die Änderung in Kraft tritt) Bewirkt nur die Freigabe an Rechenleistung, für minder dargestelltes Terrain. Genau diese Werte und Szeneriedarstellungswerte (terrain.cfg) kann man nicht lokal steuern, daher wirst du nur eine nette ausweichende Antwort auf deine Anfrage bekommen. Es ist keine CFG-Problematik – sondern eine Problematik der Auswirkungen auf verschiedene Techniken der Darstellung. Und man kann sie nicht mit globalen Werten lösen, sondern nur einen Kompromiss auf seinem System derzeit suchen. Somit kann ich nur Rainers Worte wiederholen: "Bin andererseits sowieso immer kritisch, was andere so an Weisheiten loslassen und kann jedem nur empfehlen, die hier auf Seite 1 losgelassenen Tipps zumindest nicht ohne vorherige Sicherheitskopie der fs9.cfg auszuprobieren. Und bei Problemen mit Addons immer zuerst dann an dieser Schraube wieder drehen, bevor man heulend an ein fehlerhaftes Addon glaubt." Horst |
Hi Jobia,
da ich zur Zeit auch am probieren bin, welche die besten Einstellungen in der "Terrain-Section" sind, würde mich mal interessieren, was Du für Settings eingestellt hast. Gruss :confused: :rolleyes: ;) |
Zu
"Bist Du sicher?" Ich habe da eigentlich ein Gegenbeispiel bei meinem aktuellen Projekt. Remesh über Ground2k4 funktioniert grundsätzlich wohl auch mit TML=21. Könnte so einige Probleme bei meinem hügeligen Bergland mit den Plätzen dort überwinden, die mit normale 19er nicht wirklich zu bereinigen sind. Nur müssen dann halt in den Designprogrammen durch die Ersteller auch genau diese deutlich mehr Geländepunkte eingetragen werden. Sind diese nicht da, so siehst Du meiner Ansicht nach die "lustigen" Auswirkungen wie von Dir beschrieben. Auch die SG2 funktioniert ausschließlich mit der 19er Einstellung wie von den Designern vorgesehen." Ja Rainer ich bin mir absolut sicher. Es ist mir klar das wenn ein Designer bei Remesh im LOD11 Raster arbeitet, daß es dann auch bei TMVL21 klappt, das ist mir schon klar. Nur das was ich bisher gesehen habe ist alles im LOD9 Raster umgesetzt worden. Ich kenne da bisher auch nur die Hamburg Scenery wo das an der Elbmündung eingesetzt wurde (ob es noch wo in der SG2 eingesetzt ist weis ich nicht, da ich momentan nicht die Zeit dazu hatte.) Dann kenne ich bei einer Monaco/Nizza Scenery die Verwendung von Remesh in LOD9. Von daher habe ich mich auch nur hier drauf bezogen auf remesh in LOD 9 weil bei Verwendung dieser Scenerien (die SG2 bzw. Hamburg Freeware dürften sehr viele Anwender haben) der Effekt der Pyramiden in jedem Fall bei TMVL21 auftritt. Ok ich hätte meine Worte oben anders wählen sollen dann wäre es klarer gewesen. Für diejenigen die es nicht wissen. Der TMVL21 erlaubt es beim FS2004 nach FS9.1 Patch das jeder Höhenpunkt bei einem LOD11 Mesh (ca. alle 19m ein Höhenpunkt auch einzeln dargestellt werden kann. Der FS verbindet diese Höhenpunkte mit Polygonen so das ein feste Oberfläche entsteht. Hat man ein LOD9 Mesh also ca. alle 76m ein Höhenpunkt dann stört das bei TMVL21 nicht. Auch hier werden die Höhenpunkte mit Polygonen verbunden obwohl sie 76m auseinanderliegen. Anders sieht das mit dieser Remesh Technik aus die auf LWM Technik basiert. Setzt man hier alle 76m ein Höhenpunkt dann werden diese Höhenpunkte bei TMVL19 (Defaultwert)jetzt auch sauber miteinander verbunden, da maximal ein LOD9 Mesh unterstützt wird. Man kann sich das so vorstellen als wenn man ein Tuch auf ein Nagelbrett legt. Dreht jetzt aber jemand den TMVL auf 21 dann unterstützt der FS jetzt auch LOD11 Mesh. Bei Remeshtechnik in LOD9 hat man aber nur alle ca. 76m ein Höhenpunkt. Der FS stellt jetzt aber jeden Höhenpunkt dar. Auch diejenigen die zwischen den 76m liegen. Von daher entstehen Pyramiden. Der FS stellt eine Remeshhöhenpunkt dar, dann stürzt das Gelände auf das reguläre Mesh ab. Bis man zum nächsten Remeshpunkt kommt. Dann geht es wieder hoch. Danach stüzt es wieder ab usw. Also so als wenn man das Tuch beim Nagelbrett in die Zwischenräume drücken würde. Bei regulärer Meshtechnik passiert dieses bei einem LOD9 Mesh nicht. Im Prinzip kann man das so sehen das das reguläre Meshoberflächentuch viel steifer als das Meshoberflächentuch bei Remeshtechnik über LWM ist. Wie gesagt vereinfacht ausgedrückt. Grundsätzlich werden wie gesagt alle Flanken an meshbeinflussenden Techniken steiler. Meshbeeinflussend sind wie gesagt LWM Techniken (Gewässer, Seen, Flattenpolys an z.B Airports, Linienflüsse (die schmalen Flüsse des FS) und natürlich die Straßen des FS. Das kann sogar soweit gehen das man bei schrägen Straßen am Hang Ausrichtung z.B 45° bei TMVL21 das LOD Raster selbst erkennen kann. Wir sehen die Kante wie ein Sägeblatt ausgefranst. |
Zu
"Nur ein Beispiel zu deinen z.B. - Terrain_error_factor=96.000000 //Wert von 0-100 gibt den DEM Radius an. Nein, dies reduziert nur Punkte, in den bis zum Horizont verschieden dargestellten und aufgelösten Lod Level Meshfiles. Ändern kannst du es in im FS unter: Settings/Display/Scenery/Terrain/Terrain mesh complexity (Verzeihung, ich habe nur die US "Blechdose") (Wenn du es getestet hast, wirst du ja wissen, wann die Änderung in Kraft tritt) Bewirkt nur die Freigabe an Rechenleistung, für minder dargestelltes Terrain." Eben Du sagts es Horst das deckt sich ja auch mit diesem Text von mir oben. Was ist der DEM Radius? Den reinen DEM (Mesh) Radius gibt es nicht an, da sprechen meine Tests dagegen. Was ich mit Sicherheit sagen kann das man es nicht als Radius sehen kann wie weit ein Mesh reicht das könnte man hier zunächst vermuten. Aus meiner Sicht ist dieser Punkt ein Parameter wie weit ein Mesh in seinem jeweiligen Unter LOD Leveln reicht. Man muß wissen das auch ein LOD10 Mesh mit seinen ca. alle 38m ein Höhenpunkt in der Tiefe des Raumes dynamisch in der Auflösung heruntergefahren wird. Dieser Parameter "Terrain_error_factor=" scheint Auswirkungen auf diese Dynamik zu haben. Haben wir hohe Werte haben wir auch in der Tiefe des Raumes mehr Details. Haben wir niedrigere Werte haben wir in der Tiefe des Raumes weniger Details. |
Zu
"Woher ich das habe ? Sammlung von Beiträge aus verschiedenen US-Foren und natürlich auch alles selber getestet." Das Problem ist das meine Tests eindeutig gegen einige der aus dem US Forum wiedergegebenen Beiträge sprechen. Ich sehe einige Funktionen in weiten Teilen ganz anders. Du sagst Du hast es selbst getestet. Theoretisch hätte Dir das auffallen können das da einiges nicht stimmt. Nur meine Erfahrungen sind mittlerweile das man mit normalen Scenerydateien solche Sachverhalte was ein undokumentierter Parameter in der FS9.CFG bedeutet oder ausführt überhaupt nicht beurteilen kann. Von daher wundert es mich nicht das es Tipps oder Werte zu Einträgen in der FS9.CFG gibt die eigentlich überhaupt nichts mehr auslösen. Von daher ziehe ich meine persönlichen Kenntnisse nur noch aus eigends angefertigten Testdateien wo ich mir vorher Gedanken mache wie kann man ev. so ein Problem eingrenzen bzw. einen eindeutigen Beweis erbringen wofür ein Parameter steht und wie er arbeitet. Dieses sind dann beweisbare nachvollziehbare Fakten. Zum Schluss kommt dann die Endkontrolle lässt sich das anhand einer realen Scenery mit dem neuen Wissenstand den man gewonnen hat nachvollziehen. So muss auch ich gestehen das ich beim Thema Mesh was diese LOD Dynamik bei einem Meshfile betrifft noch nich ganz so sicher bin was im mittleren Nahbereich genau abläuft. Da gibt es auch Unterschiede zum FS2002. Da war das ziemlich eindeutig. |
Zu
Zitat:
Wie ich es dem normalen Anwender empfehlen würde, dazu kann man dann was in meiner Landclassdoku lesen. Ich möchte dem nicht vorgreifen. Die Doku wird zwar interessant sein da auch zusätzlich zu der reinen Dokumentation des Landclassystem diverse Tipps und ein aktueller Landclass Patch enthalten sind. Nur da steckt viel Arbeit drin. Wenn ich alles vorher ausplaudere dann liest das keiner mehr. Da es momentan so ausschaut das aus beruflichen Gründen wohl auch die Freizeit für den Beruf investiert werden muß (was aber noch nicht feststeht könnte aber passieren) wollte ich die Doku als letzten großen Beitrag zu Ende bringen. Da ist mir natürlich schon dran gelegen das es nicht ganz umsonst war und ev. doch von ein paar Leuten mehr gelesen wird. Wobei man matürlich nie sagen kann ob an so etwas ein halbwegs breites Interesse besteht. |
Zum Thema
Terrain_error_factor ein Bild aus einer meiner Testfiles. Links Terrain_error_factor=100% rechts Terrain_error_factor=10% Man beachte im hinteren Bereich wo es blau ist diese Hügelkante im Mesh. Links schmal und hoch, rechts flach und breit. Das ganze kann man am über dem gesamten Verlauf dieser Meshkante links und rechts vergleichen und sehen. Dieser Parameter ist von der Funktion daher durchaus vergleichbar mit dem Terrain_Texture_Size_Exp= bei Texturen. Er besagt wieviele Höhenpunkte von einem Mesh (welcher LOD Level) dynamisch vom Vordergrund bis zum Hintergrund verwendet werden soll. Unten das Bild |
Hallo Joachim,
Zitat:
"Aber bewegt man sich außerhalb eines LOD11 Mesh dann hat der Wert 21 sehr viele negative Auswirkungen. Remesh Technik über LWM funktioniert nicht mehr." war eine andere. Zitat:
Zitat:
Und solche "Wissenshäppchen" - wie hier von Dir wieder gezeigt - führen natürlich auch zu dem Drang nach mehr. :D Du machst das schon richtig. Allerdings teile ich Deine Befürchtungen, dass es dann schlußendlich trotzdem kaum jemanden interessieren wird und die Fragen/Probleme hier trotzdem die gleichen bleiben. Ciao, Rainer. |
Hallo Horst,
Du sagst: "Die fs9.cfg Datei, ist eine wichtige Steuerungsdatei!!!!" So what ?? Fehlt eigentlich nur noch:" Die man nicht ändern soll!" in Deinem Beitrag. Der ganze FLUSI würde doch nur halb soviel Spass machen, wenn man nichts ändern könnte. Und so freuen wir uns weiter auf viele konstruktive Beiträge wie man wie, was, wo und mit welchen Mitteln, für jeden nach seinem Geschmack, ändern kann. Und jeder mag testen, probieren, oder auf nummer sicher gehen und alles beim Standard lassen, wie es ihm beliebt. Nicht vergessen:"Wir fliegen nicht real" und ein FLUSI-Absturz ist Gott sei Dank kein Beinbruch. Happy Changing (oder auch nicht) Fox |
Zitat:
Die "Suche" Funktion hier im Forum ist sehr hilfreich! Horst |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 14:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag