Tileproxy

[Gunnar-MD]

Hallo Christian,

die vielen Einträge in der Scenery.cfg sprechen gegen meine Idee. Daran habe ich ehrlich gesagt nicht gedacht.

Ich gestehe, die Ansichten von Andreas sind meinen ähnlich. Ich sehe auch ein schwerwiegendes Problem. Der Rechner "ersäuft" förmlich in den riesigen Datenmengen.

Eine Idee, die mir durch den Kopf gegangen ist folgende:

In Google Earth das gewünschte Gebiet mit einem Polygon markieren. Dieses in einer KML-Datei speichern. Diese wiederum in ein Programm "TileProxy Static" (eigene Erfindung ) importieren und die besagte statische Scenery generieren lassen.

Bei mir hat die Euphorie ziemlich geschwankt. Eine ganze Weile lief das Programm hervorragend. Aber mit zunehmender Dauer läßt die Performance merklich nach. So richtig bin ich mir nicht im Klaren, woran das liegt. Sicherlich wird die Festplatte dabei sehr fragmentiert aber das Defragmentieren macht man auch nicht so oft.

@Christian
Seit Beta4 kann ich nicht mehr mehrere Orte nacheinander Besuchen.
Also wenn ich den ersten Flug lade, nach einiger Zeit beende und dann einen neuen Flug, an einem anderen Ort, erstelle, kommts zu dem bereits erwähnten Mischmaschfehler, wo alles durcheinander ist und nix zusammenpasst.
Im Tileproxyfenster steht auch seltsamerweise, nach dem Erstellen des 2. Flugs, dass der "Previous Flight" geladen würde..

[cbuchner1]

Original geschrieben von Gunnar-MD
Hallo Christian,

Ich gestehe, die Ansichten von Andreas sind meinen ähnlich. Ich sehe auch ein schwerwiegendes Problem. Der Rechner "ersäuft" förmlich in den riesigen Datenmengen.

Die Lösung wäre, den World folder regelmäßig aufzuräumen und die BMP Tiles nur bei Bedarf wieder aus dem JPEG Cache herstellen zu lassen.

Im JPEG Cache selbst könnte ich noch mehrere Unterordner-Hierarchien anlegen, die entweder regional gruppiert sind, oder auf einem Hash basieren (also gleichmäßig über alle Ordner verteilt).

Aus meiner Erfahrung ist es weniger die Filesystem-Performance die den Proxy ausbremst, als vielmehr die "Weigerung" von FSX SP1, schnell genug Tiles nachzuladen. Er öffnet einfach nicht genug BMP Files pro Sekunde. Dass es deutlich schneller ginge sieht man ja beim Laden des Fluges (mehrere hundert Tiles pro Sekunde). Im Flug sind es dann oft nur noch wenige Dutzend pro Sekunde und der Proxy langweilt sich (2% CPU auslastung oder so).

[cbuchner1]

Original geschrieben von Mentos79
@Christian
Seit Beta4 kann ich nicht mehr mehrere Orte nacheinander Besuchen.
Also wenn ich den ersten Flug lade, nach einiger Zeit beende und dann einen neuen Flug, an einem anderen Ort, erstelle, kommts zu dem bereits erwähnten Mischmaschfehler, wo alles durcheinander ist und nix zusammenpasst.
Im Tileproxyfenster steht auch seltsamerweise, nach dem Erstellen des 2. Flugs, dass der "Previous Flight" geladen würde..

Sieht so aus, als müßte ich selber mal mehrere ausgedehnte Flüge machen, um diesen Problemen nachzuspüren.

[cbuchner1]

b) Die Einbindung in den FSX - mir wäre es lieber, der TileProxy würde die Daten eines bestimmten Gebietes laden (und zwar nur den höchsten gewünschten Zoom Level) und dann eine statische Szenerie daraus erstellen - das wäre aus meiner Sicht der bessere Ansatz...

Andreas [/b]

Gegen den höchsten Zoom level spricht die Mathematik. Jede Erhöhung des Zoom Levels um +1 vervierfacht leider die Pixelzahl und damit die Datenmenge.

Allein die Insel Oahu auf Zoom Level 17 herunterzuladen, dauert mehr als zwei Stunden. Und diese Insel füllt nur etwa 10-20% des geladenen Sichtradius im FSX. Nun stelle man sich mal vor, man wollte den gesamten Radius mit Zoom Level 17 (FSX LOD 15, 1.1m/Pixel) füllen. Die Platte wird mit 20 GB BMP Tiles belastet und Google wird Dir ernsthaft aufs Dach steigen

Gegen Vorausladen habe ich echt was einzuwenden. Da wird nämlich die Grenze überschritten vom interaktiven Bildbrowser - hin zum automatisierten Download-Tool. Ersterer läßt sich vielleicht noch irgendwie mit Nutzungsbedingungen vereinbaren, letzterer verstößt aber grob gegen die Terms of Service ("Robots" Klausel)

[cbuchner1]

Original geschrieben von azapf1972
Aber eines hat das Ding gemacht: es hat gezeigt, was geht und solange wir an anderen Lösungen arbeiten, macht es viel Spaß!

Andreas

Ja, die Büchse der Pandora habe ich vielleicht aufgemacht - aber die Sache zur Vollendung bringen muss Microsoft selbst - denn nur die haben die Werkzeuge, das im nächsten Flight Simulator viel effizienter zu realisieren als ich mit meinem Filesystem Hack.

Schade, dass es dort mit einem Job nicht geklappt hat. Im Januar/Februar sah es da noch gar nicht so übel aus. Ich hätte dort sicherlich was bewegt in Sachen Terraindarstellung.

Hier noch mal ein Blick durch die Büchse der Pandora (ein hochauflösendes DivX Video, Gran Canaria mit dem Motordrachen mit TrackIR )
http://stage6.divx.com/user/Bramski/...rysim-19m-mesh

[Horst LOWW]

TP hat seine Grenzen im FSX!

Aber ich finde es "cool" wie Christian sie benutzt bzw. "reizt"!
(Obwohl es sicherlich nicht die Zukunft ist – diese Technik)
Aber nicht anders darstellbar für Christian, derzeit.

Mögen "Köpfe" "rauchen"!

[cbuchner1]

Original geschrieben von azapf1972

a) Der Traffic - nicht nur auf unserer Seite sondern auch auf Googles Servern - IMHO lädt TileProxy zu viel runter - nicht nur, dass das Gebiet (vorausschauend) sehr gross gewählt ist, nein - es lädt auch alle Zoom Level, damit es zumindest unscharfe Texturen darstellen kann, während es die anderen lädt... zumindest schließe ich das aus den Daten in meinem Cache.

Andreas [/b]

Rechenbeispiel: Jeder tieferliegende Zoomlevel reduziert die Datenmenge rund auf ein Viertel. Mal angenommen, der höchste Level braucht 100 MB (Rechenbeispiel!).

Dann muss man effektiv 100+25+6.25+1.56+... = 133 MB runterladen (also ca. 33% mehr) wenn man auch SÄMTLICHE kleineren Zoomlevel darunter haben will. Also wenn man die Landschaft schrittweise von matschiger Darstellung auf scharf bringt, braucht das etwa 33% mehr Transfers.

Seit Beta 3 und mit Verwendung von FSX SP1 lädt Tileproxy viel wirtschaftlicher. Er lädt nämlich fast nur noch, was FSX wirklich darstellt (falls bulk_extend auf 0 steht, ansonsten lädt er ein bisserle mehr).

FSX SP1 greift beim Laden eines neuen Fluges erst einmal überall auf die 4x4 Tiles zu (niedrigste Auflösung), um dann anschliessend entfernungsabhängig direkt die tatsächlich benötigten MIP Levels zu laden. Man kann ihm also nur vorwerfen, anfangs unnötigerweise die niedrigste Auflösung zu laden.

Wenn man sich dann im Flug langsam auf eine Tile zubewegt, dann wird tatsächlich Zoom Level auf Zoom Level geladen. Und man landet bei den 33% Mehraufwand (im Vergleich zur höchsten Auflösung).

[azapf1972]

Original geschrieben von cbuchner1
Gegen den höchsten Zoom level spricht die Mathematik. Jede Erhöhung des Zoom Levels um +1 vervierfacht leider die Pixelzahl und damit die Datenmenge.

Stimmt - allerdings stellt sich die Frage, welcher Level denn der "passende" ist - ich denke, Zoom Level 15 oder 16 würden es für die allermeisten Gebiete tun, vielleicht würde jemand gerne Stadt-Bereiche höher auflösen wählen... im übrigen liegt der höchste Zoom Level stellenweise (z.B. EDDF) bei 21 (und ich bin sicher, in USA ist er noch etwas höher...)

Ich weiß zwar nicht, wie Du genau auf 20GB Daten kommst (Ich denke, Du beziehst Dich auf Oahu) - letzendlich hängt die Datenmenge ja vom Gebiet ab, welches Du abgedeckt haben möchtest. Allerdings stimme ich Dir zu: der "Datenberg" ist gewaltig...

Und eben deswegen ja meine Befürchtung: Google wird Dir auf's Dach steigen, wenn Du nicht aufpasst! Aber genau das läßt sich mit TileProxy eben schlecht überwachen...

Original geschrieben von cbuchner1
Gegen Vorausladen habe ich echt was einzuwenden. Da wird nämlich die Grenze überschritten vom interaktiven Bildbrowser - hin zum automatisierten Download-Tool.

Ich bin mir nicht sicher, wo die Grenze eher überschritten wird: ein "Vorausladen", wie Du es nennst, ist ja genau das, was TileProxy macht - nur, dass er die Daten "ganz nebenbei" auch noch im FSX anzeigt. Fakt aber ist ein Bildbrowser müsste die Daten nach Ende der Betrachtung löschen und das tut TileProxy mit Absicht ja nicht! Und im übrigen würde ich den FS nicht als "Bildbrowser" betrachen... - aber das ist ja genau mein Punkt: TileProxy geht mit dem Service nicht "schonend" um!

Original geschrieben von cbuchner1 Ersterer läßt sich vielleicht noch irgendwie mit Nutzungsbedingungen vereinbaren, letzterer verstößt aber grob gegen die Terms of Service ("Robots" Klausel)

Ich fürchte, dass auch TileProxy gegen die Terms of Service verstösst... weswegen ich ja auch niemals mehr als eine rein intelektuelle Diskussion zu dem Thema führen würde...

Fakt ist: wenn die Nutzung von Tools wie TileProxy Überhand nimmt, dann macht Google die Türe dicht! Interessant ist aber momentan folgendes: wir diskutieren grade über die "Terms of Service" -

Google Earth Terms of Service
use any robot, spider, site search or retrieval application, or other device to retrieve or index any portion of Google services or collect information about users for any unauthorized purpose;

Allerdings nicken wir die ab, wenn wir Google Earth verwenden... was wir aber momentan nicht tun - kein Google Earth, keine Terms of Service, ist ja Google's Schuld, dass der Zugriff auf die Daten so einfach ist...

Allerdings: das ist keine Basis für eine Diskussion. Aber wenn ich schon die Terms of Service verletzen möchte, dann sollte ich das so unauffällig und Service-schonend wie möglich machen... Klar: wer hingeht und sich ganz... na, sagen wir England... auf LOD 17 lädt, muß a) eine sehr große Platte und b) nicht alle Tassen im Schrank haben! Wer aber gezielt Gebiete befliegen möchte, der wird sich unauffälliger verhalten, wenn er diese (evtl. zeitlich gestreckt) lädt als sie über TileProxy zu laden...

Und eines sollten wir auf keinen Fall vergessen: wie auch immer wir an die Daten kommen, weitergeben oder gar weiterverkaufen (RAW oder als Bestandteil einer Szenerie) darf man sie auf gar keinen Fall!

Andreas

PS: Im Übrigen finde ich die Idee wirklich genial! - Und aus dem Grund sollte man sich auch Gedanken darüber machen! - ich möchte meinen Beitrag ja auch nicht als "Meckern" verstanden haben, sondern als einen Denkansatz (der ja auch nicht vollständig und/oder richtig sein muß!) - aber wer sich nicht austauscht, der lernt nicht...

[cbuchner1]

Original geschrieben von azapf1972

Ich weiß zwar nicht, wie Du genau auf 20GB Daten kommst

ca. 30000 Tiles im Sichtfeld bei LOD Radius "minimum", 680 kb pro BMP Tile.
Gibt etwa 20 GB. Ganz grob überschlagen.

Runtergeladen als JPEG wird natürlich weniger. Das BMP ist ja fast unkomprimiert

Ein rollover cache ist in Planung, damit Tileproxy die Daten löscht. Eine der nächsten Betas... ausserdem habe ich da noch was im Hinterkopf, das die Gesamtzahl der auf der Festplatte liegenden Dateien dramatisch reduzieren wird. Aber ich sehe schon kommen, dass sobald ich eine maximal 30 Tage Regelung für die Caches erzwinge (Terms of Service Virtual Earth), der grosse Aufschrei durch die Leute geht, die ihre Szenerien "behalten" wollen.