Daikan
-
Posts
482 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Posts posted by Daikan
-
-
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:
-
2
-
-
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.
-
2
-
1
-
Fehlen wohl noch 2 Backslashes:
cd //Volumes/SanDisk\ 2TB/X-Plane\ 12/Custom\ Scenery/simHeaven_X-World_Vegetation_Library
-
30 minutes ago, tino-dietsche said:
- gemäss Anleitung muss ich danach den folgenden Befehl ausführen: $ cd //Volumes/SanDisk 2TB/X-Plane 12/Custom\ Scenery/simHeaven_X-World_Vegetation_Library
-
Wenn ich das mache bekomme ich aber folgende Meldung:
zsh: command not found: $
tinodietsche@MBP-von-Tino-97 ~ %
-
Keine Ahnung was ich falsch mache?
Lass mal das "$" weg. Das einzutippende Kommando lautet:
cd //Volumes/SanDisk 2TB/X-Plane 12/Custom\ Scenery/simHeaven_X-World_Vegetation_Library
-
1 hour ago, simHeaven said:
Ich brauch was einfaches wie "vektoren rein, buffer=12, Polygone raus".
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...
1 hour ago, simHeaven said:Oder jemand, der QGIS installiert hat.
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.
-
1
-
1
-
-
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...
-
6 minutes ago, simHeaven said:
hat jemand auf die Schnelle eine Idee, wie ich aus Straßenvektoren mit einer definierten Breite (buffer) Polygone machen kann? Vielleicht noch mit einem gängigen Tool?
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...
-
17 hours ago, simHeaven said:
In XP12 wurden leider - und ich müsste das leider riesengroß und fett schreiben - in den Global Airports ALLE Exclusions von den Airports entfernt, Beispiel Nürnberg:
13 hours ago, simHeaven said:Janov hatte das hier näher erklärt: https://forums.x-plane.org/index.php?/forums/topic/272680-simheaven-x-world-for-xp12/&page=4#elControls_2410293_menu
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
-
32 minutes ago, simHeaven said:
die rasterdata müssen ins Ortho eingefügt werden, ist keine große Sache. Wenn Du Zeit hast, könntest Du ein Script machen, ich hab dafür grad echt keine Zeit.
Für mehr Info -> PM
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...
-
16 hours ago, simHeaven said:
Ja, das geht, ich habe an den Orthos nichts machen müssen, das macht XP12 von alleine. Ich war vor allem von dem Wintereffekt völlig baff als ich das zum ersten Mal testete, dass das so gut aussieht.
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.
-
15 hours ago, simHeaven said:
Ja, das geht, ich habe an den Orthos nichts machen müssen, das macht XP12 von alleine. Ich war vor allem von dem Wintereffekt völlig baff als ich das zum ersten Mal testete, dass das so gut aussieht.
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=643Muss das aber noch selber verifizieren...
-
Das wäre theoretisch schon möglich in dem die Vektoren in einem Preprocessing-Schritt "polygonisiert" (ermitteln einer Pufferzone für die Strassenbreite abhängig vom Strassentyp) und dann auf "Kollision" mit MSBF geprüft werden. Ist aber natürlich Zusatzaufwand...
Ortho4XP macht diese Polygonisierung genauso für das Einebnen von Straßen im Mesh ("road leveling").
-
6 hours ago, Coverdale said:
Noch ein Tip: Ich hatte in diesem Forum schon mal geschrieben, wo ich auch seltsame Rechtecke hatte. Daikan hatte für mich mal ein Test mit der gleichen Kachel erstellt, die waren bei Ihm i.O. Daraufhin habe ich eine virtuelle IP-Adresse vergeben und es war daraufhin bei mir auch i.O. Seit dem nehme ich immer eine virtuelle IP-Adresse.
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...
-
1 hour ago, stevebiker said:
Aber wie ich die richtigen Tiles, bzw. Orthofotos finde, per Koordinaten, ist mir noch schleierhaft.
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...
-
Wenn alles funktioniert, dann darfst du Verbosity wieder auf 1 stellen, um die überflüssigen Meldungen zu unterdrücken.
-
Das hat m.E. nichts mit den Bildern zu tun sondern viel eher mit der irrsinnig hohen Anzahl an Dreiecken, welche dann auch die Erstellung des DSF's extrem in die Länge zieht (und manchmal auch das intern verwendete dsftool Programm zum Absturz bringen kann).
-
Das ist zu wenig Information. Am besten den "Verbosity" Parameter auf 3 stellen und den kompletten Text der Statusmeldungen während des Generiervorgangs einer einzelnen Kachel als Anhang hier hochladen. Screenshots der Ortho4XP Einstellungen wären auch hilfreich.
-
6 hours ago, simHeaven said:
Da es doch noch länger dauert bis die öffentliche Beta von XP12 kommt (Ende Juli 2022)
Würde mich jetzt noch interessieren, woher du diese Info hast...
-
18 minutes ago, Coverdale said:
Das hört sich nach einer schlüssigen Analyse an. Das kann man wahrscheinlich auch nicht mit einer Virtuellen IP-Adresse eines anderen Landes ändern,oder?
Mit einem VPN (oder auch Proxy), das dem Bing-Server bzw. CDN eine IP in einer anderen Region vorgaukelt, könnte das Problem vielleicht gelöst werden - allerdings auf Kosten der Geschwindigkeit.
18 minutes ago, Coverdale said:Noch eine andere Frage: Wo ist der Unterschied zwischen Arc und Arc@? Bis auf ein paar Bilder sind die sonst gleich.
Arc: https://www.arcgis.com/home/item.html?id=10df2279f9684e4a9f6a7f08febac2a9
Arc@: https://www.arcgis.com/home/item.html?id=da10cf4ba254469caf8016cd66369157
Mittlerweile ist es nicht mehr empfohlen Arc@ zu verwenden, da der Layer "deprecated" ist und nicht mehr aktualisiert wird.
-
Ich vermute stark, dass das Problem durch das von Microsoft verwendete CDN verursacht wird (ich vermute das ist in diesem Fall Akamai), welches die Bilder aus einem Cache ausliefert, das abhängig vom physischen Standort (Geolokation) der Source-IP ist.
Siehe auch: https://help.openstreetmap.org/questions/36380/id-editor-uses-an-old-version-of-bing-aerial-imagery-why
Ich habe das verifiziert in dem ich die Domäne r0.ortho.tiles.virtualearth.net aus zwei unterschiedlichen physischen Standorten aufgelöst habe.
Resultat:
Aus der Schweiz (wo ich aktuell sitze) löst die Domäne auf die IP 77.109.138.72 auf. Aus Frankfurt (AWS Cloud) bekomme ich hingegen 23.216.77.197.
Ich vermute, ihr habt alle das "Pech", in Deutschland zu sitzen und das Problem wird sich voraussichtlich irgendwann mal von selber lösen (sobald der "deutsche" CDN Cache nachgefahren ist).
-
Um es nochmals in diesem Thread zu erwähnen: Ich selber benutze die .py Variante ab Github unter Python 3.5 (und nicht die .exe). Vielleicht könnte das auch relevant sein.
Was ebenfalls noch einen Versuch wert sein könnte, ist, den Wert für "url_template" im BI.lay auf Zeile 2 wie folgt zu ersetzen:
Variante 1:
url_template=http://r0.ortho.tiles.virtualearth.net/tiles/a{quadkey}.jpeg?g=136Variante 2:
url_template=http://r{switch:0,1}.ortho.tiles.virtualearth.net/tiles/a{quadkey}.jpeg?g=136Variante 3:
url_template=http://a{switch:0,1,2,3}.ortho.tiles.virtualearth.net/tiles/a{quadkey}.jpeg?g=136 -
Und ich hab jetzt bei mir ebenfalls die komplette Kachel +50+008 mit BI ZL17 erzeugt.
Resultat: Alles perfekt bzw. ich kann keinerlei "Verpixelungen" analog den vorher angehängten Beispielen erkennen:
Ortho4XP Einstellungen:
41 minutes ago, Coverdale said:Sag mal Daikan, war das jetzt Zufall, das du die Bilder von Kreuztal erstellt hast?
Nein, natürlich nicht. Ich wollte ja exakt die gleiche Textur reproduzieren, die @hmkaiser angehängt hatte, und das war eben 43904_68448_BI17.jpg
-
Bei mir sieht die Kachel bzw. 43904_68448_BI17.jpg im Cache absolut perfekt aus:
Ich habe dabei allerdings einen gezielten GeoTIFF Export der ZL17 Textur über das "Custom zoomlevels" Fenster gemacht (mit CTRL+Mausklick den entsprechenden ZL17-Texturauschnitt markiert, dann "Apply" und "Make GeoTIFF" geklickt):
Achtung: Der GeoTIFF Export setzt voraus, dass das Kommando "gdalwarp" im Suchpfad gefunden wird (d.h. über "PATH" Umgebungsvariable). Es ist Bestandteil jeder GDAL Installation.
Die komplette Kachel +50+008 hab ich bisher aus Zeitmangel nicht erzeugt.
Falls der gezielte Export bei anderen ebenfalls problemlos funktioniert, könnte es ein Hinweis sein, dass hier der Bing-Dienst bei detektierter grösserer Last ausgehend von einer einzelnen IP (z.B. während der Erzeugung der gesamten Kachel) die rohen 256x256 Pixel Bildaten zu den einzelnen Requests aus verschiedenen Quellen ausliefert - wieso auch immer. Vielleicht funktioniert das Loadbalancing nicht korrekt oder es ist ein Schutzmechanismus bzw. Microsoft macht das absichtlich um Nutzer, welche exzessiven Verkehr verursachen zu vergraulen....
Ortho4XP
in Szenerie Design und Programmierung (X-Plane 11/12)
Posted
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....