Daikan

Bitteschön - hat aber zugegebenermassen schon etwas Überwindung gebraucht, da bei mir immer eine Portion schlechtes Gewissen dabei ist, wenn ich Mechanismen ausheble, die offensichtlich das systematische "scrapen" von Orthophotos verhindern sollen, wie eben im Fall von Here.... Ich fürchte das wird früher oder später ein Schuss ins Knie für alle werden - je mehr ahnungsglose User terabyteweise Orthos ziehen, umso früher....

Genaugenommen kommt das etwas auf den Breitengrad drauf an - das liegt an der Art der verwendeten geografischen Projektion (WGS84 Web Mercator). Am Äquator ist die Fläche eines Pixels am kleinsten. Je weiter nördlich/südlich man geht umso grösser wird die tatsächliche Fläche (bedingt durch Streckung entlang der Breitengrad-Achse). D.h. das Verhältnis der projizierten Masse von Längen- und Breitengrad nimmt ab, je weiter man vom Äquator entfernt ist. Dies kann eine ganze Menge ausmachen, wie man anhand der folgenden Grafik sieht:

Ich bin auch praktisch nur VFR unterwegs und hab besonders unter VR immer wieder meine liebe Müh' mit niedrigen FPS..... Was etwas geholfen hat, ist folgendes: Komplettes "Ausknipsen" von Layer 3 und 4 (d.h. setzen von SCENERY_PACK_DISABLED in scenery_packs.ini) Privates Dataref "sim/private/controls/soundscape/kill_roads" auf 1 gesetzt (ich mach das z.B. via eines selbtgebastelten FWL Scripts) Dies unterdrückt die Umgebungs-Soundeffekte welche X-Plane in der Nähe von Strassen erzeugt (aka "Strassenlärm"). Niemand braucht solchen Schnickschnack, oder? Schon gar nicht wenn das FPS kostet.... Bei mir hat diese Massnahme die FPS um gute 10% gesteigert. Extended DSFs deaktiviert (schont darüberhinaus auch VRAM und Paging). Die Mesh-Dichte (sog. "Triangle Count") von selbstgenerierten Ortho-Kacheln deutlich reduziert (im Vergleich zu XP11) - z.B. durch erhöhen von "curv_tol" von 2.0 auf 3.0 in Ortho4XP. Dies trägt besonders im Gebirge Früchte (heisst: FPS Gewinn). In flachem Gebiet ist die Mesh-Dichte defaultmässig klein, da der verwendete Triangulations-Algorithmus von Ortho4XP grundsätzlich adaptiv arbeitet d.h. je "gebirgiger" umso höher die resultierende Mesh-Dichte (bei gleichem DEM Raster). Für den Fall, dass alles obige nichts hilft, habe ich mir ein FWL Script erstellt, dass dynamisch noch drastischere Massnahmen ergreift, sofern die FPS einen definierten Minimalwert nicht erreichen: Schrittweise Erhöhung des privaten Datarefs "sim/private/controls/reno/LOD_bias_rat") auf max. 2.0 -> verringert die Distanz ab welcher Objekte nicht mehr gerendert werden Schrittweise Reduktion des privaten Datarefs "sim/private/controls/cars/lod_min" auf 1000 -> verringert die Verkehrsdichte auf Strassen Adaptives Setzen des privaten Datarefs "sim/private/controls/clip/override_far" auf einen Wert zwischen 30000 und 80000 - dies ist die ultimative Holzhammer-Methode zur harten Begrenzung der Rendering-Distanz und wirkt sich auf ALLES aus (inkl. Atmosphäre und Weltall). Sieht nicht schön aus, aber kann im äussersten Notfall helfen, die FPS zu halten.

Fehlen wohl noch 2 Backslashes: cd //Volumes/SanDisk\ 2TB/X-Plane\ 12/Custom\ Scenery/simHeaven_X-World_Vegetation_Library

Lass mal das "$" weg. Das einzutippende Kommando lautet: cd //Volumes/SanDisk 2TB/X-Plane 12/Custom\ Scenery/simHeaven_X-World_Vegetation_Library

Ich befürchte, dass es keine einfache und pfannenfertige Lösung für das Problem gibt - ausser man schreibt sich das Progrämmchen selber oder gibt es in Auftrag... Hier! Bin zwar wie gesagt weit davon, ein Profi zu sein, drüfte allerdings die Anfängerphase mit totaler Ahnungslosigkeit schon hinter mir haben Wenn du mir deine Vektoren inkl. Anforderungen schickst, kann ich ja mal sehen, was ich auf die Reihe kriege - oder auch nicht.

Ich weiss, dass man in QGIS OSM Daten als Vector-Layer importieren kann und es gibt auch eine praktische "Buffer" Funktion im Vektor-Toolset: Beispiel vorher/nachher: Es unterstützt darüberhinaus auch PostGIS und Batch-Processing, somit gibt es fast nichts, womit es nicht umgehen kann.... Aber: Es ist eben ein mächtiges GIS-Werkzeug, dass auch gelernt werden will... ich selber hab da bisher leider nur an der Oberfläche gekratzt...

Ortho4XP macht das im Prinzip bereits um Straßen im Mesh zu glätten. Vielleicht kann man dort den einen oder anderen Python Code abkupfern...

Es scheint, als wäre hier das letzte Wort noch nicht gesprochen und die Gateway-Airport-Exclusions könnten durchaus wieder Teil der Default-Szenerie werden. Ich stütze mich dabei auf folgenden Kommentar von Ben: https://developer.x-plane.com/2022/09/x-plane-12-early-access-is-here/#comment-41895 Also vielleicht erstmal mal den Ball flachhalten

Interessant. Gibt's dazu schon irgendwo eine offizielle Doku? Ich (wie auch vermutlich viele andere Ortho-Nutzer) wäre(n) natürlich sehr interessiert an den Details - ich hatte dazu auch schon mal vorsorglich einen Topic auf der .org eröffnet... Falls du eine freie Minute hast, wäre dir die Community sicher dankbar, wenn du dort deine bisherigen Erkenntnisse kurz zum Besten geben könntest...

Hab's grad bei mir getestet und die Wasseroberflächen sind zwar (schön) animiert aber nicht in 3D... Um den 3D Effekt zu bekommen müssen also bisherige Ortho-Kacheln ziemlich sicher angepasst werden - so wie es Ben im Blog/Video auch erwähnt hat.

Also, dass die 3D-Wellen "einfach so" mit XP11-Ortho-Kacheln funktionieren überrascht mich jetzt doch etwas, nachdem Ben ja folgende Äusserungen machte: https://developer.x-plane.com/2022/03/x-plane-12-development-update-march-4th-2022/#comment-41142 https://youtu.be/GfG1ms5flvw?t=643 Muss das aber noch selber verifizieren...

Dies betraf aber soviel ich weiß nur Bing, welches bekannt für seine Synchronisationsprobleme in seinem CDN ist. Und es waren auch keine "weiße" Kacheln, sondern "bloß" Farbunterschiede, bedingt durch Aufnahmen aus unterschiedlichen Zeitpunkten...

Wenn du die exakten Koordinaten sowie den verwendeten ZL und Provider Code (BI, GO2, Arc, etc.) postest kann ich dir die zugehörigen Namen der Texturdateien liefern. Die Herleitung ist ein bisschen umständlich um es hier auf die Schnelle zu erklären aber ich hab das schon öfters gemacht und hab da etwas Übung...

Kleiner Tipp: Ich würde dir anraten, jeweils die Anzahl Dreiecke (tris) pro Kachel im Auge zu behalten. Diese wird jeweils am Ende des Step 2 ausgegeben. Auf meinem System versuche ich z.B. den Wert von 7M nie zu übersteigen, da ansonsten die FPS zu stark leiden. Besonders im Gebirge wird dieser Wert schnell erreicht, wenn man daran gewöhnt ist, Kacheln im Flachland problemlos mit niedrigem curvature_tol zu generieren...