Huch…das ist ja ne ganz andere Seite

Ich hatte hier geschaut…! Danke für den richtigen Link
http://wiki.openstreetmap.org/wiki/Glosm

@Tordanik: habe jetzt auf mind. 50 Gebäuden die Parameter gesetzt - beim laden stürzt der aber ab (bei “generating terrain…”

“JTS triangulation failed” steht in der Konsole als letzter Fehler.

Wenn du selber testen magst - die Daten sind oben:
http://www.openstreetmap.org/?lat=51.24472&lon=9.25826&zoom=15&layers=M

Ich hab deine Region gerade mal manuell auf dem Server angestoßen und das hat Problemlos geklappt. Es gab zwei kleinere Fehler in den Daten, die aber kein Grund für einen Absturz sind und wie man in der Slippymap sieht, passt da auch alles http://maps.osm2world.org/?zoom=17&lat=51.24626&lon=9.25561&layers=B0TTFF

Ich habe das ganze mit diesem Datensatz aus der Overpass-API getestet. Kann dein Problem also nicht wirklich nachvollziehen. Ist das evtl. eine nested Exception und eigentlich OutOfMemory oder sowas? Ansonsten bitte auch mal noch mehr von der Exception pasten.

Muss ich heut Abend mal schauen; bin grad auf Arbeit. Könnte auch an den Texturen gelegen haben. Hab eine 4096er Skytextur und zwei andere mit eingebaut + in der Config die Texturgröße von 1024 auf 4096 gestellt…
Die Performance bei texturierter Darstellung (mit deinen Standardtexturen) ist unter Java natürlich net soo der Hammer (hab 4x3 Ghz zur Verfügung…denke es wird auch nur ein Thread gestartet). Gibts hier keine Hardwareunterstützung?

Zu deinem Server: renderst du das ganze mit POVRay?

Auch wenn’s am neuen Thema vorbei geht ;)…

Probier mal Trigger Shot aus: https://play.google.com/store/apps/details?id=com.krugism.triggershot
Das hatte ich vor knapp einem Jahr verwendet und in meinem Urlaubsgebiet Fotos gemacht und danach gemappt. Damals noch mit einer selbst zusammengeschusterten Halterung. Die Ergebnisse waren nicht sooo schlecht. Hätte das Gerät noch eine halbwegs vernünftige Kamera…Aber das ist wieder ein anderes Thema.

Inzwischen ist eine “richtige” Halterung vorhanden. Bei dieser vibriert das Handy aber zu stark, die Fotos werden so nix. Da muss ich mir nochmal was überlegen. Aber die App an sich funktioniert gut.

Als Intervall habe ich 2 Sekunden gewählt. 5 Sekunden sind meiner Meinung nach zu viel, da gehen einem zu viele Infos flöten. Die App hört übrigens auf zu knippsen wenn das Display aus geht. Könnte vielleicht auch das Problem sein, dass du nur 5 Bilder bekommen hast bei deinem ersten Versuch.

Genau DIE App hatte ich ja gestartet…nach 5 Fotos oder so hat dre aufgehört… ah…ja, das Display war nach kurzer Zeit aus! Danke für den Tipp Probier ich nachher wieder aus…oder gleich mal in der Pause ne Runde mit dem Auto fahren

Da muss man unterscheiden: Der Konvertierungsprozess, bevor irgendwas gerendert wird, ist Java. Das eigentliche Rendering im Client nutzt OpenGL und ist hardwarebeschleunigt - allerdings hoffentlich von einer Grafikkarte, nicht vom Hauptprozessor - und da dürfte Java dann keine Rolle mehr spielen.

Beides sollte sich noch massiv optimieren lassen, muss halt jemand machen.

Nein, hatten wir ganz am Anfang mal gemacht, war aber viel zu langsam um ein größeres Gebiet abzudecken. Der Slippymap-Server nutzt jetzt wie der Client OpenGL. POVRay nutzen wir selber momentan nur für Einzelbilder, wie einige der Screenshots auf der Website.

Eventuell könnte man irgendwann mal wieder eine Karte von handverlesenen Gebieten mit POVRay machen, aber das ist derzeit nur eine Idee.

Also FALLS es mit OpenGL läuft, dann läuft es bei mir sicherlich nicht über die Grafikkarte ;)) Mit einer GTS450 sollte das Dörfchen ohne Probleme laufen (CPU: AMD A6-3670K, 4x3 Ghz) …ich hab jedenfalls eine Ruckelshow, wenn Texturen aktiviert sind. Kann sonst aktuelle Spiele mit 8xAA/16xAF und Full-HD problemlos spielen… und hier ist ja noch nicht mal Schatten, AA oder sonst was aktiviert

Ahso…ja ist sicherlich um einiges schneller Zudem wäre es ja in der selben Qualität wie die Echtzeitansicht, wenn mal alle Texturen usw. drin sind.

Ich habe endlich ein wenig Zeit in der Pause eben gefunden und mich an die Skybox sowie Wassertextur gesetzt - Schatten auch schon mal weich gemacht. Hier mal ne Voschau (habt ihr bei osm2world ein eigenes Forum oder etwas in der Richtung…?):

Gruß
Paul

Sieht ja nett aus Wir haben ja auch schon einige Passau-Bilder gerendert, aber die von dir gewählte Perspektive gefällt mir da schon besonders gut. Hatten wir bisher noch nie

Zur Textur muss ich aber anmerken, dass sie - obwohl sie mir wegen dem realistischeren Look recht gut gefällt - nicht ganz korrekt ist. Die Ilz ist nämlich ein sehr sauberer klarer Fluss, nicht wie die dreckige Donau!!

Und dann hab ich da noch ein paar Kleinigkeiten, an denen wir auch schon ein paar Detailverbesserungen gemacht hatten die du vermutlich noch nicht kennst. Auf http://osm2world.org/download/ gibt es die POVRay tree models für hübschere Bäume. Dafür musst du dann nur das zip entpacken, da ist dann unter anderem ein .ini-File für die besseren Baum-Definitionen drin die du in der Hauptconfig osm2world_definitions.inc auch einfach durch einkommentieren des entsprechenden Includes aktivieren kannst. Außerdem haben wir vor einiger Zeit mal noch tolle spiegelnde Fenster gebastelt die ebenfalls in der Hauptconfig (auskommentiert) enthalten sind. Die Texture-Map dazu haben wir bisher leider noch nie offiziell gepackt, aber Tobias hat es netterweise eben auf seinen Server gesetzt, die findest du hier. Da wir (oder zumindest ich) eher wenig Ahnung von POVray haben und das nur mit viel Google hinbekommen: Die Config für den weichen Schatten wäre sicher auch nett für die Default-config und auch sonst wenn du da noch weitere Tips für uns hast, nur her damit

Forum haben wir keines, passiert eigentlich alles hier über das OSM-Forum und teilweise noch etwas auf der talk-de Mailingliste.

Also bei der Wasserfarbe habe ich mich an Luftbildern orientiert
Das ist etwas, was noch bei den OSM-Definitionen fehlt - es gib ultraklare, blaue flüsse…oder grünliche…oder einfach nur Drecksbrühen…irgendwie ein color=blue/green/brown müsste noch rein Ich will noch diverse Wasserparameter für Bach, See, Teich usw. erstellen. Die sind da schon ganz unterschedlich. Habe auch nette, copyrightfreie, gras und kiesel (=bachgrund) Texturen gefunden…
Was nett wäre: die texture {} durch material {} in der INI und dem Generator umstellen. Das Wasser hat jetzt nämlich u.a. Lichtbrechung und Frensel-Spiegelung, welche im Material und nicht der Textur angegeben wird…schadet nicht, direkt alle auf Material umzustellen

Die Haupt-INI will ich noch um paar Paramter ergänzen - ihr habt es schon mit der Jahreszeit Sommer angefangen:
Tageszeit (morning, afternoon, night) → beeinflusst Sonnendefinition, Skysphere, Beleuchtung (z.B. bei jeder Laterne eine Spot-Lightsource, die dann aktiviert wird)

Wetter (sunny, rainy, windy, storm) → beeinflusst alle Texturen und Wasseroberflächen. Stärke des Nebels bzw. Dunstes. Wellenhöhe und -unregelmäßigkeit wird je nach Windstärke entsprechend angepasst. Bei rainy gibts zus. Kringel auf dem Wasser und alle Texturen sind “naß” (=überall auch Spiegelung).

Und dann zum Schluß noch die Jahreszeiten, wodurch Texturen ausgetauscht werden (schnee statt grün) und Schnee fällt (kann mich da noch an ein ganz tolles Makro Anfang letzten Jahrzents erinnern, was 3D-Schnee auf Objekten generiert hat)

Zum Thema Flussfarbe:
http://passauer-land.putzwerbung.de/bilder/passau1.jpg

Scheint hier aber nur der eine Ärmel ganz schön dreckig zu sein

Ich hatte mich an diesem hier orientiert…da war wohl schlechteres Wetter. Hier sieht man kein HImmelblau als Spiegelung drauf:
http://www.nuernbergluftbild.de/pictures/k06110340.jpg

EDIT:
So - meine erste Natur-Testlandschaft für O2W und POV-Ray Texturtests wäre soweit (ca. 190x145 Meter). Habe gemische Wälder sowie Nadel- und Laubwälder getrennt. Grundfläche ist Wiese. Einen Fluss, eine Strasse, paar Wege, zwei Bäche, zwei Jägerhochsitze und einen Teich.

Unter diesen ‘kontrollierten Bedingungen’ fallen mir gleich drei Sachen auf:

• die Skalierung scheint ganz gut zu stimmen. Der See ist 56 Meter lang (vom Bach zum Bach). Entsprechend sind die Bäume dann ca. 5 - 20 Meter hoch
• die Baumdichte in Wäldern ist gering bis gar nicht vorhanden. Die zwei Nadelwälder recht fehlen vollständig - wird hier evlt. das Tag nicht erkannt? Bäume im Wald würde ich allgemein größer ansetzen + in Abständen von vielleicht 4 oder 5 Metern zueinander streuen. Das dürfte hübsche Wälder ergeben
• meine Waldpfade (highway=path) ohne ‘ground’-Angabe sind aus Asphalt
  Diese müssten auch ohne Extra-Angaben aus “ground” bestehen → http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath

Spreewald bei SPON:

http://cdn1.spiegel.de/images/image-480754-galleryV9-ricc.jpg

Sven

Morgen,

anbei ne kleine Vorschau eines stärker bewölkten Tagesscene und leicht nebliger Morgenscene (Passau)
Die Wolken werden via Media in POV-Ray generiert, was leider aber ganz schön an der Performance zieht…das obere Bild hat etwa 15 Minuten gerendert (A 0.3, 4 x 2,8 Ghz A6-AMD). Ohne die Wolken liegts bei nicht mal 2…
Bei der Morgenscene habe ich nur eine kleine Wolke eingesetzt - die verlangsamt kaum.

Was mir bei Wasseroberflächen aufgefallen ist - diese nicht nicht absolut plan! Siehe Spiegelung der Bäume hinten links…

Gruß
Paul

Sieht super aus

(pssst, wird aber langsam OT )

Danke (jaaa…hab ich mir auch gedacht ;> Deshalb ja die Frage, ob o2w nicht extra iwo ne Seite hat )

Oh, hab grad erst deinen Edit im alten Post gesehen.

Wenn ich mich nicht täusche, sollten Waldbäume bereits ein höheres Maximum haben als andere. Zur Dichte schau mal bei http://wiki.openstreetmap.org/wiki/OSM2World/Configuration_file - speziell treesPerSquareMeter.

Ich will hier keine erneute “path”-Diskussion lostreten, aber OSM2World stützt sich zumindest im Moment nicht auf die Interpretation von highway=path als “Trampelpfad”/“Waldweg”, da diese Bedeutung im Proposal von path nicht vorhanden war, sondern erst nachträglich entstanden ist (und sicher nicht von allen Mappern geteilt wird). Daher werden alle Wege - footway, cycleway, bridleway und path - gleich behandelt.

Danke für den Link - in die config hatte ich bisher nicht geschaut. Dachte da werden nur die Texturen definiert. Dieser Default-Eintrag ist ja wirklich mehr als unsinnig:

tree density in forests

treesPerSquareMeter = 0.001

Wenn ich richtig rechne, komme ich auf ein Baum pro Quadratkilometer… Wer hat diese merkwürdige Zahl ausgerechnet bzw. auf welchen Wald ist das bezogen?

Bzgl. “Path” habe ich mich auf den Wiki-Eintrag bezogen - hier steht nur was von Waldwegen. Sogar auf dem Foto und den Beispielen zu erkennen:
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath

Waldpfade habe ich schon immer mit path getaggt - und Fußwege aus Asphalt als footway. So habe ich das auch von anderen gesehen. Mh…

Es sind 1000 Bäume pro Quadratkilometer, weil 1 km² = 1.000.000 m².

Trotzdem natürlich zu wenig. Das ist einfach aus Performancegründen so gewählt - früher brauchtest du da nur eine Ecke von einem riesigen Wald-Multipolygon in deiner Bounding Box zu haben und der Viewer ist komplett zusammengebrochen.

Inzwischen ist die Performance dank Vertex Buffer Objects und dem Wegschneiden von Waldstücken außerhalb der Bounding Box (falls vorhanden) aber besser geworden. Von daher könnte ich den Default wohl erhöhen, wenn ich dazu komme die config aufzuräumen. Dafür wäre interessant, bei welchem Wert du am Ende deiner Experimente landest.

Die Slippymap nutzt übrigens 0.01.

AAh…ja. Danke für die Korrektur. Bei 0,25 hat der sich grad weggehangen - und bei 0.1 sieht meine Testscene von Oben so aus

Kennt jemand von Euch ein Tool mit dem man ein Video (mit SRT-File das Timestamps und Koordinaten enthält) in Einzelbilder zerlegt und diese dann mit den Infos aus dem Untertitel-File synchronisiert?

Will sagen: Ich habe hier aus meinem “Registrator Viewer” (sieht so aus viele abgefilmte Wege. (Beispiel Landstraße, Beispiel Autobahn und Beispiel Ortschaft.)

Wenn es dafür eine sinnvolle Nutzung geben würde für OSM wäre ich dem aufgeschlossen. (Ich selbst schaffe es nicht, das alles(!) selbst nachzumappen, was man daraus ziehen kann.)

P.S. Und bevor Einwände hinsichtlich der Lesbarkeit von Schildern etc kommen: Die Qualität der lokalen Dateien ist zumindest etwas besser als das was Youtube nach dem Umkodieren (selbst bei 1080er-Auflösung) draus macht. Ich würde die Videos daher nicht erst zu Youtube pumpen (abgesehen von dem überflüssigen Upstream-Traffic…)