LOD 10 mesh Darstellung und Fehler
 

Hallo,
Ich habe keine Ahnung, wo ich die Frage jetzt anhängen soll.
Joachim hat im Software Forum sein Mesh Testfile erwähnt.
Mit diesem File kann er einfach LOD9, LOD10, oder LOD11 darstellen und die Fehler erkennen im FS9.
Mich hat nur seine Aussage LOD10 stimmt auch nicht richtig, verunsichert.
Ich könnte ja jetzt ein Mail an Joachim schreiben.
Er liest aber auch die Beiträge hier, und vielleicht hat ja auch noch jemand anderer einen ergänzenden Kommentar.

Ich erzeuge mir derzeit ein Schweden Mesh und wollte versuchen dies in LOD10 darzustellen, da mir der Einfluss durch die Linien durch LOD10 und TMVL 20 schöner und angenehmer erscheint. Bzw. will ich meine eigenen „alten“ Mesh files umstellen.

Um mir hoffentlich Arbeit zu ersparen, ein paar Fragen, (vor allem an Joachim):
Hast du dein Testfile an die Darstellung und Auflösung der einzelnen LOD Level angepasst?
Oder hast du es ganz einfach in einen anderen LOD Level „resampled“?
Welche resample.exe verwendest du?

Warum die Fragen?
Ich möchte für mich selber herausfinden, worauf ich aufpassen muss.
a)Wie ich die Daten interpoliere (oder auch annähere) und mit welcher Methode und Auflösung?
b)Welches resample tool geeignet scheint?

Damit ich für mich klären kann:
a)Die Daten die ich dem resample tool zur Verfügung stelle sind nicht passend?
b)Das resample tool verursacht die Fehler?
c)Die Darstellung der bgl Datei im Zusammenhang mit TMVL erzeugt den Fehler im FS?
Ergänzend: meistens verwende ich Höhenlinien oder x,y,z Daten. Aber auch Daten in einem Grid.

Horst

Re: LOD 10 mesh Darstellung und Fehler
 

Zu


Zunächst mal vermute ich das Du auf Diese Aussage von mir anspielst:

"So und jetzt kommt es. Wie sieht das selbe Testmesh im FS2004 aus. Bild siehe Anhang. Fakt ist ein LOD10 mesh wird im FS2004 angezeigt. leider aber nicht korrekt. Es müssten 1000m hohe Nadeln sein. Sind es aber nicht. Es gibt hier irgendwelche Störungen. Auch verhält sich das etwas anders wenn ich den TMVL von 21 auf 20 runtersetze. Dann sieht es anders aus ist aber immer noch nicht 1 zu 1 umgesetzt.

Gehe ich auf den Defaultwert TMVL 19 wird auch das LOD10 Mesh nicht dargestellt ich habe wieder ein flache Fläche mit 500 Meter also den Basisbodenwert meines Testmesh".

Also es war bei mir folgender Maßen. Diese Testmeshfiles sind aus künstlichen Rohdaten entstanden die ich in einem RAW File definiert habe. Es stehen je nach Abdeckunsgfläche meiner Testfiles exakt (256+1)x (256+1) oder aber z.B (1280+1)x(1280+1) Höhendaten zur Verfügung. Meine Files decken also exakt einen oder mehrere LOD Quadranten ab. Ich denke diese Problematik warum +1 ist Dir bekannt.


Auch in der .INF Datei ist dieses so definiert. Weiterhin lasse ich mein Meshfile exakt auf dem LOD Raster der Quadranten starten. (gemäß dem verwendeten LOD Level) Weiterhin ist der Abstand der Höhenpunkte sowohl in X als auch Y Richtung exakt im LOD Raster angegeben. Dieses hat im Gegensatz zu realen DEM Rohdaten den Vorteil das die resample.exe nicht interpolieren muss, sie dient nur zur BGL Erzeugung mit anderen Worten eigentlich nur noch zu Header Erzeugung und der Kompression der Daten. Daher ist es auch egal welche der mittlerweile 3 resample.exe Versionen ich verwende. Alle setzen ideale Rohdaten 1 zu 1 ohne Fehler um. Meine fertigen BGLs kann man schön mit dem TMF Viewer kontrollieren das bestätigt auch den Sachverhalt das 1 zu 1 umgesetzt wurde.

Von daher sind meine Meshfiles sicher ich kann eine 100% Aussage machen was ich dem FS anbiete.

Meine Aussage in Bezug zu LOD10 bezog sich daher auf eindeutige Daten.

Das Problem ist also nicht der Weg vom DEM zur BGL sondern das der FS2004 diese eindeutigen Daten der BGL nicht 1 zu 1 umsetzt.

Der FS2002 kann es der FS2004 nicht.

Dem zu Folge ist daher auch zu erwarten das der FS2004 auch bei realen LOD10 Mesh Daten Fehler produziert wird. Das ganze ist wie gesagt zunächst komplett unabhängig von der verwendeten
resample.exe.

Zur Anmerkung ich erwähnte auch das meine Testdaten natürlich extrem sind und in der Realität recht selten anzutreffen sind. Denn wo hat man schon real ein Geländeabsturz innerhalb ca. 38m von 1000m auf 500m. Ev. im Grand Canyon auf jeden Fall bei den Angel Falls in Venezuela. Da sind es ja fast 1000m Höhenunterschied wenn ich mich recht erinnere. Fantastisch das es so etwas überhaupt gibt.

Wie mein Test beweist hat der FS2004 aber auf jeden Fall Probleme das was definitiv als Höhenpunkt in der BGL steht 1 zu 1 im Gelände umzusetzen.

Da ja der Patch kommen soll wird wohl nichts dagegen sprechen Dein Mesh in LOD10 umzusetzen ich denke der Bug wird wohl behoben werden.
Ist das nicht der Fall wäre es ja auch kein Thema Deine Rohdaten später ev. nochmal über die resample.exe zu jagen und ein LOD9Mesh zu erzeugen.

Übrigends mit diesen künstlichen Rohdaten kann man natürlich sehr gut das Interpolationsverhalten der resample.exe testen.

Das habe ich Spaßhalber mal im Zuge meiner LC Doku gemacht. Daher kann ich sagen das die resample.exe so intelligent ist das sie anhand der .inf Datei bei LC merkt das sie nur als Flächeninterpolator arbeiten darf nicht aber als Interpolator in der Wertigkeit der Bytes.

Wäre auch schlecht das würde hinterher im FS zu ganz falschen LCs führen.


Ich weis nicht wie diese Global Landclassdaten die schon mehrfach erwähnt wurden vorliegen. Sollte man diese als RAW Daten in Photoshop öffnen können, dann könnte man diese mit geringer Vorarbeit sogar direkt der resample.exe zuführen und dort die flächenmäßige Interpolation durchführen.

Ich persönlich habe aber damals als ich nach Möglichkeiten der großflächigen automatischen Landclassproduktion gesucht habe die Interpolation immer im Fotoprogramm erfolgen lassen. Denn da hatte ich die Möglichkeit das eine Basiskarte als Demo als Ebene dahinterlag. So konnte ich die Qualität der Interpolation vorab kontrollieren und Gegenmaßnahmen einleiten. Mit anderen Worten ich habe der resample.exe immer Daten zugeführt die ideal waren. So kann ich sicher sagen es wird das 1 zu 1 umgesetzt was ich auch anbiete unabhängig vom resampler.

Damit kommen wir zu Deiner anderen Frage.

Denn genau hier ist das Problem. Die resample.exe Varianten die es gibt haben unterschiedliche Interpolierungsverhalten. Meine Aussage bezieht sich aber nur auf die beiden älteren Varianten (die neue des FS2004 habe ich in Bezug zu interpolation nicht getestet da ich wie gesagt ideale Daten verwende)

Fakt ist bei Fotosceneryprogrammierung sieht man die Unterschiede der Qualität am besten. Hier schneidet aus meiner Sicht der ganz alte resampler besser ab als der aus dem FS2002 SDK.

Was natürlich nicht bedeutet das dieses auch für Mesh zutrifft.

Da müsstest Du dann mal Vergleiche Deiner fertigen BGL (aus den verschieden resample.exe) mittels TMF Viewer und Deinen realen DEM Daten in z.B Microdem anstellen. Da dürfte sich rauskristallisieren welche resample.exe das beste Ergebniss liefert. Ich würde den Test aber nur in möglichst gebirgigem Gelände durchführen. Ich denke nicht das flache Gegenden den verschiedenen resample.exe Versionen Probleme bereiten.


Den FS lassen wir zunächst aufgrund der Fehler lieber außen vor um ein Mesh zu beurteilen.

Der Nachteil bei der alten reample.exe ist das er keine BGLs erzeugt sondern nur ein TMF File. Es werden weitere Tools benötigt. Es muss über Batch oder Kommadozeile noch die Datenkompression mittels TMFCOMPRESS.EXE erfolgen weiterhin die Kompilation in die BGL mit TMF2BGL.EXE

Ich hoffe das Dir das etwas weiter geholfen hat.

Hallo Joachim,

Natürlich helfen solche Informationen weiter! Herzlichen Dank.
Nur diese Vergleiche dauern ewig lange. Darum frage ich lieber, bevor ich mir dies antue.

Ich vertraue dem resample Tool eben nicht ganz, bzw habe ich dies nicht ausprobiert.
Man kann die Rohdaten auch vorher interpolieren, um eine ca. passende Abdeckung oder Auflösung zu erhalten.
Im Prinzip versuche ich es wie du, indem ich vorher die Rohdaten manipuliere, um die Daten etwa 1:1 dem resample tool zu präsentieren.
Natürlich habe ich sie dann verändert. Aber besser ich mach es, als das resample tool.
Und die Interpolationen (der Rechenvorgang) vorher und die verschiedenen Varianten, dauern schon manchmal Stunden für ein kleines Meshfile.
Daher will ich die Rohdaten auch nicht ohne „Vorarbeit“ in einem anderen LOD Level generieren.

Ich bin eher der visuelle Typ (Einfluss von anderen Daten auf mesh) Im Prinzip ist ja nur wichtig, was ich im Flusi sehe, und wie dieser die Daten darstellen kann.
Der Patch wird hier sicher weiterhelfen (meine Vermutung).

Zu LC:
Luis Sa hat einen Link in seinem Forum, wo man diese Daten für Europa runterladen kann (erreiche das Forum derzeit nicht, sonst hätte ich den Link geschrieben).
Wenn du sie in einem bestimmten Format brauchst, sende ich es dir.
Wichtig, wie du schreibst, ist aber immer eine Basiskarte, wo dies relativ genau eingezeichnet ist (auch Landsat!). Ansonsten verlässt man sich nur auf die angebotenen Daten. Im Prinzip, wie bei SRTM – manchmal stimmst, manchmal eben nicht.

Jedenfalls Danke
Horst

Hört zwar nicht hierher vielleicht liest der eine oder andere aber hier mit. Ich erwähnte oben beim Mesh die Angel Falls. Ich finde es einfach beeindruckend diese Daten des Wasserfalls bzw. diesem realen Absturz im Gelände man müsste glatt mal schauen wie es im FS dargestellt ist. ev. mit einem verfügbaren ADDON Mesh.

Wer sie nicht kennt ein Auszug eines Artikels über die realen Angel Falls.

"Der Salto Angel (Salto del Angel; dt. Angel-Fälle) ist mit 978 Metern (größte Stufe 805 m) der höchste freifallende Wasserfall der Erde. Er befindet sich im Süden von Venezuela, in der Gran Sabana und liegt im Zufluss des Rio Carrao.

Entdeckt wurden die Wasserfälle erst 1937 durch den amerikanischen Buschpiloten Jimmy Angel (daher auch der Name Angel-Fall) der auf dem Auyan-Tepui notlanden musste. Drei Tage soll Jimmy Angel für den Abstieg und das Erreichen der nächsten Ansiedlung benötigt haben".

Unten ein Doppelbild dieses beindruckenden Geländes. Ich finde die Natur faszinierend.

Bei solchen Kannten wie bei diesen Fällen würde ich eher dazu tendieren das Mesh etwas tiefer anzusetzen und dann ein gmax Objekt fein ausgestalltet darüber zu designen. Da muss man wenigstens nicht auf Details verzichten und die Wände lassen sich ordentlich texturieren.

Oder gibt's im FS9 noch die Möglichkeit von Nicht-Symmetrischen-Mesh?

Ich denke eine halbwegs realistischen Absturz mit Mesh bekommt man einmalig schon hin. Notfalls über ein sogenanntes LWM Poly.

Allerdings auch nur mit dem LOD Level des Mesh das es bei LOD11 Probleme gab und bei LOD 10 auch nicht ganz sicher ist wird dieser Absturz/Höhendifferenz auf jeden Fall von 1000m auf 0m innerhalb 76m möglich sein. Bei so einem Absturz ist die dann zur Anwendung kommende LC Gebirgstextur aber extrem versaut und verwaschen. Da wäre dann ähnlich wie Du vorschlägst ein Einfügen eines im Mesh versenkten 3D Objektes welches man mit einer schönen Felstextur verkleidet optisch vermutlich sehr angenehm. Theoretisch wäre so auch eine nach innen geneigte Fläche möglich also ein Felsüberhang.

Hallo,
Wäre wirklich sehr interessant, solche Gebiete zu versuchen darzustellen.
Wird halt sicher schwer sein, geeignetes Material zu finden.

Horst

PS:
Da mir die Software threads zu „bunt“ zu dem Thema Patch sind.
Sion kracht bei mir nicht mehr, auch mit der original terrain.cfg.

Hast Du auch mal in SION getestet und hier den TMVL erhöht denn ansonsten crashte es dort nicht. Es sei denn man hat eines der Addon Meshfiles die damals genannt wurden. Außerdem trat es nur an zwei Monaten im FS auf. Weis allerdings nicht mehr welche. ev. Dezember, Januar vielleicht hatte ich das sogar in meiner Doku stehen.

Aber ich vermute hier gibt es jetzt auch ein Problem das zu simmulieren.


Irgendwer äußerte das der TMVL anders definiert ist. Es wurde eine 3stellige Zahl erwähnt. Jetzt hat man natürlich kein Vergleich mehr was TMVL21 nach dem Patch entspricht. Habe selbst den Patch noch nicht gewagt zu installieren weil ich keinen Platz habe meine Partition zu sichern.

Ich bin aber ohne Zweifel das MS das Problem behoben hat. Nur mit der Erklärung die sie liefern da habe ich so meine Interpretationsprobleme. Werde aber wenn es bei den Airportpolys so bleibt wie es beim Default der Fall war also unpassender Chamäleoneffekt wohl meinen Patch zusätzlich weiterverwenden.

Ja, auch wenn ich den TMVL auf 21 erhöhe. Kein Crash. (Habe den alten thread nochmals gelesen)
Falls du den:
TERRAIN_EXTENDED_LEVELS=1
meinst in der fs9.cfg?
Der war und ist bei mir gleich.
Die fs9.cfg wurde nicht angefasst(soweit ich es verglichen habe), sonst hätte man sie auch gesichert.
Es wird ein Backup-Ordner angelegt, wo die derzeitigen Daten (dll, cfg, exe, generic.bgl) hingespeichert werden.
Ich hänge dir ein zip-file an.
Eines ist die bak datei in Textformat, die andere ein Installtionsprotokoll, wobei nicht alle Module aufgeführt sind.
Es ist ein RTF Patch.
Also: Modules, FS9.exe, display.cfg

Angaben ohne Gewähr.

Horst

Ich habe jetzt schon von 2 Leuten gehört das der TMVL eine andere Dimension haben soll. Demnach müsste die FS9.CFG nach dem Patch geändert sein. Also könnte bei Dir oder bei den anderen was in die Hose gegangen sein.

Danke für die Info denn da offensichtlich Dateien geändert und nicht unbedingt neu installiert werden würde auch eine Cleansweep LOG Datei nichts nutzen. Das einzigste was unabhängig funktioniert und repräsentativ ist, ist vermutlich die Suche nach Änderungsdatum von Dateien global über den FS Pfad bzw. zusätzlich den der Anwender wo auch die FS9.CFG steht.

Und ev. das Registry durchsuchen.

Ich habe auch von jemand eine Info über den Inhalt der terrain.cfg nach dem FS2004 Patch bekommen.

Dieses ist immer noch meine Version. Da kann jetzt sein das der FS Patch hier verweigert hat da sie nicht original war. (ich erwähnte gestern morgen, es war glaube ich noch vor fünf das man vor dem Patch die Default terrain.cfg einspielen soll)

Auf jeden Fall muss man die terrain.cfg zum testen gegen die default ersetzen. Ev. ist bei Dir nach dem Patch auch noch meine aktiv. Wobei ich natürlich wie gesagt davon ausgehe das der FS9 Patch die Fehler behebt.

Übrigends auch die ATP2004 soll Änderungen der terrain.cfg vornehmen.

Falls Du diese hast würde meine eh nicht mehr den original Zustand haben.

Ich vermute wenn die FS9.cfg geändert wurde, dann nicht wärend der Installation des Patches sondern beim ersten Ausführen. (Eine Art "Selbstreperatur", was der Flusi ja durchaus schon immer so gemacht hat.)

Ach ja, falls ihr tatsächlich von TERRAIN_MAX_VERTEX_LEVEL=19 redet, der ist bei mir immer noch zweistellig. (BITTE keine Abkürzungen hier, das führt nur zu Verwechslungen.)

Ja, kann ich auch bestätigen,

der TMVL ist immer noch zweistellig - der Wert wurde nicht geändert. Auch scheinen keine neuen Einträge hinzugekommen zu sein. Einige, wenige Werte wie Sichbarkeitsradien etc. wurden aber geändert. Aber auf den ersten Blick nichts Außergewöhnliches.

Auf CTP habe ich aus Zeitmangel noch nicht getestet.

Gruß
Thomas

Hallo,

TMVL wird durch den Patch NICHT angefasst. Habe mit mehreren Testrechnern und ein paar Installationen etc... ein paar "Versuche" durchgeführt. Muß ja doch zu was nütze sein, der Beruf den man ausübt.

Aber anders als zuvor erkennt man jetzt wirklich Terrain-Unterschiede bei den verschiedenen TMVL-Einstellungen. Ok... Unterschiede sah man vorher auch, aber jetzt passen - zumindest bei mir - einzelne Höhenpunkte.

Ciao,
Rainer.

Hi Rainer,

welcher TMVL ist denn nun empfehlenswert? Einige Addons "pfuschen" da ja ganz gewaltig rum. Ich gehöre zu den "glücklichen" mit dem FSG 38m Mesh, reicht TMVL 20 oder ist 21 erforderlich?

Hi Börries,

20 reicht für die schönen amerikanischen FSGenesis- oder Taburet-Meshs völlig aus. Wir sprechen da ja mit unseren VFR-Flügen die gleiche Sprache.

21 wurde bisher - meines Wissens nach - u.a. von Madeira genutzt. Ob dies aber nötig ist?

In meinem neuen Ostwestfalen werde ich aber wohl zumindest die 21 als Option vorschlagen. Gerade bei einem gerade von mir im Bau befindlichen Platz ist diese 21 sogar eigentlich dann Pflicht, soll das Mesh wirklich dem Platzzustand nahekommen.

Von der Performance ist mir bei gestrigen Testflügen auf meinem System auch kein großer Unterschied zwischen 20 und 21 aufgefallen.

ABER: Ich habe bei einem relativ bekannten kommerziellen Mesh durch die 21 fehlerhafte Spitzen drin. Muß mal noch näher rumprobieren, ob da tatsächlich dann irgendwie der Wurm reinkommt oder ob ich da selbst was reingehauen habe. Habe nämlich andererseits ein anderes kommerzielles Mesh, dass diesen Fehler an gleicher Stelle nicht ausgelöst hat und dies würde ich dann speziell bevorzugen. Aber keine näheren Kommentare dazu. Dies war schließlich mit dem FS9-Urzustand nicht festzustellen und jeder hat jetzt die Chance, eventuell nachzuziehen.

Ciao,
Rainer.

Danke Rainer,

aber was ist denn dann mit den 9,6m Meshes (Yellowstone, Hawaii, Monument Valley, Grand Canyon, alles FSG)?

:D Erwischt. Die habe ich nicht (bis auf die Grand Canyon). :D
Probiere es mal aus.

Ciao,
Rainer.

Also 9,6m Mesh halte ich für maßlos übertrieben. Da geht im Hintergrund zuviel verloren. So ist mir das zumindest bei meinem PC schon bei 19m aufgefallen.

Hallo,
Die Empfehlung für solche globalen Änderungen sollte man schon bedenken.
Ersetzen, durch Installationsprogramme, wird man sie hoffentlich auch nie.
Weiters würde ich auch bedenken, wie weit der Radius der dargestellten Mesh files reicht.
Die Performance wirkt sich eigentlich nur in der Darstellung (Grafik) aus. Kann aber in „engen“ Gebieten (sehr viele Informationen – auch Flugzeug bedenken) sehr stark sein.

Auch der Einfluss von der terrain.cfg durch den Wert offset für die verwendete Textur ist extrem. Auch im Flachland – und die Einblendung der Landklassen (abhängig von Neigung) - wirkt extrem.

Nur für eine kleine Szenerie: nein. Solche Werte sollten mit Bedenken geändert werden.

Abgesehen, dass es bei Verwendung, Update – nicht Update, Unterschiede gibt.

Horst

Kann ich Dir nur zustimmen Horst

@Horst, @Joachim

Eure Einwände sind schon bei mir angekommen, zum Glück gibts ja die Möglichkeit den FS mit unterschiedlichen fs9.cfg´s zu starten, alleine schon wegen unterschiedlicher Eingabegeräte etc.

Beim Mesh mach ich es halt dann genauso, mir gings auch hauptsächlich um eine generelle Aussage, ob sich eine Änderung der TMVL jetzt ( positiv ;) ) auf die Darstellung der jeweiligen Meshes auswirkt.

Auf jedenfall trifft das für die 38m Meshes zu, wie ich gestern in den Cascaderange Mountains (FSGenesis-Mesh) feststellen konnte; die Berge wirken einfach lebendiger.

Also für mich ist der Patch (das Update) auf jedenfall ein positiver Schritt gewesen.

Schöne Grüsse

Boerries

@Buschflieger
Hallo,

Der Thread stammt eigentlich von Donnerstag – der Update wurde Samstag herausgebracht.
Die Frage habe ich eigentlich nur gestellt, für 76m zu 19m (Bild Avsim Conference) aus einem anderen Beitrag hier. Ob tatsächlich LOD 10 korrekt dargestellt wird.

- die Berge wirken einfach lebendiger

Ich habe hier einmal etliche Fotos angehängt:
http://www.wcm.at/forum/showthread.php?threadid=145644

Leider darf man jetzt wieder anfangen (sehr mühselig), weil die Information zu dem Update gering sind – und die Auswirkungen überprüfen.
D.h, ob du tatsächlich die Punkte siehst, die du sehen sollst.

Wenn es dir so besser gefällt, und keine anderen Probleme verursacht, lass den Wert. (Ich denke Holger hat sicher eine Empfehlung in der Readme. Habe ich jetzt nicht gelesen).

Es ist nicht nur Genauigkeit, sondern auch Geschmack. Welche anderen Daten dadurch zerstört, bzw. nicht richtig angezeigt werden, zeigen dir vielleicht meine Fotos.
Joachim hat sehr viel bereits darüber geschrieben.

Horst