OSM2World 0.2.0-dev: Technische Fragen

Wow, ging ja flott. :open_mouth:

Also, die untere Schicht wären einfach entfärbte Ziegelsteine. Die Textur und der Farbwert sollten so sein, dass die Steine hinterher passen, der Mörtel ist wurscht.

In der zweiten Textur (als separate Datei) dann den Mörtel in seiner natürlichen Färbung und mit Transparenz (partielle oder vollständige Transparenz über Alphakanal der jeweiligen Pixel) dort, wo die Steine zu sehen sein sollen.

Nahmd,

Ok.

Ein automatisierter Entfärber würde also die angelieferte Graphik in eine anzugebende Anzahl von Kanälen aufteilen, meistens einen, bei Steinen und Mörteln zwei, vielleicht gibts auch Anwendungen mit noch mehr Kanälen.

Danach wird jedes Pixel einem Kanal zugeordnet, und je Kanal wird eine Datei erstellt mit den Originalfarbwerten, aber nur den zum Kanal gehörenden Pixeln (Rest transparent), einer weiteren Graustufendatei (mit der gleichen Aufteilung opaque/transparent), und eine Textdatei mit dem ausgewählten Farbwert.

Hier ist ein erstes Beispiel. Ich bin gespannt, was ihr daraus bastelt.

Denn ich will hölzerne Holzhütten und steinerne Steinhütten sehen. Und Kühe.

Gruß Wolf

Edit: besseres Beispiel.

Es scheint derzeit noch Probleme bei Inseln zu geben:
http://maps.osm2world.org/?zoom=15&lat=53.61547&lon=11.47677
http://www.openstreetmap.org/?lat=53.6165&lon=11.4736&zoom=14

Da sind derzeit alle Gebäude ohne Land im Wasser :wink:

Dann vergleiche mal Kaninchenwerder mit der Insel Lieps (die wird dargestellt) weiter nördlich im gleichen See. Dort wird place=island um Umfang verwendet, bei Kaninchenwerder fehlt das. Ob man das nun als Fehler im Renderer ansieht oder als unvollständige Daten, das mögen kompetentere beurteilen.

Edbert (EvanE)

Hallo,
lustiges Problemchen:

Bei einer meiner beiden Mäuse (Microsoft Notebook Optical 3000) bewegt sich die Kamera rückwärts, egal in welche Richtung ich das Mausrad drehe. In anderen Programmen arbeitet die Maus korrekt.

Chris

Edit: Gelöst (in der Intellipoint Software kann man Ausnahmen definieren, die nicht mit dem weichen Bildlauf kompatibel sind).

Nahmd,

Ein wenig untergegangen: ich hatte da etwas gebastelt.

Wird ein Tool für diesen Bearbeitungsablauf noch gebraucht?

Gruß Wolf

Sorry, bin grade erst wieder vom Hack Weekend in Karlsruhe zurück. Werde mich darum und um eure anderen Posts aber ab morgen kümmern! :slight_smile:

So, ich fange mal mit den Abstürzen an. Als ersten Schritt für die Fehlersuche habe ich eine Version von OSM2World mit der allerneuesten JOGL-Bibliothek gebaut, um sicherzustellen, dass wir es hier nicht mit einem bereits behobenen Fehler zu tun haben:

http://tobias-knerr.de/temp/osm2world-jogl-2.0-rc11/OSM2World-noversion-bin.zip

Es würde mich freuen, wenn diejenigen, bei denen die 0.2.0-Entwicklungsversion nicht funktioniert, mal ausprobieren, ob das Problem auch mit dieser alternativen Version noch auftritt.

Gestern gab es auch einen Mesa-Update, der mit XCB und GLX zu tun hatte. Das hat aber nichts geändert. Mit der oben verlinkten Version gibt es den gleichen Absturz wie vorher. Allerdings funktioniert es jetzt unter VNC, so dass zumindest ich das Programm über diesen Umweg nutzen kann. Das ist schon ein blöder Fehler, da hier viele Komponenten zusammenspielen und nicht so richtig klar ist, was nun genau die Ursache ist.

Als erstes hab ich den Aufruf wieder geändert in:

java -Xmx1G -jar OSM2World.jar %*

Ergebnis:
Für einen Moment wird alles gut angezeigt, dann nach einem Klick (egal wo) kommt:

Dann bleibt nur das schließen von cmd, was auch den OSM-Viewer beendet.

Schade dass das neue JOGL das Problem noch nicht behoben hat, aber es stand fast zu befürchten. :confused: Als nächstes würde ich gerne prüfen, ob es an JOGL oder OSM2World liegt - ich stelle dazu demnächst was zusammen. Danke für eure Geduld.

So, jetzt aber auch @Netzwolf: Prinzipiell funktioniert das Einfärben der Texturen, auch mit den mehrlagigen Ziegeln - siehe hier:

Allerdings gibt es ein paar Probleme:

  • JOGL kann keine Graustufen-PNG lesen, ich habe es halt zum Testen dann wieder in ein normales Farb-PNG (mit nur grauen Pixeln) umgewandelt.

  • Die grauen Texturen sind vergleichsweise dunkel, so dass die Farbe im Ergebnis auch deutlich dunkler ist als das, was der Mapper angefragt hat.

  • Und jetzt das große Problem: OSM2World kann wie gesagt nur die unterste Schicht einfärben, und das Einfärben ist “aus technischen Gründen” auch für die Berücksichtigung der Beleuchtung nötig. Daher sind die Fugen auf nicht frontal mit voller Intensität beleuchteten Wänden immer deutlich zu hell.

Die normal entfärbten Texturen haben das Texturschichtproblem natürlich nicht, das sollte was werden.

Für Ziegel & co muss ich aber wohl erst noch mal den Code umbauen. Bis jetzt fehlt mir die zündende Idee dafür…

Nahmd,

Von der Einschränkung wusste ich leider nichts. Das ist aber trivial zu lösen, und die Dateien sind maximal gerade einmal ½kb größer, alldieweil die Graustufenbilder mit ≦ 256 Farben immer über Farbtabelle codiert werden.

Ich hatte dazugeschrieben, dass ich den Schritt “Aufhellen” übersprungen habe. Ich sorge natürlich später dafür, dass das rückgefärbte Bild (soweit im RGB-Farbraum möglich) die gleiche Gesamthelligkeit hat wie das Originalbild.

Das heißt, die Helligkeit wird über eine Veränderung der Einfärbung realisiert?

Das Problem besteht also darin, dass die Fugen sich nicht an die Beleuchtungsstärke anpassen? Da kann ich dann leider nichts machen. Mist. :confused:

Sehr schön. :wink: Dann habe ich Zeit, das Verfahren in Ruhe ordentlich zu implementieren.

Gruß Wolf

Das ist ein Fehler in den Daten. Am outer-Way steht ein natural=water. Tags an outer-Ways gelten aber nur bei ungetaggten Multipolygonen für die Fläche des Multipolygons. (Laut Wiki: “If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged.”)

Wenn das Multipolygon wie hier eigene Tags hat, dann gelten die Tags am outer-Way für den Way selber, nicht für das Multipolygon.

Was mir noch nicht gefällt, ist dass viele landuses und sonstiges “drumherum”. Was kann man denn tun, damit das besser wird? Komme zwar erst am nächsten Wochenende dazu, irgendetwas zu machen, aber fragen kann man ja schon einmal :slight_smile:

Ansonsten: Super Sache, das.

http://forum.openstreetmap.org/viewtopic.php?pid=317742#p317742

Dass viele relevante landuses nicht auftauchen liegt an einer Schwäche des Codes. Er kann noch nicht zuverlässig am Boden Platz für Wege schaffen, die durch eine Fläche führen. Da so etwas bei landuse natürlich öfter vorkommt, halte ich mich mit der Auswertung der entsprechenden Tags noch zurück.

Was sonstiges “drumherum” angeht: Das ist in vielen Fällen einfach nur eine Sache dessen, dass noch niemand Code geschrieben hat (also eine Zeit-/Arbeitsfrage), wäre aber für Programmierer mit Java-Kenntnissen eine vergleichsweise leichte Übung. Bei manchen Objekten fehlen auch Texturen. Wenn du genaueres wissen willst, müsstest du etwas konkreter werden.

Apropos Texturen
Ich habe mir vor einigen Tagen OSM2World 0.1.9 herunter geladen und die Beispiel-Texturen. OSM2World 0.1.9 läuft soweit ganz gut und ist sehr nützlich um einiges auszuprobieren.

Leider scheint es mit den Farben und Texturen nicht zu klappen. Ich rufe folgendes auf:
./osm2world.sh --gui --config “…/OSM2World_Texture_2012-07-15/texture_config.properties”

Nur wird leider nichts eingefärbt und keine Fenster gezeichnet. Ich bekomme diesen Output auf der Shell.

unknown material: RED_ROAD_MARKING
unknown material: ROAD_CROSSING_ZEBRA
unhandled geometry type: class com.vividsolutions.jts.geom.LineString

Was läuft bei den Texturen noch schief? (Die Probleme den Aufruf herauszufinden und mit den Leerzeichen im Ordner-Namen lasse ich mal weg.)

Weiter bekomme ich eine ganze Latte von NullPointerException wegen Wegkreuzungen (das ist jedoch unabhängig von den Texturen):

ignored exception:
java.lang.NullPointerException
	at org.osm2world.core.world.network.JunctionNodeWorldObject.getTriangulation(Unknown Source)
	at org.osm2world.core.world.modules.RoadModule$RoadJunction.renderTo(Unknown Source)
	at org.osm2world.core.target.TargetUtil.renderObject(Unknown Source)
	at org.osm2world.viewer.model.Data$1.perform(Unknown Source)
	at org.osm2world.viewer.model.Data$1.perform(Unknown Source)
	at org.osm2world.core.util.FaultTolerantIterationUtil.iterate(Unknown Source)
	at org.osm2world.viewer.model.Data.createPrimitiveBuffer(Unknown Source)
	at org.osm2world.viewer.model.Data.loadOSMFile(Unknown Source)
	at org.osm2world.viewer.control.actions.OpenOSMAction$OpenOSMThread.run(Unknown Source)
this exception occurred for the following input:
junction node WO for (11883764 at 50.7080642, 7.1352432, {ref=1, highway=motorway_junction, TMC:cid_58:tabcd_1:LCLversion=9.00, name=Bonn-Bad Godesberg, TMC:cid_58:tabcd_1:Class=Point, TMC:cid_58:tabcd_1:NextLocationCode=11750, TMC:cid_58:tabcd_1:LocationCode=11749})
...

Kann ich die einfach ignorieren oder weist das auf Probleme in den Daten hin, um die ich mich besser kümmern sollte?

Edbert (EvanE)

Dass das nicht klappt hat einen einfachen Grund: 0.1.9 ist dafür zu alt. Ich gebe zu, dass der Hinweis “if you are using the latest build and want to see textures” beim Texturpack nicht sehr auffällt…

Das würde glaub ich auch in 0.2.0 noch auftreten. Bei manchen Features ist der Kartenstil dem Code etwas voraus. :wink:

Ignorieren. Einige wenige Fälle sind vielleicht Datenprobleme, aber die gehen in der viel größeren Zahl derjenigen unter, wo die primitive Kreuzungsberechnung von OSM2World versagt. Auch hier würde 0.2.0 leider noch wenig ändern.

OK, dann werde ich morgen einen Versuch mit dem latest build wagen. Zugegebener Weise habe ich den Hinweis überlesen.

Das hatte ich mir wegen der vielen Meldungen fast gedacht.
Heute hatte mir OSM2World ein selbst-überschneidendes Polygon gemeldet. Das war in der Tat ein Fehler in den Daten (Validator fand den Fehler auch). Bei den vielen überlappenden Linien für die Building-Parts war es mir nicht möglich, die Ursache zu erkennen. So habe ich das fehlerhafte Polygon kurzer Hand gelöscht und neu erstellt. Danach ging es wieder.

Das Gebäude des Maritim Hotels in Bonn, weswegen ich überhaupt mit 3D angefangen habe, ist jetzt auch in der SlippyMap so wie ich es wollte und (in groben Zügen) der Realität entspricht.
Wie du an den vielen weiteren 3D-Gebäuden in der Umgebung siehst, hat mich das Thema gepackt. :slight_smile:

Edbert (EvanE)

Ist zwar schon etwas her, aber letztlich gibt es doch einen Erfolg zu vermelden: Viele Updates aller beteiligten Komponenten später funktioniert es jetzt bei mir ohne Umwege. Die Ursache war letztendlich eine längere Kette von kleinen Unzulänglichkeiten, und meine Konfiguration war eine von den Kombinationen, in der es zu einem Problem geworden ist.