Freeware 38m Mesh für die Alpen

[BC_Holger]

Hallo zusammen,

eine neue Version des Patches fuer die Problemstelle in Salzburg, sowie fuer zwei Gipfel in den franzoesischen Alpen, ist jetzt hier erhaeltlich: http://forums.simflight.com/viewtopi...=299577#299577

Lasst mich wissen, ob es dieses Mal klappt wie geplant

Ciao, Holger

[Falko]

@Holger

<Falko, ich gebe dir natuerlich Recht, dass eine Kompilierung von kleineren Zellen das Updaten vereinfachen wuerde. Allerdings wuerde das den Modemnutzern nur bei Patches helfen, denn das Gesamtpaket muessen sie ja so oder so laden.>

- Genau das meine ich, es würde das Ausbessern von Fehlern sehr vereinfachen.

<Ausserdem scheint die Groesse der Teilstuecke das Ladeverhalten (d.h. die Prioritaet) zu beeinflussen, zumindest waere das eine logische Erklaerung fuer das Phaenomen, das Joachim und ich weiter oben angesprochen haben.>

-Das ist ja gerade das Problem, man kann große Teile nicht mit kleineren Teilen mit gleichem LOD überschreiben. Sind alle Teile klein kann man sie einfach austauschen.

<Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.>

-Also, ich hab das für Deutschland in LOD9 mit den inf-Dateien gemacht. Das sind inzwischen sogar 99 Dateien. Für die Rastergrenzen habe ich die den HGT-Dateien entsprechenden Grenzen gewählt, jeweils die nächste LOD9-Grenze nördlich oder östlich zu den HGT-Grenzen. Falls man sich auf so eine Norm einigen könnte wären die verschiedenen Mesh's kompatibel zueinander. So habe ich z.B. für Deutschland vier verschieden Mesh's von gleicher Qualität die alle nicht zueinander passen.
Falls Du für Dein LOD9-Puffer-Mesh auch die erste LOD9 Grenze nördlich des letzen verwendeten nördlichen Breitengrads gewählt haben solltest, hätte man einen Nahtlosen Übergang von Deinem Alpen-Mesh zu meinem Micro-Tile-Mesh für das restliche Deutschland. Die LOD Grenzen kann man sehr einfach berechnen.

Gruß, Falko

[Jan-Paul]

Hi,

ich habe das Prioritäten Problem mit Austria Pro und FSGlobal bei mir folgendermaßen gelöst.

Statt FSG verwende ich das Mesh von Yohann Baptiste welches Großflächiger als FSG ist. Man muß aber Trotzdem den FS in Salzburg starten damit Austria Pro auch zur anzeige kommt. Damit FSG sich nicht vor das Baptiste Mesh schiebt, habe ich die entsprechenden FSG BGL's (L9N1601.BGL bis L9N1604.BGL) entfernt.

[JOBIA]

Zu
"Das ist ja gerade das Problem, man kann große Teile nicht mit kleineren Teilen mit gleichem LOD überschreiben."

Eben nicht so haben wir es z.B bei ATP das kleine FS Global Teile das großflächigere ATP Mesh überschreiben (also genau umgekehrt wie Du schreibst), aber eben nicht überall.

Da hört leider noch sehr viel mehr zu dieser Problematik.

[oscar.o]

jedenfalls hat das letzte update von Holger seinen Zweck erfüllt, die Salzburg Attraktion ist nun verschwunden, herzlichen Dank hierfür!

Gruß

oscar.o

[nautic]

Hat hier noch jemand einen CTD gehabt? Ich bin mir immer noch nicht sicher, ob es an den Altiports (Courchevel etc.) liegt, an den Meshes oder beidem?

[JOBIA]

Zu

Original geschrieben von Falko
@Holger

<Falko, ich gebe dir natuerlich Recht, dass eine Kompilierung von kleineren Zellen das Updaten vereinfachen wuerde. Allerdings wuerde das den Modemnutzern nur bei Patches helfen, denn das Gesamtpaket muessen sie ja so oder so laden.>

- Genau das meine ich, es würde das Ausbessern von Fehlern sehr vereinfachen.

<Ausserdem scheint die Groesse der Teilstuecke das Ladeverhalten (d.h. die Prioritaet) zu beeinflussen, zumindest waere das eine logische Erklaerung fuer das Phaenomen, das Joachim und ich weiter oben angesprochen haben.>

-Das ist ja gerade das Problem, man kann große Teile nicht mit kleineren Teilen mit gleichem LOD überschreiben. Sind alle Teile klein kann man sie einfach austauschen.

<Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.>

-Also, ich hab das für Deutschland in LOD9 mit den inf-Dateien gemacht. Das sind inzwischen sogar 99 Dateien. Für die Rastergrenzen habe ich die den HGT-Dateien entsprechenden Grenzen gewählt, jeweils die nächste LOD9-Grenze nördlich oder östlich zu den HGT-Grenzen. Falls man sich auf so eine Norm einigen könnte wären die verschiedenen Mesh's kompatibel zueinander. So habe ich z.B. für Deutschland vier verschieden Mesh's von gleicher Qualität die alle nicht zueinander passen.
Falls Du für Dein LOD9-Puffer-Mesh auch die erste LOD9 Grenze nördlich des letzen verwendeten nördlichen Breitengrads gewählt haben solltest, hätte man einen Nahtlosen Übergang von Deinem Alpen-Mesh zu meinem Micro-Tile-Mesh für das restliche Deutschland. Die LOD Grenzen kann man sehr einfach berechnen.

Gruß, Falko

Nun zunächst mal verwendest Du unkorrigierte SRTM Meshdaten. Ich glaube das ergibt eh keinen Sinn diese Daten die ja jedermann ohne Basiswissen per SRTM Tool einfach innerhalb weniger Minuten in eine FS Mesh BGL resampeln kann zu nutzen.

Leider gibt es die sinnvolle Korrektur selbst in einigen Addon Meshfiles nicht.

Warum ergibt es aber keinen Sinn Microfiles zu machen.


Klar wäre das praktisch wenn man mal bei Bugs kleine fehlerhafte Teile wie jetzt geschehen austauschen kann.

Nur nutzt man unkorrigierte SRTM Daten, dann würde ich schon sagen, das man die ganze Alpenregion als einen einzigen Bug bezeichnen könnte, selbst wenn sehr vieles korrekt ist.

Außerdem entstehen hier wieder hunderte an Dateien wie man ja bei Dir schon (jetzt schon 99 Stück) sieht.

Im Fehlerfall oder sinnvolle Priorität ist das überhaupt nicht mehr zu bewältigen.

Nehmen wir doch einfach mal die Bugs an Airports wie sie z.B Henning meldet. Also z.B auch Bodentexturflackerprobleme durch Wechselwirkung AREA16N Flatten, Runwaycode und Mesh.

Klar kann man das zunächst ermitteln in dem man irgendeine Scenery abmeldet. Nur will man dann hunderte BGls absuchen um die zu ermitteln um die es sich handelt. Der Aufwand welches Addon nun gerade hinsichtlich Priorität je nach Startort (der Bug den wir hier erwähnten) wird mit Microfiles noch unberechenbarer.



Was aber meiner Meinung auch dagegen spricht ist der Barth Effekt.

Kennst Du noch die ersten Barth Landclass LC Files für Deutschland?

Das was ich jetzt überarbeitet hatte, was man im Zuge des German Landscape Projektes Downloaden kann.


Der Verwaltungsaufwand für den FS wird sehr hoch. Man hat wesentlich längere Ladezeiten.

Da jedes Landclass und natürlich auch Meshfile einen Datenheader mit sich schleppt wird das Verhältnis Nutzdaten zu Datenheader extrem ungünstig.

Deckt ein File 300 x 300 km ab ist der Datenheader nicht anders als bei einem kleinen File welches nur 1km x 1km abdeckt. Nur das Du jetzt 90000 mal diesen Header der auszuwerten ist hast.

Ist natürlich jetzt ein Beispiel welches nicht ans LOD Raster angelehnt ist.

Das Prinzip ist aber leider so.

Weiterhin ist die Datenkompressionsrate der BGls bei großen Files größer als bei vielen kleinen.

Bedeutet hat man exakt identische Informationen für eine große Fläche, dann ist unabhängig vom Header das große File kleiner in den MBs als die vielen Einzelfiles die die selbe Fläche abdecken.

Meiner Meinung spricht sehr vieles gegen kleine Files.

Wenn man ein gutes perfektes Mesh hat, dann wird es auch keiner nötig haben hier irgendwelche Bereiche raus abzuschalten.

Wenn ich mal Mesh außen vor lasse und nehme mal Landclass, dann möchte ich behaupten das fast alle Anwender mittlerweile Chaos und keinen Überblick haben und kaum einer wissen dürfte welches Landclassfile wo gerade aktiv ist.

Das selbe gilt für Mesh auch. Wenn dann noch diese Microfiletechnik kommt ev. dann auch noch mit ein oder zwei Puffermesh die dann natürlich auch noch in Microtechnik sein sollten dann gute Nacht FS.

[JOBIA]

Zu


Aussage Holger

<Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.>


und Deine Antwort

-Also, ich hab das für Deutschland in LOD9 mit den inf-Dateien gemacht. Das sind inzwischen sogar 99 Dateien. Für die Rastergrenzen habe ich die den HGT-Dateien entsprechenden Grenzen gewählt, jeweils die nächste LOD9-Grenze nördlich oder östlich zu den HGT-Grenzen. Falls man sich auf so eine Norm einigen könnte wären die verschiedenen Mesh's kompatibel zueinander. So habe ich z.B. für Deutschland vier verschieden Mesh's von gleicher Qualität die alle nicht zueinander passen.
Falls Du für Dein LOD9-Puffer-Mesh auch die erste LOD9 Grenze nördlich des letzen verwendeten nördlichen Breitengrads gewählt haben solltest, hätte man einen Nahtlosen Übergang von Deinem Alpen-Mesh zu meinem Micro-Tile-Mesh für das restliche Deutschland. Die LOD Grenzen kann man sehr einfach berechnen.



Ok über die Größe eines Meshfiles habe ich ja schon geschrieben.



Ich denke nicht das Holger ein Problem hat die LOD Grenzen zu berechnen, es hört sich jetzt fast so an als wenn Du das so interpretierst.

Ich denke nur ihm ist der Aufwand zu hoch, weil er ebenso wie ich keinen Sinn darin sieht.

Welche Grenzen mal wählt ist jedem selbst überlassen. Das hängt nämlich zum Teil auch von den Rohdaten ab die man hat. Nicht jeder nutzt großflächige löchrige SRTM Daten.


In der Regel produzieren alle immerhin schon rechteckige Meshfiles.

Aber es gibt auch Extreme wie z.B bei der Swiss Pro. Man hat offensichtlich wirklich nur für die Schweiz Top Daten gehabt. Von daher ist das Swiss Pro LOD11 Mesh ein Mesh welches gemergt wurde.

Es ist ein Mesfile welches aber überhaupt nicht rechteckig ist. Es hangelt sich in kleinen LOD Quadranten um die Schweiz herum.

Trotzdem ist es sinniger Weise nur ein Meshfile.

Klar man hätte es auch anders mergen können. So konnte man aber den Speicherbedarf noch mals optimieren. Was hätte es gebracht große Teile außerhalb der Schweiz für die man keine Top Daten hat in LOD11 zu resampeln.

Ich denke zu einer sinnvollen Meshprogrammierung gehören einige Gedankengänge.

Aber ich gebe Dir in folgendem Punkt recht, sinnvoll wäre eine Einigung auf feste Größen der Meshumsetzung, z.B LOD5 Quadrant bei LOD9 oder ähnlich, denn dann bekommen wir auch diese unberechenbare Priorität in jedem Fall in den Griff

[nautic]

Hallo Jobia,

es scheint so, wenn ich Dich richtig verstehe, wäre es zu aufwendig, festzustellen, was und bei welchem Mesh zu einem CTD oder anderen Problemen führt.

Kann es nicht auch sein, dass in den Altports Landclassendateien versteckt sind, die diesen Landclass CTD auslösen, wenn der Texture ordner nicht leer ist. (gab es doch bei AROE). Oder bringe ich da etwas durcheinander. Sorry, mittlerweile verliere ich da die Übersicht, zum Mal mir die Materie fremd ist - auch wenn man durch Deine Beiträge einiges lernen, verstehen kann...

Im Anhang der scenery Ordner von Courchevel...

[nautic]

als jpg