Das Problem was es mit Switzerland gibt ist folgendes. Programmiert man jetzt eine Fotoscenery gemäß FS2002 SDK dann legt sich diese optisch über die bisherige Scenery nur die Airports bleiben optisch oberhalb der Fotoscenery bestehen. Ohne weitere Maßnahmen verschwinden aber optisch sämtliche anderen Sceneryelemente wie Landclassbodentexturen deren Autogen, die Gewässertexturen der großen Seen und Flüsse usw. Was zurückbleibt sind allerdings dessen meshbeeinflussende Komponenten also die Höhen.

Hätte ich die Switzerland Fotoscenery und würde die über mein Bild im Anhang legen hätten wir sie als optische Oberfläche. Allerdings würde sie sich auch über diese Tafelberge des Sees und des Airports legen. Übrigends wäre mein Mesh höher als der See und der Airport hätte man hier optische Senken in diesem Bereich.

Genau hier besteht für Jean das Problem. Die Seen von Microsoft sind leider falsch positioniert (zum Teil 500m und mehr) auch sind sie in der Form nicht ganz korrekt. Airports müssen konstruktionsbedingt eine feste waagerechte Höhe haben wenn auch AI Traffic erfolgen soll bzw. Texturen eine höhere Auflösung größer ca. 4,7m pro Pixel haben sollen. Er bekommt in sein Mesh bzw. die Fotoscenery z.B durch falsch positionierte Seen optische Fehler in Form von Tafelbergen und Senken (natürlich nicht so augeprägt wie bei meiner Demo) wenn sein Mesh sehr genau ist. Übrigends auch Sraßen usw. beeinflussen das Mesh sie flatten es. Mit anderen Worten sie flachen es waagerecht ab. Erkennbar im Bild an der Railroad im Vodergrund. Hier ist der Welleneffekt des Mesh gedämpft. Kleine Linienflüsse wie im Hintergrund flatten das Mesh nicht dafür drücken sie eine Senke ins Mesh.

Hier das Bild. gelbe Pfeile wellenförmiges Mesh.
rote Pfeile Airport und See sitzen unabhängig vom Mesh auf einem Berg.
orange Pfeile Railroad flattet die Wellen des Mesh waagerecht ab. Weiterhin kann man hier schön den Automatismus von Landclass sehen das je nach Steigung im Mesh die Texturen wechseln. Bei meinen Wellen im Mesh findet man Wald vor usprünglich ist da eine Landclass programmiert die Felder zeigt. Im Bereich bei der Railroad wo es flach ist Felder. An den Hängen zu den Tafelbergen Gebirgstexturen. Dieser meshabhängige Texturwechsel bei Landclass ist leider nicht beeinflussbar und bereitet den Designern Probleme.

Jean wollte etwas tun um diese neagtiven Effekte zu verhindern. Leider ist noch kein Terrain SDK für den neuen FS2004 veröffentlicht worden. Wie also vorgehen?

Er ist daher den Weg gegangen das er Scenerydateien die z.B die Seen enthalten einfach durch umbenennen deaktiviert. Diese Informationen werden dann vom FS nicht mehr verarbeitet.
Für die Seen bedeutet dieses im Prinzip sie existieren nicht mehr. Auf mein obiges Bild bezogen würde dieses bedeuten: Optisch ist der See mit seinen Texturen verschwunden weiterhin aber auch seine eigene Höheninformation und damit auch der Tafelberg. Es gibt keine Meshstörung mehr. Das die Gewässertexturen auch nicht mehr existent sind juckt uns nicht, da wir ja die Fotoscenery haben die diese Informtion in den Texturen selbst enthält.

Das löschen bzw. deaktivieren hat allerdings Nachteile.

1) Da die Gewässerinformation selbst in Form einer sogenannten Landwatermaske (LMM Poly) abgelegt ist und aus dieser andere Elemente des FS Informationen beziehen fehlen für diese natürlich die LWM Masken.

Folge: Der See wird nicht mehr in unserem GPS, der Kartenansicht und dem Wettermenü angezeigt.

2) In so einem File sind immer gleich sehr viele Seen enthalten. So deckt z.B das File HP950150.bgl welches von Switzerland deaktiviert wird die Fläche von ca. oben Nord N47*48.00` bis nach unten Süd N45*00.00` und von links West E07*30.00` bis rechts Ost E11*15.00` ab.
Eine riesen Fläche die wesentlich größer als die Switzerland Fotoscenery ist. Das selbe gilt für andere Files die noch deaktiviert werden.

Das ist die Erklärung dafür das außerhalb von der Switzerlandfotoscenery diese Informationen fehlen.

Die optimalste Lösung wäre es z.B die Gewässer komplett neu eintsprechend Ihrer Realität sowohl in der Form, Position und Höhe neu zu programmieren.
Von Hand sehr viel Arbeit Rainer kann ein Lied davon singen. Die andere Lösung ist eine Manipulation der Defaultfiles. Jean kannte diese Möglichkeit damals nicht jetzt kennt er sie.

Jetzt könnte man nur innerhalb der Switzerland die Gewässer löschen. Es gäbe keine Störungen außerhalb der Switzerland. Im GPS wären die Seen trotzdem verschwunden. Abhilfe ist auch hier möglich. Die Höhe -9999m wird im FS als Meshclinging interpretiert. Die Oberfläche eines vorhandenen Gewässers folgt dem Meshgelände. Dadurch gibt es keine Meshstörungen das Gewässer selbst bleibt im GPS erhalten. Diesen Weg wird jetzt Jean gehen. Die Tools mit denen man das erledigen kann hinterlassen aber geringfügige Spuren. Will man diese beseitigen muß man andere Wege gehen.
Das Ergebniss ist aber auch so sehr gut.

Straßen und Railroads, Linienflüsse müssen aber entfernt werden um Ihre Meshstörungen zu beseitigen. Es gibt nur eine andere Lösung die ich sehe. Erhalten dieser Elemente innerhalb der Schweiz aber eine Umswitchung auf Dummytexturen anstatt einer Zuweisung über die terrain.cfg. Dann kann man innerhalb der Schweiz alles erhalten und bekommt trotzdem die Mesheeffekte weg. Ich weis nicht wie Jean da vorgehen wird, das Thema hatten wir noch nicht.

Kommen wir zum Rollwegproblem. Dazu unten ein weiteres Bild. Hier habe ich zusätzlich das LWM Flattenpoly in der Höhe auf 78m manipuliert. Es liegt damit über dem Mesh aber unterhalb des Airports. Das LWM Flattenpoly hat folgende Hintergrund.

Möchte man z.B Polygone mit Bodentexturen erstellen die eine höhere Auflösung als Landclass haben sollen dann benötigen sie eine waagerechte Oberfläche. Hier erstmal das Bild.

Was kann man bei diesem Bild sehen. Man sieht im Bereich der gelben Pfeile das der Airportrasen auf 78m abgesackt ist. Dieses zuvor erwähnte Flattenpoly ist von Microsoft übrigends exakt in der Größe programmiert wie das Airportrasenpoly. Man sieht aber das die Runway und Teile des Airports noch auf 280m liegen.

Da wir bei Bild1 aber gesehen haben das auch das LWM Flattenpoly durch seine eigene Höhe Tafelberge bzw. Meshbeeinflussung generell auslöst hat Jean diese Files auch gelöscht. Damit folgt der Airportrasen in weiten Teilen dem Mesh. Tafelberge oder Senken fallen so nicht weiter groß auf. Wir wissen in der Realität sind Airports äußerst selten pott ebenen und waagerecht. Durch löschen der LWM Flattenfiles mindert er die durch sie verursachten Mesheffekte.

Man kann erkennen das Teile des Airports aber nicht absacken. In diesen Bereichen stürzt ein Flugzeug dann nicht in ein Loch. Weicht man aber davon ab erwischt es einen und man sackt bis auf die Meshhöhe ab.

Das Du bei einem ADDON Airport diesen Effekt nicht hast kommt dadurch das diese in der Regel Ihre eigenen Flattenpolygone meist noch alter Machart also ganz andere Technik (Area16N) für sich selbst mitbringen. Kann man auch sehr schön bei GAP FS2002 Versionen sehen wenn man ein gutes Mesh hat. Hier sind die Bereiche wo das Mesh im Umfeld platt gemacht wird wesentlich größer als bei den Defaultairports, die hier kleinere Flattenpolys verwenden.

Als Nebenanmerkung möchte ich noch erwähnen, dass sich die neuen Defaultairports generell anders als die nach alter Technik verhalten. Würde mein Bild einen alten FS2002 Airport zeigen hätte der ältere Runwaycode selbst eine Meshverbindung hergestellt. Es gäbe keine schwebende Ruway. Taxiwaylines würden schweben. Die Taxiways und Apron selbst würden auf das Mesh absacken und ev. flackern. Die Airportgebäude wiederrum würden schweben.

Grund dafür das beim neuen alles oben bleibt ist der neue Code. Wir erinnern uns das unsere optischen Rollweginformationen beim neuen auch als Rollwegdefinition für den AI Traffic gelten. Der ist von Microsoft aber nur als waagerechter Verkehr vorgesehen. Sprich die Bezugshöhe des AI Traffics ist auch gleichzeitig die Höhe der neuen Taxiways/Aprontexturen.
Früher war der AI Traffic eine eigenständige Information.

Bei der Gelegenheit sei auch gleich das versacken von AI Traffic angesprochen.
Ich erwähnte oben wie es ausgesehen hätte wenn wir hier einen Airport nach FS2002 Technik gesehen hätten. Taxiways usw. wären auf das Mesh bzw. auf ein niedriger liegendes Flattenpolygon abgesackt. Sprich liegt das Flattenpoly bei einer ADDON Scenery nicht exakt auf der selben Höhe wie die AI Traffic Höhendefinition haben wir schwebende oder versinkende Flugzeuge. Das kann natürlich dann auch für Airportobjekte gelten wie Gebäude oder statischen/dynamischen Verkehr.

Im Anhang noch mal ein Bild wie es sich momentan bei der Switzerland verhält. Im Gegensatz zu Bild 2 fehlt das Flattenfile FL950150.bgl.

Man erkennt das Rasenpoly ist auf das gewellte Mesh abgefallen. Im Prinzip Dein beobachteter Zustand. Nur das man es durch die Übertreibung meiner Werte hier besser sieht.

Bei der Gelegenheit kann man auch den Terrain_Max_Vertex_Level (TMVL) erklären der von Switzerland in der FS9.CFG verändert wird.

Dieser Faktor ist Default auf 19 gesetzt. Er ist im Gegensatz zum FS2002 nicht mehr über einen so großen Bereich manipulierbar. Offensichtlich hat Microsoft hier einen Riegel vorgeschoben.

Er hat viele Auswirkungen auf das Mesh und ich möchte nicht alles was dahintersteckt erwähnen. Wichtig für unseren Fall sind die Probleme die wir dadurch erhalten können.

Warum hat ihn Jean geändert?

Ein Mesh zeichnet sich durch zwei wesentliche Merkmale aus. Zum einen natürlich die Qualität der umgesetzten Höhengenauigkeit im FS. Was nützt in dieser Hinsicht die höchste Genauigkeit wenn wir nur alle 1km einen Höhenpunkt hätten.

Also ist der nächste Punkt wieviele Höhenpunkte ich in der waagerechten Fläche habe. Im Prinzip vergleichbar mit einer Bilddatei. Hat man zwei Fotos die das selbe Objekt darstellen kann man bei dem welches aus mehr Pixeln besteht die Feinheiten besser erkennen als bei dem was nur wenige hat.

Hier gibt es beim FS feste Stufen/Schritte in denen das erfolgen kann. Man nennt dieses den LOD Level. Da hatte ich aber auch auf meiner Homepage etwas zum nachlesen falls da jemand Interesse hat. Jean hatte sehr gute Rohdaten. Er hat daher LOD Level11 für sein Mesh in der Schweiz gewählt. Das entspricht im Prinzip ca. alle 19m ein Höhenpunkt. Es ist klar das man damit sehr viele Feinheiten darstellen kann. Wir hatten das Matterhorn als Beispiel. Ev. war das nicht so gut gewählt da man extrem steile abfallende Höhenwerte auch mit einem niedrigen LOD Level ganz gut darstellen kann. Anders sieht es aber aus wenn etwas stark zerklüftet ist.

Auf jeden Fall stellt der FS mitTMVL19 dieses optisch nicht mehr dar. Das war der Grund warum Jean diesen verändert hat. Meine Empfehlung liegt aber ihn bei 19 zu belassen.

Um mal die Auswirkungen zu demonstrieren habe ich ihn mal nicht auf 21 erhöht wie es durch Switzerland passiert sondern habe ihn mal von 19 auf 18 abgesenkt.

In Bild4 findet man Auswirkungen. Das Bild ist eine deckungsgleiche Fotomontage. Es zeigt ein und die selbe Scenery. Rechts und links sieht man die Scenery mit TMVL19 in der Mitte mit 18. Bei TMVL 19 sieht man im Bereich der gelben Pfeile das mein gewelltes LOD9 Mesh dargestellt wird. Im Gegensatz dazu sieht man in der Mitte bei TMVL18 das es nicht mehr optisch dargestellt wird. Es wird jetzt im Prinzip jeder zweite Höhenpunkt ausgelassen. Es werden quasi Wellenberg mit Wellenberg verbunden. Es entsteht eine ebene Fläche. Das ganze muß man quadratisch sehen also in alle Richtungen. Wie die Verbindungen zu stande kommen also (Wellenberg mit Wellenberg) bzw. (Wellental mit Wellental) hängt vom ersten Wert ab mit dem das Mesh in der Nordwestlichen Ecke anfängt. Jean hat den Wert raufgesetzt damit sein LOD11 Mesh als solches dargestellt wird. Andernfalls würde es nur als LOD10 bzw. LOD9 dargestellt.

Was hat man nun für Nachteile. Das Mesh lässt einen häufigeren Höhenwechsel zu und damit auch steilere Flanken. Ev. reagiert darauf unsere Landclassengine. Man erhält einen automatischen Wechsel der Texturen. In unserem Beispiel schön zu sehen. Bei TMVL19 im Bereich der blauen Pfeile. Hier waren bei meinem Landclassfile auf dem Mesh mal Felder bei der Flanke zum See waldähnliche Texturen siehe auch weisse Pfeile. Nun hat man einen Wechsel zu Wald im Mesh bzw. an der Flanke zum See Gebirge. Man kann auch sehen das der See auf der linken Seite steiler zum Mesh abfällt als auf der rechten Seite.

Diese Effekte findet man natürlich genau so bei den Airportflattenpolys vor.

Ganz kurz noch zwei Dinge. Der FS stellt nur eine ganz bestimmte Menge an Höhenpunkten optisch dar. Dieses muß man aber auf das Gelände selbst beziehen. Man muß sich das in etwa so vorstellen. Zwei gleich große Mesh mit LOD11 eines flach das andere zerklüftet. Bei TMVL21 wird man bei dem flachen ADDON Mesh keine großen Unterschiede sehen. Der FS muß anhand der Information in dem Meshfile (es werden genau so viel Höhenpunkte definiert) nichts groß darstellen an Gittermodell.

Die Terrain Engine erkennt das hier nicht viel zu berechnen ist. (Übrigends auch der resampler mit dem das Meshfile erzeugt wird erkennt dieses anhand der Rohdaten. Auch hier findet schon eine Komprimierung statt. Das erklärt warum zwei ansonsten identische Meshfiles mit unterschiedlichen Inhalt auch unterschiedlich groß sind obwohl sie identische Anzahl von Höhenpunkten enthalten. Das gilt jetzt für den neuen resampler. Die alte Version benötigt hierzu noch ein paar zusätzliche Dateien)

Kommen wir zurück zum zerklüfteten LOD11 Mesh. Hier gibt es genau soviel Höhenpunkte. Diesmal aber mit ständigen Änderungen. Die Terrain Engine merkt das es hier auf einmal viel zu berechen und an 3D Modell darzustellen ist. Genau wenn dieser Fall eintritt und es sehr viele Änderungen gibt, dann wirkt sich ein TMVL über 19 negativ aus. Ich hatte mal vor langer Zeit ein Bild ins Forum gestellt wo man das erkennen kann. Dem FS damals noch FS2002 geht die Puste aus. Er verschiesst mit TMVL sein Pulver quasi schon im Vordergrund. Es wird fast alles dargestellt was geht. Leider bleibt ihm dann nicht mehr viel in Richtung nach hinten , rechts und links. Da werden dann wesentlich weniger Meshpoints dargestellt als mit TMVL 19. Ich habe es damals glaube ich so definiert Vorne hui hinten pfui.

Wie gesagt diese Entscheidung muß jeder selbst treffen wo er nun mehr Wert drauf legt. Außerdem ist dieses dynamisch zu sehen. Es hängt halt vom Meshinhalt ab.

Bei manchen LOD11 Meshfiles werden bei TMVL21 übrigends Fehler sichtbar die vorher bei TMVL19 optisch weggebügelt sind.

Und zu guter letzt noch ein Problem von TMVL21. Es gibt die Möglichkeit der so genannten Remesh Funktion z.B über das Designtool Ground2K. Im Prinzip ist dieses eine Verwaltigung der LWM Funktion. Es können hier einzelne Höhenpunkte allein gesetzt werden. Der Vorteil hier bei ist das man auch kleine Bereiche mal eben schnell als Mesh erstellen kann. Es hat aber nichts mit einem echten Mesh zu tun wo man ja leider immer mindestens einen LOD Quadranten erstellen muß.

Etliche Designer nutzen auch diese Funktion. Man findet sie z.B in einer Frankreich Scenery oder eben auch in der Hamburg Scenery.

In dieser sind auch die Screenshots entstanden. Oben Hamburg Remeshbereich mit TMVL19 unten selbe Stelle mit TMVL21. Jetzt sind Pyramiden erkennbar. Grund ist folgender vorher konnte der FS mit TMVL 19 nicht jeden Höhenpunkt auflösen er lies nur LOD9 zu. Von daher werden bei remesh nur die einzelnen Höhenpunkte mit einer Oberfläche überspannt.
Mit TMVL 21 kann er auch die Höhenpunkte dazwischen darstellen. Nur dazwischen existiert nichts. Die Oberfläche sackt jetzt auf das reguläre Mesh ab. Dieses liegt aber auf nahezu 0 Meter. Es entstehen Pyramiden die jeden einzelnen Höhenpunkt erkennen lassen den Dirk bei seiner Brandenburg Scenery gesetzt hat.

Damit dürften die Probleme erkennbar sein mit denen man im FS zu kämpfen hat. Es ist immer ein für und wieder. Leider ist der FS nicht mehr so leicht verständlich. Es gibt viel neues. Nicht alle schönen Möglichkeiten sind kompatibel zu anderen Techniken. Scenerien können sich stören.

Globale Veränderungen in den CFG Dateien dürfen nicht kommentarlos bleiben der User muß wissen womit er rechnen muß. Er sollte auch die Probleme der Designer kennen. Den von Ihnen fordert man immer etwas neues. Bzw. ohne neues wird nichts gekauft bzw, nicht gelobt. Leider verbergen sich hinter jedem neuen Gefahren.

Das wollte ich mit diesem Beitrag rüberbringen.

Unten das Bild der Remesh Funktion von Hamburg. Oben mit TMVL 19 unten TMVL21.

Danke
 

Hallo Jobbia,


danke für Deine ausführliche Erklärung.
Wie man sieht, ist das nicht so einfach zulösen.
Aber hoffen wir, dass es uns gelingt.
Es wäre nämlich jammerschade ,wenn man Switzerland Pro im FS nicht voll benützen könnte.

Klasse, endlich mal umfassend und für die Materie einfach erklärt.
Wenn du das nächste mal eine Vorlesung gibst, sag bescheid. :)

Das größte Problem in der Zukunft sehe ich in dem Zusammenwachsen verschiedener Szenerien. Wenn jetzt z.B. Real-Germany 1 bis zur Schweizer Grenze wächst werden wir sehr warscheinlich Inkompatibilitäten haben. Und damit meine ich nicht die unterschiedlichen Texturen.

Ein Wunsch von mir für die neuen MS Version wäre, dass man Rainer Dudas Flüsse oder etwas ähnlich genaues integriert. Dazu die Strassen und Eisenbahnen. Dann würden diese wenigstens in D für alle Add-On Designer schon einmal richtig liegen. Natürlich würde man sich sowas generell wünschen.

Stellen sich diese Probleme nur bei uns? Wie schaut es in Amerika aus? Ist das Land zu gross und zu weit als dass sich die Leute um mehr Genauigkeit kümmern oder ist dort die selbe Diskussion und Problematik bekannt?

Hallo Jobia,

Respekt! Tolle Zusammenfassung.

Ich möchte diesen Eintrag zu gerne als "Sticky" hier im Forum sehen. Da werden einige Dinge angesprochen, die hier entweder schon oft Thema waren oder auch mit Sicherheit immer mehr Thema werden.

Meine "Fluss-Abdeckung" ist noch bei weitem zu gering, um daraus eine Art "Standard" machen zu können. Mehr ist leider für eine einzige Person nicht machbar; nur zu schade, dass dies kein anderer aufgegriffen hat. Es ist nämlich wirklich nur "Fleißarbeit".

Ich erwarte eigentlich entweder eine automatisierte Lösung (wobei die wohl leider auch nicht 100%-ig richtig korrekt sein kann) oder eine Lösung von Microsoft selbst (vielleicht im FS10). Ich kann als einzelne kleine Person zumindest nicht so einfach hergehen und zentrale bgl-Dateien des Flusis ändern, wie dies andere ja schon gemacht haben. Wäre aber wahrscheinlich eine kluge Idee, maximale Bereiche in Deutschland sowohl von Microsoft-Mesh- wie auch von Microsoft-LWM-Files zu bereinigen und dann das gesamte Gebiet komplett neu zu gestalten. Nur hören die gelöschten oder umbenannten Files halt nicht einfach an Landesgrenzen auf, d.h. ich würde damit wieder andere beeinflussen usw. usw...

Mal gespannt, wie dies dann bei der Austria-Professional geregelt sein wird. Unsere Ländergrenzen in Europa sind halt "zerklüfteter" und gebietsweise kleiner wie die große USA, wo man solche Probleme wahrscheinlich niemals haben wird.

Ciao,
Rainer.

Gute Darstellung des Problems, Joachim.

Kannst du zukünftig bei vielen Szenerien anhängen, wenn es keine Möglichkeit für einen Excludebefehl für Flatteneinträge von Originaldateien gibt.
Bevor man Wünsche für den FS 10 an MS schreibt, sollte man dies als Priorität für FS 9 sehen. Es sind Informationen von MS unbedingt notwendig.
Sonst kommt es zu einem Chaos.

Die Deaktivierung von Originaldateien bedeutet ca 64 LOD 5 cells (N-S ca München-Venedig)
Die Manipulation dieser Dateien durch Löschen seines Gebietes in der Originaldatei, wird Probleme mit den „Anrainern“ verursachen. (es gibt nur eine Originaldatei)
Derzeit vielleicht sinnvoll, LWM durch Ludowise und Knoblauch.
Linien bleiben vorhanden.

Eingriff in die Steuerungsdateien (cfg) sind nicht sinnvoll, da sie eben globale Auswirkungen haben. Der Anwender soll dies selbst entscheiden. Er stellt auch alles andere selbst ein.

Wenn man nur in einem kleinen Gebiet herumfliegen will, kann man dies alles machen und bestimmte Szenerien anpassen. Aber wenn man auch in anderen Gegenden und angrenzenden Szenerien unterwegs ist, machen diese Eingriffe keinen Sinn. Jede Szenerie braucht dann andere Einstellungen bzw. Originaldateien.

Wie man dies während des Überfluges der Szenerie ändert (wenn man auch angrenzende Szenerien hat), darf jeder selbst überlegen.
Ich überlege es nicht, da es nicht funktioniert.

@Rainer
Bin auch sehr gespannt, wie dieses Team das Problem löst.

Horst

Ich hatte ja schon stark mit dem Gedanken gespielt mal alle Hauptstraßen und Autobahnen für Deutschland umzusetzten, aber das scheitert an meiner freien Zeit. Es müsste ein Tool geben womit man die vorahnedene Vektordaten auslesen kann (z.B. aus den Garmin MapSource CD's oder irgendwelchen Routenprogrammen), man hätte auf einen Schlag alle Straßen, Gewässer, Wohnorte und Industriegebiete... sicher eine Utopische Vorstellung, vor allem da man die Daten wohl nicht einfach verwenden dürfte.

Vielleicht erbahmt sich M$ ja mal sowas umzusetzen...

Bis dahin träume ich weiter...