Ich hab die Grafiken von Marek bereits abgegriffen.
Wenn ich das Entfärben hinbekomme, gieße ich es in ein Script und dann heißt es: Selbstbedienung.
Ich hab von Grafikbearbeitung exakt 0 Ahnung. Es reicht gerade mal zum Erstellen eines Icons mit xpaint (schäm). Aber eine Gelegenheit zum Entfernen der Wahnvorstellung “Farbe” aus der Welt – die lasse ich mir natürlich nicht entgehen.
Was mir gleich aufgefallen ist: wenn ich entfärbe, und dann mit einer beliebigen Farbe wieder einfärbe, ist die entstehende Fläche einfarbig, also weniger natürlich als das Original.
Man könnte leicht beim Entfärben mehr als einen “Kanal” erzeugen: dann gäbe es z.B. zwei Graustufenbilder, aber beide mit Teiltransparenz. Die Aufteilung in Kanäle ist technisch leicht (Vektorquantisierer), die würde bei den Backsteinen Steine und Mörtel trennen oder beim Zaun die Holzlatten und den Hintergrund.
Die Einzelbilder kann man getrennt einfärben und wieder übereinanderlegen. Die Frage ist: lohnt das? Genauer: kann die 3D-Software damit überhaupt etwas anfangen? Ich kenne mich mit 3D überhaupt nicht aus.
OSM2World kann mehrere Einzelbilder übereinanderlegen. Dabei verdecken die “oben” liegenden Texturen die darunterliegenden, außer dort wo die Pixel einen teilweise oder komplett transparenten Alphawert haben.
Die unterste Textur hat dabei eine besondere Rolle, denn diese lässt sich optional einfärben, dazu werden dann die rgb-Werte im Texturpixel (im Intervall 0 bis 1) mit denen der Farbe multipliziert. Die darüber liegenden Schichten lassen sich hingegen nicht einfärben - aber wir haben ja ohnehin normal nur einen Farbwert als Tag zur Verfügung.
Transparenz in der untersten Textur spielt natürlich keine Rolle beim Kombinieren der Texturen, sondern ist dann interessant, wenn das Objekt dort komplett durchsichtig sein soll, z.B. Lücken im Zaun.
Gibt es dafür ne Anleitung, damit sich der Laie etwas drunter vorstellen kann und ggf. auch etwas beitragen kann?
So in etwas: Aus Foto wird Grafik (vorher/nachher), beachte.
Edit: Werden lediglich halbtransparente GIF-Dateien benötigt, so wie für die Webseitengestalltung?
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.
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.
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.
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).
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:
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.
Schade dass das neue JOGL das Problem noch nicht behoben hat, aber es stand fast zu befürchten. 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…
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.
Sehr schön. Dann habe ich Zeit, das Verfahren in Ruhe ordentlich zu implementieren.
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
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.
