MarcoReitano / AvSS17

1 stars 0 forks source link

SRTMDataCells evtl. in gemeinsames Filesystem vom Server downloaden lassen #7

Closed DennisBuderus closed 6 years ago

DennisBuderus commented 7 years ago

Es wäre sinnvoll die SRTM Dateien vom Server herunterladen zu lassen, damit nicht jeder Client die gleiche Datei herunterladen muss.

schwedenmut commented 7 years ago

Aktuelles Problem, dass SRTMDataCells.cs Zeile 490 ff. nicht wirklich greifen.

schwedenmut commented 7 years ago

Aktuell werden die SRTM Daten - zumindest unter macOS - an einem suboptimalen Speicherort persistiert.

bildschirmfoto 2017-09-28 um 15 49 10

Man beachte den Pfadnamen XD

DennisBuderus commented 7 years ago

Das ist der Pfad, der noch von mir in den projectsettings zuletzt verwendet wurde... Der ist nicht wirklich hard-coded irgendwo drin... Dafür hatten wir ja diese Meldung vorher drin, dass der osm und srtm path gesetzt werden muss... Hab das quasi nur mitgepusht...

Gesendet von VMware Boxer

Am 28.09.2017 15:52 schrieb schwedenmut notifications@github.com:

Aktuell werden die SRTM Daten - zumindest unter macOS - an einem suboptimalen Speicherort persistiert.

Man beachte den Pfadnamen XD

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

schwedenmut commented 7 years ago

Der ist nicht wirklich hard-coded irgendwo drin

https://github.com/MarcoReitano/AvSS17/blob/a3312528585bf471116e3dd001fd591c91a65590/AVSUnity/Assets/SRTM/SRTMHeightProvider.cs#L51 und wird dann mit weiteren Daten erweitert: https://github.com/MarcoReitano/AvSS17/blob/a3312528585bf471116e3dd001fd591c91a65590/AVSUnity/Assets/SRTM/SRTMDataCell.cs#L48

Somit ist der Path doch hard-coded drin, oder nicht @DennisBuderus ?!?

DennisBuderus commented 7 years ago

Hola... Wie ich gestern schon geschrieben habe: den Pfad soll man eigentlich über das config-editorwindow setzen, damit er in den editorprefs gesetzt wird.. Die "hard-coded" Initialisierung kann auch weggelassen werden, dann wird darauf hingewiesen, dass der Pfad nicht gesetzt ist. Ist quasi nur ein fallback während der Entwicklung gewesen, damit der auf jeden Fall gesetzt ist... Eigentlich sollte jeder den aber für sich konfigurieren... Hätten wir den fallback weggelassen, würde es solange nicht wirklich funktionieren bis du ihn selbst setzt... So hab ichs zumindest gerade in Erinnerung..

VG Dennis

Gesendet von VMware Boxer

Am 29.09.2017 16:56 schrieb schwedenmut notifications@github.com:

Der ist nicht wirklich hard-coded irgendwo drin

https://github.com/MarcoReitano/AvSS17/blob/a3312528585bf471116e3dd001fd591c91a65590/AVSUnity/Assets/SRTM/SRTMHeightProvider.cs#L51 und wird dann mit weiteren Daten erweitert: https://github.com/MarcoReitano/AvSS17/blob/a3312528585bf471116e3dd001fd591c91a65590/AVSUnity/Assets/SRTM/SRTMDataCell.cs#L48

Somit ist der Path doch hard-coded drin, oder nicht @DennisBuderus ?!?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

schwedenmut commented 7 years ago

Hmmm, macht halt nur wenig Sinn bei Workern ein GUI Fenster zu öffnen, wo man dann einen bzw. mehrere Speicherpfade hinterlegen muss.

schwedenmut commented 7 years ago

https://thenewstack.io/methods-dealing-container-storage/

DarkMuesli commented 6 years ago

Info: Die Größen der SRTM-Datenpakete bewegen sich vom einstelligen KB bis zum (niedrigen) einstelligen MB Bereich. (Ich habe bei Stichproben nichts > 1,5 MB gesehen). Im worst-case also das vierfache davon, wenn ein Tile genau im Schnittpunkt liegt. Zum Vergleich: Eine serialisierte Szene bewegt sich (je nach Serialisierung und Tilegröße) im ein- bis dreistelligen MB Bereich. Die SRTM-Daten kommen zwar im Gegensatz dazu von außen, aber aufgrund unserer extrem guten Internetanbindung gibt es keine dringende Notwendigkeit für ein gemeinsames Filesystem.

DarkMuesli commented 6 years ago

Nicht notwendig - Evtl. für zukünftige Releases interessant.