simHeaven - OSM/W2XP-Szenerien für XP10

[alpilotx 111]

Mal so ein Gedanke zum Wasser "schnippeln": ich nehme mal an, dass du effektiv "nicht anderes" machst, als das Wasser zu "maskieren" (ja, bei manueller Arbeit sicher kein Pappenstiel). Nun, in der Tat könntest du dir das rein theoretisch durchaus einfacher machen, bzw. den Computer deutlich mehr in die Mitverantwortung ziehen. Denn, die Information darüber wo Wasser ist liegt ja bereits komplett in digitaler Form vor. In OSM natürlich (wem sage ich das ). Nun müsstest du "nur" noch die ganzen Wasser-Polygone aus OSM in ein Raster Format bringen (vector-to-raster Konvertierung in verschiedenen GIS Tools), und dann natürlich im selben Referenzsystem und selben Kachelgrößen extrahieren wie deine DDS Kacheln .... danach ist es nur noch eine "Kleinigkeit" halbweg automatisch die Differenz zu bilden.

Klingt natürlich deutlich einfacher als es ist, und es kommt natürlich stark darauf an was für Tool du hier einsetzen könntest / kannst. Ich persönlich würde (nein ich werde es mangels Zeit nicht selber tun) da in Richtung GRASS GIS (http://grass.osgeo.org/) denken, welches ja recht mächtige Operatoren zur Arbeit mit Raster und Vektor Geodaten bietet (auch die besagte vector-to-raster Konvertierung). Da könnte man vermutlich auch gleich in einem Tool alle oben benannten Arbeitsschritte abfrühstücken ... In sofern könnte mittlefristig durchaus nüptzlich sein sich mit diesem Biest ... ehm ... Tool anzufreunden (denn ja, GRASS ist sicher nichts für schwache Gemüter ... erst nach einiger Einarbeitung erschließen sich die viele der Vorzüge ... und Haken und Ösen). Die Stärken von GRASS liegen darin, dass im Prinzip alle Arbeitsschritte über skritbare Befehle ausgeführt werden (die gewöhnungsbedürftige GUI tut unter der Haube auch diese Befehle ansprechen).

Eventuell wäre auch ein Tool wie Diva-GIS dafür geeignet (soll recht mächtig sein, aber stärker GUI orientiert - selber habe ich nur wenig Erfahrung damit).

http://www.diva-gis.org/

[hrsoft 0]

Hallo Pilotbalu, vielen Dank für deine super osm scenery europe. du schreibst, von EDDM gibt es bereits eine Beta4. Kannst du mir sagen, wo ich die downloaden kann. Als Münchener wäre ich sehr beggeister davon. Viele grüsse Heinz

[simHeaven 1664]

Hier ist das Thema zu EDDM 4.0 auf x-plane.org:

http://forums.x-plane.org/index.php?showtopic=57995

Und hier geht es direkt zum Download der EDDM 4.0 beta (39):

https://www.disk.dsl.o2online.de/!#/FXHDjBR/X-Plane%2010/Upload%20EDDM%204%20Betas/

[simHeaven 1664]

Eventuell wäre auch ein Tool wie Diva-GIS dafür geeignet http://www.diva-gis.org/

Das sind wie immer sehr wertvolle Tipps von dir... Hab das Diva-GIS angeguckt, ok, nur das 77-seitige Handbuch überflogen, denke jedoch, dass ich mir die Einarbeitung sparen kann:

Bin nämlich gestern mal mit 2 umgebauten Kacheln geflogen, die Ladezeit geht gefühlt gegen unendlich... waren 22 Minuten bis X-Plane geladen war und der Speicher war zu 85 Prozent belegt. Ähm, ich habe 32 GB, also waren ca. (27 - 3 =) 24 GB von X-Plane belegt. Man kann somit kaum mehr als 2 Kacheln laden -> unbrauchbar! Auch wenn es mit dem HD-Mesh etwas schöner aussieht.

Das bringt mich auf eine andere Idee: Ich schicke dir die dsf-Dateien und du machst mir HD-Mesh rein! *frechgrins* Alternativ bräuchte ich was, wo ich nur ein oder 2 Knöpfchen drücken müsste. Dann könnte ich die dsf- Dateien in 3 Versionen machen:

1. Standard-Mesh in Terrain
2. HD-Mesh in Terrain
3. Overlay mit Polygonen

Durch einfaches Umkopieren bzw. Umbenennen der dsf-Dateien kann man von der einen in die andere Version "schalten", das ganze noch per Batch quasi auf Knopfdruck und wenn man das Plugin X-Reloaded hat auch während des Fliegens.

Was meinst du? Deine HD-Mesh in meinen Fototapeten? Geht das? Und ich geb dir bei Erfolg (ok, sonst auch!) ein Bierchen im Biergarten aus, vielleicht im Unicum wenn du eh am Turm bist...

[hrsoft 0]

Hallo Pilotbalu, danke für die rasche Antwort wegen EDDM 4 Beta. Leider kann ich mit diesen downladlink nichts downloaden, weisst du vielleicht noch eine andere Adresse?

[alpilotx 111]

Na du fragst mich was ... eines der wenigen Bereiche bei der Scenery, womit ich mich bisher wenig aktiv befasst habe is die Photoscenery (nicht lachen ). Von daher ist mir auch nicht ganz klar, wie da die Mesh rein kommt.

Mein Verständnis ist - und ich lasse mich gerne korrigieren - dass das photoscenery tool (G2XPL ???) die Texturen von Google zieht, und automatisch mit dem Mesh "verheiratet" (oder ist dass dann "draped" ? Was ich nicht vorstellen kann bei so großen Gebieten, da "draping" ja ab einer gewissen Größe Performancetechnisch ungünstig wird). Dann ist letztendlich ja "nur" die Frage, wo welcher Mesh Quelle sich G2XPL dann bedient? Von der HD Mesh oder Standard Mesh ....

... ach ja, aber - so langsam demmerts - ich vermute du möchtest eine DSFs nur einmalig erstellen lassen (von G2XPL) und nachträglich (ohne zweimal alles von Google holen zu müssen), die Mesh im DSF austauschen ... Hmm, na ja, das geht sicher, aber ich habe da auch kein Patentrezept für. Höchstwahrscheinlich könnte man das mit einigem an Skript Arbeit und DSFTool (mal nach TX konvertieren, alles austauschen was auszutauschen ist, wieder zurück nach DSF konvertieren) machen. Oder ich liege eh total falsch :-) ?

Übrigens verstehe ich nicht so ganz, warum bei deinen ausgeschnittenen Seen die enorme Ladezeiten entstehen. Vermutlich liegts aber auch daran, dass mir - da ich mich wie gesagt damit kaum befasst habe - nicht ganz bewusst ist, über welche technische Schiene du das machst.

EDIT: ich habe mich jetzt noch ein wenig "belesen", und bin der Meinung, dass bei einer großflächigen Photoscenery diese doch eigentlich über den MeshTool entstehen müsste/könnte. Der kann dann selber(!) eine passende Mesh aus Höhendaten dafür mit generieren (das lese ich aus der Douk da heraus: http://wiki.x-plane.com/MeshTool_manual#Commands_for_Working_with_Orthophotos). Da kann man dann sogar die Auflösung der Mesh in gewissen grenzen steuern. Aber möglicherweise funktioniert dein Tool (ist es denn nun g2xpl?) anders, und übernimmt irgendwie doch eine bestehende Mesh.

[LyAvain 121]

Irre...

*staunendes Schweigen*

Irre, irre, irre...

Ich hab heute mal testweise den Bereich um meinen Heimat Flughafen als Phototapete unter meine OSM Scenarios gepappt. Die Wirkung ist absolut Hammer.

Da ich gerne mit kleinen Maschinen durch die Gegend eiere und mich gerne an Landmarken orientiere, ist das perfekt für mich. "Kleine" Flussläufe wie Oker, Leine, Aller etc. sind da wo sie hingehören. Kleine Döfer sehen auch so aus, wenn keine OSM Objekte da stehen. So macht Sichtflug 100x mehr Spass.

Echt saubere Arbeit. Danke Dir PilotBalu.

Jetzt muss ich nur irgendwie hinkriegen, dass sich die Scenery Gebäude von EDVE nicht mit den OSM Gebäuden vermischen. Dann bin ich endgültig glücklich.

Liebe Grüsse

Ly

[simHeaven 1664]

Hallo Pilotbalu, danke für die rasche Antwort wegen EDDM 4 Beta. Leider kann ich mit diesen downladlink nichts downloaden, weisst du vielleicht noch eine andere Adresse?

Dann musst du wohl den Autor anschreiben, denke nicht dass er die noch wonaders publiziert.

[NorskCat 15]

Hallo Pilotbalu, danke für die rasche Antwort wegen EDDM 4 Beta. Leider kann ich mit diesen downladlink nichts downloaden, weisst du vielleicht noch eine andere Adresse?

Hm, ein Blick in den Thread Link von PilotBalu hätte dir auch diesen Post mit dem Download-Link vom Autor offenbart.

[simHeaven 1664]

Von daher ist mir auch nicht ganz klar, wie da die Mesh rein kommt.

Das funktioniert erstaunlich einfach: g2xpl konvertiert die Standard-ds-Datei aus der Global scenery, macht eigenes (u.a. die Terrains statt den Standard-Texturen dazu, und macht das ganze wieder zu einer dsf-Datei. Feddich!

Ich hab jetzt einfach deine HD-Mesh gegen die Standard-dsf ausgetauscht und g2xpl nochmal laufen lassen, aber nur bis die dsf erzeugt wurde und dann in den schon vorhandenen Ordner kopiert und geguckt. Die HD-Mesh ist drin, nur an den fast senkrecht abfallenden Wänden eines Berges da schmiert die Textur. Klar es wird ja von oben draufprojeziert und wenn das sehr steil ist, bleiben nicht viel Pixel pro Höhenmeter.

Ich lasse das ganze nun nochmal komplett rechnen, vielleicht behandelt g2xpl die Steilflächen anders und spendiert dor mehr Pixel. Wenn ich aus den .ter einfach .pol mache, sieht das hervorragend aus, wie auf einem Foto. Ich stelle später Bilder rein, wenn die Kachel neu gerechnet ist, hoffe, dass da noch was besseres rauskommt.

Die lange Ladezeit und der enorme Speicherbedarf liegt nicht an den ausgeschnitteten Seen, den hat man auch vorher schon, das muss an den Polygonen liegen. Ich meld mich nochmal, Bier kriegste natürlich trotzdem.

[simHeaven 1664]

Echt saubere Arbeit. Danke Dir PilotBalu.

Jetzt muss ich nur irgendwie hinkriegen, dass sich die Scenery Gebäude von EDVE nicht mit den OSM Gebäuden vermischen. Dann bin ich endgültig glücklich.

Und schon wieder jemanden glücklich gemacht, freut mich!

Die neuen Fototapeten werden noch besser, so nebenbei erwähnt... Und auch die OSMs bekommen noch realistischeren Wald dazu, alles nach und nach...

Um die OSM-Gebäude von den Flugplätzen fernzuhalten editiert man die Szenerie mit World Editor oder Overlay Editor und setzt um den Flugplatz eine "exclusion facade", wenn man es übertreiben will, macht man andere exclusions gleich noch dazu, wie objects, forest, dann hat man auch vor wild herumstehenden Bäumen oder Autogen-Objekten seine Ruhe.

Ich denke, dass durch den Aufruf von Ben die Szenerie-"Designer" nun besser darauf achten, auch gleich die eclusions mit zu setzen. Bei selbst konvertierten FSX-Szenerien muss man das aber nach wie vor selbst machen.

[simHeaven 1664]

Hm, ein Blick in den Thread Link von PilotBalu hätte dir auch diesen Post mit dem Download-Link vom Autor offenbart.

Ich hab ja gleich für Faule den Downloadlink aus dem Thread mit rauskopiert. Bei mir funktioniert der Link, vielleicht liegt es am Browser oder dessen Einstellungen.

[LyAvain 121]

Danke für den Hinweis... Ich hab mal auf die Schnelle EDDV, EDVE und EDDH im Overlay Editor geöffnen und ein wenig herumgespielt. Habs sogar hinbekommen. Ich werd das nach und nach mal bei allen Airports machen wo es mir auffällt.

Bei einigen Autobahn-Waldschneisen an der A2 Richtung Hannover und der A395 fiel mir auf, dass Bäume auf der Fahrbahn stehen. Da werde ich auch mal rangehen. Ich glaube das kommt öfter vor.

Jahaa... Du hast mich extrem glücklich gemacht. Die Phototapete ist schon genial... Nur die Downloads dauern recht lange. Da wartet man immer ganz hibbelig auf die nächste Kachel.

[simHeaven 1664]

Mei, kann dir die Tapeten auch nicht auf den Rechner zaubern. Da hilft ein Bier- oder Weinchen zur Beruhigung oder schöne Flüge über die schon vorhandenen Szenerien.

[alpilotx 111]

So, ich bin ein Mann des experimentierens, und bevor ich weiterhin nur Vermutungen über die Photoscenery anstelle, habe ich mal lieber experimentiert. Dazu habe ich mal eines der kleinere Kacheln von ZL16 genommen, und in seine Einzelteile zerlegt (beziehungsweise mein Skript dsf-to-gml genommen, um die Daten anschließend in QGIS anschauen zu können).

Nun sehe ich auch genau den Aufbau (eigentlich, wie vermutet - aber schön es mal zu sehen) und was g2xpl so mit der Mesh macht. Pfiffiges Programmchen, das muss ich schon lassen. Denn die Default Scenery ist alles anderes als Trivial aufgebaut, und besteht aus tausenden, unförmigen kleinen "Patches" (jeweils kleine Dreiecksnetze), welche zusammen, wie ein Patchwork (Flickwerk) die Scenery ergeben. Jedes solches Patch steht für einen - gewissermaßen - Landclasstyp in der Global Scenery und bekommt jeweils unterschiedliche Texturen (beziehungsweise eigentlich nur die TER Files! ... diese referenzieren dann den/die benötigten Texturen und welche Shader zum Einsatz kommen sollen!) aufgeklebt. Obendrein überlappen die "Patches" sich auch noch - wegen der sanften Übergänge zwischen verschiedenen Texturen.

Zur Veranschaulichung, hier ein Ausschnitt aus +57+011 mit der Global Scenery (zur Vergrößerung, immer anklicken):

Wie man sieht, ein recht ungeordnetes Patchwork (was aber der natürlichen Strukrut der Landclass Daten geschuldet ist ... also absolut normal und erwünschenswert).

Das ist aber so direkt kaum für eine Photoscenery nutzbar, wo jedes Bildelemt (Fotokachel) jeweils einen rechteckigen Bereich abdeckt. Und das Dreiecksgitternetz muss auch jeweils solche Patches bereitstellen, welche entlang der Rechtecke abgegrenzt sind (und die Überlappungen brauchts hier gar nicht erst). Also tut offensichtlich - wie wir gleich sehen werden - g2xpl die Mesh einlesen, aber tut dabei vermutlich die ganzen ursprünglichen, unregelmäßigen Patches auflösen und ein zusammenhängendes, einfaches Dreiecksgitternetz erzeugen. Anschließend zerschneidet es dieses Gitternetz in - neue - rechteckige Patches (und zerteilt auch die Dreiecke welche über solche Patch-Grenzen liegen in zwei oder mehr Unterdreiecke), so dass man am Ende ein neues, viel regelmäßigeres Patchwork erhält, was aus lauter rechteckigen Bereichen besteht (jeder Bereich referenziert auch hier ein TER File --> das wiederum referenziert letztendlich die passende Textur).

Zur Veranschaulichung, hier ein Ausschnitt aus +57+011 mit der ZL16 Photoscenery von simHeaven (die Regenbogenfarben verlaufen zufällig in Spalten, aber man erkennt trotz dem, daß es kleine Rechtecke sind - die Fareben wurden aus einer Farbverlaufpalette von QGIS den einzelnen Pacthes zugeordnet):

Zum Schluss noch eine Nahbetrachtung eine - identischen - Ausschntites, wo man sieht, wie die ursprünglichen Dreiecke entlang der neuen, rechteckigen Patch-Grenzen zerschnitten wurden.

Zuerst die original Global Scenery (auch aus +57+011):

Und letztendlich dann die Photoscenery von der selben Stelle (bei genauer Betrachtung sind die zerlegten Dreiecke sichtbar):

Das mag zwar jetzt für einige ein unnötiger, sehr technischer Ausflug in die Welt des DSF Meshes sein, aber vielleicht auch für einige mal ganz lehrreich !

Andras

[uwespeed 165]

Das muss ich mir nochmal etwas langsamer durchlesen .

Jedenfalls hätte ich ohne dein dsf-to-gml-Skript die Änderungen im Mesh der LPMA-Szenerie wohl nicht machen können, oder es wäre noch sehr viel aufwändiger geworden als es sowieso schon war (für die weniger technisch versierten - ich habe da etwa 450 Eckpunkte dieser Dreiecke "von Hand verschoben", d.h. statt der ursprünglichen Koordinaten neue eingetippt und dann noch weitere Schritte per Skript ausgeführt).

Also, ohne Andras gäbe es LPMA nicht in der Form in der es gegenwärtig ist, bzw. zukünftig noch sein wird. Ein dreifach Hoch .

Andras, weisst du, ob - und falls ja, wie - man mit QGIS die Dreiecke, bzw. deren Eckpunkte verschieben kann (ich habe nichts dergleichen gefunden, oder nur nicht genug gesucht)? Falls nicht mit QGIS, gibt's da was anderes? Zwar habe das Mesh jetzt ja schon geändert, aber ich will noch ein paar weitere Änderungen durchführen, da wäre es natürlich einfacher, wenn ich das auf grafischem Wege lösen könnte. Und wenn ich dann ein solches geändertes Mesh hätte, bräuchte ich auch noch ein "umgekehrtes" Skript, nämlich gml-to-dsf. Wäre das ein großer Aufwand, das zu tun? Ich kenne mich da leider zu wenig mit GIS und AWK und so Zeugs aus.

Zur Info noch an Andras: XPFR hat ja versucht, g2xpl auf meinem geänderten Mesh anzuwenden, irgendwie hat das aber nicht funktioniert, weil ich noch mit Cestomanos pintadera-Tool ein HD-Mesh daraus gemacht habe. Zwar habe ich nicht verstanden, warum das nicht ging, vielleicht verstehe ich es, wenn ich obiges nochmal genau durchlese.

[simHeaven 1664]

Das mag zwar jetzt für einige ein unnötiger, sehr technischer Ausflug in die Welt des DSF Meshes sein, aber vielleicht auch für einige mal ganz lehrreich !

Das war mir alles klar, nun ja, vom Ansatz her. Kann das der Grund, dass Fototapeten schneller sind, aufgrund der geordneteren Struktur?

Habe es auf die verschiedensten Arten probiert es klappt, erzeuge HD mit Joses Pintadera und binde es ein, binde dein HD-Mesh ein... es ändert sich auch immer was in der Darstellung, nur so richtig gut sieht es erst mit den Polygonen aus. Liegt wahrscheinlich daran, dass bei Terrain alles steiler ist, dadurch sieht es auf den Steilflächen verwaschener aus.

Noch ne Idee, wie man deine HD-Mesh in die Terrain-dsf einbinden kann?

[LyAvain 121]

So, bin bis eben auf meinen 5 Kacheln hin und her geflogen, während die 6. langsam wird... Macht echt Spass. Man kann soviel entdecken, dass man seine Ungeduld auf das nächste Fleckchen Photodeutschland zügeln kann.

Nochmal vielen Dank für die tolle Arbeit.

[simHeaven 1664]

Hoffe, du hast Nachtflugberechtigung... Hab auch fast eine Nachtschicht eingelegt.

[alpilotx 111]

ndras, weisst du, ob - und falls ja, wie - man mit QGIS die Dreiecke, bzw. deren Eckpunkte verschieben kann (ich habe nichts dergleichen gefunden, oder nur nicht genug gesucht)? Falls nicht mit QGIS, gibt's da was anderes? Zwar habe das Mesh jetzt ja schon geändert, aber ich will noch ein paar weitere Änderungen durchführen, da wäre es natürlich einfacher, wenn ich das auf grafischem Wege lösen könnte. Und wenn ich dann ein solches geändertes Mesh hätte, bräuchte ich auch noch ein "umgekehrtes" Skript, nämlich gml-to-dsf. Wäre das ein großer Aufwand, das zu tun? Ich kenne mich da leider zu wenig mit GIS und AWK und so Zeugs aus.

Na ja, mit QGIS kann man ja eigentlich schon die Dateien editiere, aber ich bilde mir ein, nicht in jedem Format (z.B. bei SHP Files geht das sicher ... und da schreibt er dann die Änderungen auch gleich mit rein). Aber vermutlich geht das auch mit anderen Tools, da das GML Format ja eigentlich ein Standard ist, den die meisten GIS Tools lesen können sollten. z.B. könntest du ja noch Diva-GIS ( http://www.diva-gis.org/ ) anschauen (habe ich selber wenig benutzt, soll aber auch recht mächtig sein ... und trotz dem ein halbwegs brauchbare GUI haben).

Und nein, ein umgekehrtes Skript habe ich auf die Schnelle auch nicht (habe ich ja nie gebraucht ... das dsf-to-gml war ja auch nur zur "reinen" Visualisierung gedacht). Das kann man sicherlich zusammen hacken, da das GML Format zumindest von der Datenstruktur her doch recht nah am DSF liegt. Ist aber syntaktisch etwas "aufgeblasener" (GML ist halt eben im Grunde XML mit einer vorgegebenen Struktur) ... das kann man dann mit einigem Skript-Zauber in so ziemlich alles umwandeln. Aber trivial dürfte es nicht sein ... insbesondere, da ich bei der Umwandlung in GML ja eine ganze Menge weglasse (Straßen, Wälder etc. etc.) was man ja dann wieder rein mergen müsste (und dann wirds richtig ekelig )!

ur Info noch an Andras: XPFR hat ja versucht, g2xpl auf meinem geänderten Mesh anzuwenden, irgendwie hat das aber nicht funktioniert, weil ich noch mit Cestomanos pintadera-Tool ein HD-Mesh daraus gemacht habe. Zwar habe ich nicht verstanden, warum das nicht ging, vielleicht verstehe ich es, wenn ich obiges nochmal genau durchlese.

Zu 100% kann ich es dir nicht beantworten, aber ich habe so meine Vermutungen .... Ich nehme stark an, dass g2xpl davon ausgeht dass es eine saubere Mesh Struktur aus den DSFs bekommt (was ja auch normalerweise stimmt, wenn es von unseren Tools erstellt wurde - oder auch vom MeshTool). Wenn du allerdings von Hand Dreiecke verschoben hast (und zwar so richtig "von hand" ... also Koordinate eintippen etc.), könnte es passiert sein, dass du evtl. einige Dreiecke nicht sauber "umgebogen" hast. Obendrein kommt noch dazu, dass - wie ich schon oben bei meiner Ausführung andeute - bei unserem Global Scenery Patchwork, die einzelnen "Patches" auch noch meistens um ein Dreieck überlappen (wegen den sanften Texturübergängen), sprich, du hast viele Dreiecke mindestens doppelt, oft aber auch drei- oder vierfach (wenn sich mehrere Patches treffen). Und wenn an der Stelle nicht alle überlappenden Dreiecke sauber verschoben wurden, könnte das z.B. (so stelle ich es mir vor) g2xpl schon ziemlich verwirren (aber offenbar kommt X-Plane damit gut zurecht ... wird aber dann in einem unglückliche Fall zu kleinen Darstellungsfehlern führen).

Übrigens dürfte auch in den GIS Programmen, wenn du GML editieren würdest das Hauptproblem werden, dass du bei überlappenden Dreiecken alle erwischst (und sauber, mit exakter Koordinatenübereinstimmung die Ecken verschiebst - ok, bei einem halbwegs vernünftigem GIS Programm mit ordentlichem snapping müsste das noch halbwegs klappen).

[alpilotx 111]

Das war mir alles klar, nun ja, vom Ansatz her. Kann das der Grund, dass Fototapeten schneller sind, aufgrund der geordneteren Struktur?

Ja, natürlich! Allein schon an der DSF Größe siehst du, dass es ein wenig kleiner ist. Sprich, du hast um einiges weniger Dreiecke (man spart ja zum Beispiel die ganzen Überlappungen, da man zwischen Fototexture Kacheln ja sich nich um sanfte Übergänge kümmern muss). Auch muss die Grafikkarte keinerlei komplizierten Shader anwenden und sanfte Textuhrübergänge berechnen etc. ... das spart schon ein paar Rechenzyklen.

Habe es auf die verschiedensten Arten probiert es klappt, erzeuge HD mit Joses Pintadera und binde es ein, binde dein HD-Mesh ein... es ändert sich auch immer was in der Darstellung, nur so richtig gut sieht es erst mit den Polygonen aus. Liegt wahrscheinlich daran, dass bei Terrain alles steiler ist, dadurch sieht es auf den Steilflächen verwaschener aus.

Noch ne Idee, wie man deine HD-Mesh in die Terrain-dsf einbinden kann?

Woher der Unterschied zwischen TER oder POL an der Stelle kommt ist mir nicht ganz kalr. Denn eigentlich müsstest du ja in beiden Fällen das grundsätzliche Problem aller Fototexturen (ist ja bei MSFS nicht anders), dass sie dir ja immer nur ein Bild des senkrechten Blickes von Oben bieten. Sprich, du hast ja gar keine Information über die steilen Felswände (oder eben nur sehr wenig) .... und wo nichts (oder wenig) vorhanden ist, kann man auch schlecht die Information einfach so herbeizaubern. Nur mit extremen Aufwand könnte man - sofern man z.B. extra Fotos der ganzen Berge von der Seite hätte - soetwas umgehen, aber da müsste man dann schon eine Art Mischung der klassischen Fototexturierung (also die rechteckige Zerlegung des Mesh) und unregelmäßigen Patches an den Steilwänden vorgehen, wo per TER eine Seitenprojektion benutzt wird (bei der Global Scenery benutzen wir natürlich überall, wo es steiler als X-Grad wird entsprechende Shader, die mehr von der Seite die Texturen Projizieren ... weshalb das Ergebnis in den Bergen ja auch recht ansehnlich ist). Aber ich glaube nicht, dass den enormen Aufwand in absehbarer Zeit jemand auf sich nehmen wird (wofür man auch noch hoch spezialisierte Tools bräuchte)

Und wegen deiner letzten Frage .... nun, ich habe dafür keine Lösung. Insbesondere wenn du meine Ausführung über die Arbeit von g2xpl vor Augen hältst, ist das alles andere als trivial. Na ja, eigentlich wäre da möglicherweise g2xpl der richtige Ansprechpartner ... das Tool könnte mit seinen bestehenden Mechanismen wohl noch am ehesten einen Mesh Austausch unter der Haube durchführen (da sie ja eh bereits einige der Mesh-Verarbeitungsschritte drin haben) :-)

[dav8624david 0]

Hallo Pilot Balu,

Hab da mal ne Frage zu deinen Fototapeten,

Die sind ja in Städte unterteilt, decken die dann trotzdem das ganze Gebiet ab oder muss ich für dazwischen die zl 16 von Zonephoto laden?

Würde am we gerne mal von Sylt nach Rostock fliegen, welche Fototapeten brauch ich denn da?

Gruß, David

[uwespeed 165]

Und nein, ein umgekehrtes Skript habe ich auf die Schnelle auch nicht (habe ich ja nie gebraucht ... das dsf-to-gml war ja auch nur zur "reinen" Visualisierung gedacht). Das kann man sicherlich zusammen hacken, da das GML Format zumindest von der Datenstruktur her doch recht nah am DSF liegt. Ist aber syntaktisch etwas "aufgeblasener" (GML ist halt eben im Grunde XML mit einer vorgegebenen Struktur) ... das kann man dann mit einigem Skript-Zauber in so ziemlich alles umwandeln. Aber trivial dürfte es nicht sein ... insbesondere, da ich bei der Umwandlung in GML ja eine ganze Menge weglasse (Straßen, Wälder etc. etc.) was man ja dann wieder rein mergen müsste (und dann wirds richtig ekelig )!

Ah ja ... jetzt, wo du es sagst . Das habe ich nicht bedacht, dass das Skript ja praktisch nur das Gelände aus dem dsf zieht und nicht die Straßen, Autogen, ... Das Ganze dann wieder zu mergen wäre tatsächlich ekelig - ich hatte mal für meine Fürth Szenerie 2 dsf's per Hand zusammengefügt, als der WED das noch nicht konnte. Also vergessen wir es ganz schnell wieder und ich habe nie so doof gefragt .

Zu 100% kann ich es dir nicht beantworten, aber ich habe so meine Vermutungen .... Ich nehme stark an, dass g2xpl davon ausgeht dass es eine saubere Mesh Struktur aus den DSFs bekommt (was ja auch normalerweise stimmt, wenn es von unseren Tools erstellt wurde - oder auch vom MeshTool). Wenn du allerdings von Hand Dreiecke verschoben hast (und zwar so richtig "von hand" ... also Koordinate eintippen etc.), könnte es passiert sein, dass du evtl. einige Dreiecke nicht sauber "umgebogen" hast. Obendrein kommt noch dazu, dass - wie ich schon oben bei meiner Ausführung andeute - bei unserem Global Scenery Patchwork, die einzelnen "Patches" auch noch meistens um ein Dreieck überlappen (wegen den sanften Texturübergängen), sprich, du hast viele Dreiecke mindestens doppelt, oft aber auch drei- oder vierfach (wenn sich mehrere Patches treffen). Und wenn an der Stelle nicht alle überlappenden Dreiecke sauber verschoben wurden, könnte das z.B. (so stelle ich es mir vor) g2xpl schon ziemlich verwirren (aber offenbar kommt X-Plane damit gut zurecht ... wird aber dann in einem unglückliche Fall zu kleinen Darstellungsfehlern führen).

Klingt plausibel. Ich habe nämlich absichtlich eine "Schweinerei" mit dem Mesh gemacht (siehe Screenshots in diesem Post), das könnte also dazu gefüht haben. Wobei es andersherum offensichtlich geht - also erst g2xpl und dann Meshänderung.

[simHeaven 1664]

Hab da mal ne Frage zu deinen Fototapeten,

Die sind ja in Städte unterteilt, decken die dann trotzdem das ganze Gebiet ab oder muss ich für dazwischen die zl 16 von Zonephoto laden?

Ich hab zwei verschiedene Arten von Fototapeten: eine deckt das ganze Gebiet, die ganze Kachel, in derselben Qualität ab (zu finden unter Photosceneries ZL16/17) und die andere sind die "Airport & City Areas", die decken das Gebiet um Flughafen und Stadt in guter Qualität ab (ZL17), meist ein Kreis um X mit Radius Y, außerhalb des Kreises ist die Qualität nicht so gut (ZL14) und nur wenn man genug Höhe hat erträglich anzusehen. Die sind vor allem für IFR-Flieger und Leute die die Stadt erkunden wollen gedacht. Wenn ich mal ein Update der Areas mache, dann passe ich das Gebiet außerhalb des Kreises auf ZL16 an, damit fügt es sich besser ein.

Die Benennung der Kacheln erfolgt nach Breiten- und Längengrad, Land und einer Stadt, die in der Kachel liegt, meist die größte, oder eine mit Flughafen oder eine in der Mitte der Kachel, ein Kürzel und dann die Auflösung: z+54+010_D_Kiel_gx17

Um von Sylt nach Rostock zu fliegen brauchst du 5 Tapeten:

z+54+008_D_Pellworm

z+54+009_D_Flensburg

z+54+010_D_Kiel

z+54+011_D_Fehmarn

z+54+012_D_Rostock

Du kannst dir z.B. in Google Earth das Gitternetz einblenden, dann siehst du auch die Kacheln die du brauchst.

[simHeaven 1664]

Also tut offensichtlich - wie wir gleich sehen werden - g2xpl die Mesh einlesen, aber tut dabei vermutlich die ganzen ursprünglichen, unregelmäßigen Patches auflösen und ein zusammenhängendes, einfaches Dreiecksgitternetz erzeugen.

Hab noch mal intensiv geguckt (das kann ich gut!), scheinbar verändert g2xpl das Mesh auch etwas, weil z.B Felsformationen steiler sind als in der Ausgangsmesh. Deswegen wirken auch die Texturen in der mit g2xpl erzeugten dfs-Datei "schlierenhafter" als mit der originalen XP10-dsf-Datei, die ja von in der Polygon-Version benutzt wird.

Ich habe mir dein Tool installiert, dann GnuWin32 und auch noch QGIS mit allem... muss sagen, das ist schon aufwändig um nur mal so zu gucken und auch um da überhaupt reinzukommen. Wenn ich mal Muße habe...

Ich kann ja mit g2xpl die HD-Mesh als Grundlage nehmen, das funktioniert, die Datei ist genau die 8 MB größer, die auch deine Datei größer ist (im Standard-XP-7z-Format) und das Ergebnis ist auch sichtbar. Nur doch wie in der Nicht-HD-Version etwas abweichend vom Original. Da kann wahrscheinlich nur Rob dazu was sagen...

Ich lass das jetzt erstmal mit der HD-Version meiner Fototapeten, wenn jemand noch eine zündende (und einfach) Idee hat oder die dsf- Dateien bearbeitet, dann her damit. Dann könnte ich ja für alle Tapeten die HD-Version (ca. 30 MB pro Kachel) nachliefern.

Spätestens Anfang der Woche können die Betatester die neuen Tapeten laden, ein bis zwei Wochen später sind sie dann auf simHeaven verfügbar. Weil ich auf denselben Server hochladen will (das ist mit der schnellste), werde ich für die Dauer des Uploads von ca. einer Woche den Download der alten DACH-Fototapeten sperren.