OSM2World 0.2.0-dev: Technische Fragen

Dann mach ich mal den Anfang: Das latest build-Release (0.2.0OSM2World-latest-bin.zip) läßt sich bei mir garnicht starten. V.0.1.9 läuft super.
XP SP3 Lenovo NB 2GB Ram, 1,58GHz, Java 6 Build 31
Klick auf osm2world-windows.bat öffnet cmd, die sich sofort auch wieder schließt. das wars... 🙁

Bei mir passiert mit dem latest (von gerade eben) unter Linux (openSUSE 12.2 x86_64) auch nicht viel außer:

#␣A␣fatal␣error␣has␣been␣detected␣by␣the␣Java␣Runtime␣Environment:
#
#␣␣SIGSEGV␣(0xb)␣at␣pc=0x00007f635a72fd90,␣pid=5344,␣tid=140064691083008
#
#␣JRE␣version:␣7.0_09-b30
#␣Java␣VM:␣OpenJDK␣64-Bit␣Server␣VM␣(23.2-b09␣mixed␣mode␣linux-amd64␣compressed␣oops)
#␣Problematic␣frame:
#␣C␣␣[libxcb-glx.so.0+0xed90]␣␣xcb_glx_get_string_string_length+0x0

Es gibt dazu noch längliche Traces, aber die sagen mir nicht viel. Wäre toll, wenn jemand was damit anfangen und zur Fehlerbeseitigung beitragen kann:

Stack:␣[0x00007f635a185000,0x00007f635a286000],␣␣sp=0x00007f635a284188,␣␣free␣space=1020k
Native␣frames:␣(J=compiled␣Java␣code,␣j=interpreted,␣Vv=VM␣code,␣C=native␣code)
C␣␣[libxcb-glx.so.0+0xed90]␣␣xcb_glx_get_string_string_length+0x0

Java␣frames:␣(J=compiled␣Java␣code,␣j=interpreted,␣Vv=VM␣code)
j␣␣jogamp.opengl.GLContextImpl.glGetStringInt(IJ)Ljava/lang/String;+0
j␣␣jogamp.opengl.GLContextImpl.initGLRendererStrings()V+39
j␣␣jogamp.opengl.GLContextImpl.setGLFunctionAvailability(ZIII)V+74
j␣␣jogamp.opengl.GLContextImpl.createContextARBVersions(JZIIIII[I[I)J+174
j␣␣jogamp.opengl.GLContextImpl.createContextARBMapVersionsAvailable(IZ)Z+118
j␣␣jogamp.opengl.GLContextImpl.mapGLVersions(Ljavax/media/nativewindow/AbstractGraphicsDevice;)Z+21
j␣␣jogamp.opengl.GLContextImpl.createContextARB(JZ)J+123
j␣␣jogamp.opengl.x11.glx.X11GLXContext.createImplRaw(Ljogamp/opengl/GLContextImpl;)Z+681
j␣␣jogamp.opengl.x11.glx.X11GLXContext.createImpl(Ljogamp/opengl/GLContextImpl;)Z+17
j␣␣jogamp.opengl.GLContextImpl.makeCurrentWithinLock(I)I+47
j␣␣jogamp.opengl.GLContextImpl.makeCurrent()I+191
j␣␣jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(Ljava/lang/String;)Ljogamp/opengl/SharedResourceRunner$Resource;+275
j␣␣jogamp.opengl.SharedResourceRunner.run()V+270
j␣␣java.lang.Thread.run()V+11
v␣␣~StubRoutines::call_stub

---------------␣␣P␣R␣O␣C␣E␣S␣S␣␣---------------

Java␣Threads:␣(␣=>␣current␣thread␣)
=>0x00007f63787af000␣JavaThread␣"main-SharedResourceRunner"␣daemon␣[_thread_in_native,␣id=5366,␣stack(0x00007f635a185000,0x00007f635a286000)]
0x00007f63786cf000␣JavaThread␣"AWT-EventQueue-0"␣[_thread_blocked,␣id=5365,␣stack(0x00007f635b3ce000,0x00007f635b4cf000)]
0x00007f63786ce000␣JavaThread␣"AWT-Shutdown"␣[_thread_blocked,␣id=5364,␣stack(0x00007f635bad7000,0x00007f635bbd8000)]
0x00007f6378514800␣JavaThread␣"process␣reaper"␣daemon␣[_thread_blocked,␣id=5361,␣stack(0x00007f6370040000,0x00007f6370068000)]
0x00007f63784ff800␣JavaThread␣"AWT-XAWT"␣daemon␣[_thread_in_native,␣id=5359,␣stack(0x00007f6360121000,0x00007f6360222000)]
0x00007f63784c6000␣JavaThread␣"Java2D␣Disposer"␣daemon␣[_thread_blocked,␣id=5358,␣stack(0x00007f6360222000,0x00007f6360323000)]
0x00007f63781da000␣JavaThread␣"Service␣Thread"␣daemon␣[_thread_blocked,␣id=5356,␣stack(0x00007f636b7c9000,0x00007f636b8ca000)]
0x00007f63781d8000␣JavaThread␣"C2␣CompilerThread1"␣daemon␣[_thread_blocked,␣id=5355,␣stack(0x00007f636b8ca000,0x00007f636b9cb000)]
0x00007f63781d5000␣JavaThread␣"C2␣CompilerThread0"␣daemon␣[_thread_blocked,␣id=5354,␣stack(0x00007f636b9cb000,0x00007f636bacc000)]
0x00007f63781d3000␣JavaThread␣"Signal␣Dispatcher"␣daemon␣[_thread_blocked,␣id=5353,␣stack(0x00007f636bacc000,0x00007f636bbcd000)]
0x00007f6378178800␣JavaThread␣"Finalizer"␣daemon␣[_thread_blocked,␣id=5352,␣stack(0x00007f636bcfd000,0x00007f636bdfe000)]
0x00007f6378176800␣JavaThread␣"Reference␣Handler"␣daemon␣[_thread_blocked,␣id=5351,␣stack(0x00007f636bdfe000,0x00007f636beff000)]
0x00007f6378009000␣JavaThread␣"main"␣[_thread_blocked,␣id=5345,␣stack(0x00007f6381646000,0x00007f6381747000)]

Other␣Threads:
0x00007f637816e000␣VMThread␣[stack:␣0x00007f636beff000,0x00007f636c000000]␣[id=5350]
0x00007f63781e5000␣WatcherThread␣[stack:␣0x00007f636b6c8000,0x00007f636b7c9000]␣[id=5357]

VM␣state:not␣at␣safepoint␣(normal␣execution)

VM␣Mutex/Monitor␣currently␣owned␣by␣a␣thread:␣None

Die 0.1.9 läuft problemlos. Das JOSM-Plugin kendzi3d bringt JOSM mit der gleichen Fehlermeldung zum crashen.

Kamera fängt nach einiger Zeit an zu "zittern", so dass man resetten muss.

Vorschlag für Kamerabewegung:

nach links/rechts drehen: left/right
vorwärts/rückwärts bewegen (parallel zum Erdboden, in Kamerarichtung): runter/hoch Taste (schneller mit Shift)
Kamera hoch/runter bewegen: Page Up/Down
Kamera hoch/runter schwenken: Ctrl- Up/Down

Die Blickrichtung (N,S,O,W) und Kamera Höhe sollte angezeigt werden.

Chris

reneman wrote:

XP SP3 Lenovo NB 2GB Ram, 1,58GHz, Java 6 Build 31
Klick auf osm2world-windows.bat öffnet cmd, die sich sofort auch wieder schließt. das wars... sad

Na, das ist wahrscheinlich einfach: In der .bat steht "-Xmx2G", java darf sich also 2G Speicher reservieren, den du nicht zur Verfügung hast - einfach mal in einen kleineren Wert ändern. Wenn es nicht hilft, schreibe in die .bat noch eine Zeile "pause", dann bleibt das Fenster solange offen bis du eine Taste drückst und die Fehlermeldung lesen kannst.

Vorschlag für Kamerabewegung:

Also ich finde die momentane Steuerung mit linker/rechter Maustaste schon nicht schlecht. Mich irritiert nur die Schwenkbewegung mit Pfeil rechts/links - das resultierende "schiefe" Bild ist in dieser Anwendung eigentlich unnütz. Besser wäre es, um die senkrechte Achse zu drehen.

mueschel wrote:

reneman wrote:

XP SP3 Lenovo NB 2GB Ram, 1,58GHz, Java 6 Build 31
Klick auf osm2world-windows.bat öffnet cmd, die sich sofort auch wieder schließt. das wars... sad

Na, das ist wahrscheinlich einfach: In der .bat steht "-Xmx2G", java darf sich also 2G Speicher reservieren, den du nicht zur Verfügung hast - einfach mal in einen kleineren Wert ändern. Wenn es nicht hilft, schreibe in die .bat noch eine Zeile "pause", dann bleibt das Fenster solange offen bis du eine Taste drückst und die Fehlermeldung lesen kannst.

Super, danke das funktioniert. Jetzt wird die Anwendung geladen. ABER:
Hab es mit 1G 1200M und 800M probiert, aber offenbar wird die Menüleiste nicht generiert, denn dort ist im neuen Fenster nix. Der schwarze Hintergrund mit dem weißen Text ist dafür zu sehen. Wenn man irgendwo klickt, dann wird alles weiß, dann hilft nur noch ein kill über die taskman.exe 🙁
(Es wird kein Fehler in cmd angezeigt.)

Moin!

Hab jetzt mal das Graz Modell mit den Texturen versucht - im OSM2World GUI schaut es gut aus, beim Export to obj jedoch wirds unansehnlich.
Wenn man das mit DeepExploration laden will, zeigt er keine Texturen an, nur die bäume werden schwazre flächen...
Tips?

• edit* ahh, die Texturen sind doch da, aber nur schwarz im Falle der Bäume.
  

Nur die Fenster fehlen noch...

Amiga4000

Ich habe mittlerweile einige gewünschte Features eingebaut, siehe Ursprungspost. Wer in den Genuss kommen will, muss updaten.

Zu den Abstürzen: Probleme mit der Grafik, die zwischen 0.1.9 und 0.2.0 dazu gekommen sind, hängen höchstwahrscheinlich mit der seit der neuesten Versionsnummer eingesetzten neueren Version der Bibliothek JOGL (Java OpenGL Bindings) zusammen, die auch Kendzi3D einsetzt. Zu diesem Thema wird sich aber voraussichtlich noch Peda zu Wort melden.

Amiga4000 wrote:

• edit* ahh, die Texturen sind doch da, aber nur schwarz im Falle der Bäume.
  

Nur die Fenster fehlen noch...

Darstellungsprobleme bei den Bäumen können ein Hinweis auf Probleme mit Transparenz (Alpha-Werte in den Texturen) sein.

Die Fenster werden über Multitexturing dargestellt, also mehrere Texturen übereinander. Das lässt sich meines Wissens in .obj gar nicht so abbilden - ein vergleichbares Problem wurde auch hier berichtet: #30. Ich bin mir unschlüssig, was der beste Workaround dafür ist.

Moin

Ok, das Problem mit de Bäumen hab ich gelöst bekommen in DeepExploration - die texturen sehen OK, muste in DeepExploration nur die Opacity setzen für die Textur. Un klar, die Bäume mit texturen machen kaum schatten, die 3D Volumenmodelle haben bessere Schatten. Vielleicht 4 oder 8 mal pro baum, statt 2 mal für mehr Schatten?
Fenster sind durchaus ein Problem, das mit multi-texturing kann .obj ned so recht abbilden. Schade, denn fenster geben bei Gebäuden doch schon einen ziemlich guten Eindruck über die Höhe des Gebäudes.
Man müßte die 2 Texturen "baken" - zusammenkleben als eine Textur, das jedoch ist erheblich Aufwand und kostet Speicher. Oder eine Textur mit Fenster je Hauswand-material?

Amiga4000

eine Textur mit Fenster je Hauswand-material?

Mehrmals ausprobiert. Sieht schlecht aus.
Ich denke, es sit besser, wir setzen neue Standards, selbst wenn *.obj und einigen andere gängige Formate mit der Sache noch wenig anfangen können.

Auf jedem fall- besten Dank für Dein Tun!

Grüße,
Marek

Moin

Nun jaa, neue Standards hin oder her, die Frage nach Sinn und Nutzen kommt schon auf - mit einem ordentlichem Exporter kann man die erstellen Daten weiter nutzen ohne erheblichen Mehraufwand. Bleibt die Frage: One Way Dead End Street oder Mehrnutzen?
Ausserdem gibt es ausreichend viele 3D Formate - collada und vrml sind nach .obj die wichtigeren.
Aber ich bin weder coder noch experte... Ich kann leider weder einen ordentlichen Exporter schreiben noch das Texturproblem lösen. Leider.

Amiga4000

Amiga4000 wrote:

Nun jaa, neue Standards hin oder her, die Frage nach Sinn und Nutzen kommt schon auf - mit einem ordentlichem Exporter kann man die erstellen Daten weiter nutzen ohne erheblichen Mehraufwand. Bleibt die Frage: One Way Dead End Street oder Mehrnutzen?
Ausserdem gibt es ausreichend viele 3D Formate - collada und vrml sind nach .obj die wichtigeren. ...

Hallo Amiga4000

Du hast die wichtige Frage schon angedeutet.
Soll man sich nach den unzureichenden Fähigkeiten eines Austauschformates richten, wenn es doch viele weiteren gibt? Ich bin auch kein 3D-Experte, eine Forderung nach mehrlagigen Texturen scheint mir jedoch nicht besonders abgehoben.

Man soll sich meiner Meinung nach weder nach dem funktionsreichsten noch nach dem funktionsärmsten Format richten, sondern eine Auswahl von Funktionen treffen, die für einen selbst wichtig sind und die von einigen Austauschformaten unterstützt werden.
Wo das für ein Zielformat nicht passt, muss man entweder eine Umgehung entwickeln oder mit der unzureichenden Unterstützung leben. Es gibt ja andere Formate zum ausweichen.

Edbert (EvanE)

Amiga4000, könnten deine Tools denn auch andere Formate wie z.B. Collada lesen?

Für einen kurzfristigen Workaround wäre es mit überschaubarem Aufwand möglich, über die Konfigurationsdateien Wandtexturen mit eingebauten Fenstern einstellbar zu machen. (Die müssten dann allerdings auch erst mal gebastelt werden!) Gebäudefarben könnten so aber nicht berücksichtigt werden.

Genauso wie eine Firma wie ESRI in der Lage ist ein Importfilter für OSM Daten zu schreiben, wird es möglich sein, Multitexturen zu importieren. Ein Praktikat hat einen solchen Tool für meine Firma schon im Jahr 2001 geschrieben.
Im Grunde ist es eien einfache Sache: Unterstütze eine Format Multitexturen nicht, so muß ein Export Tool für Texturen geschrieben werden, mit dem die Texturen "zusammengeklebt" werden. Es ist keine unmögliche Sache.

Moin

OpenSG selber kann collada recht gut, collada hat sich auch generell zu einem guten Austauschformat zwischen den 3D Welten entwickelt.
Aber ich möchte nicht sagen: baut dieses oder jenes nur weil ICH es brauchen könnte.
Man sollte ein brauchbares Format wählen, welches man a) selber beherrscht und b) die nötigen Features kann.
Ich bin zur Zeit schon froh, das man einigermassen nach .obj exportieren kann (auch wenn nicht ganz sauber) und somit ich wenigstend etwas habe.
Ich weiß selber, das das eine Menge Arbeit ist, und den idealen Weg kenne ich nicht.

Wir haben ja auch Tools wie DeepExploration zur Verfügung, welches eine Menge 3D Formate lesen und wandeln kann. Aber bei jedem dieser Umwandlungen gehen Informationen verloren.
Deswegen wünsche ich mir (leicht blauäugig wie ein Kind zu XMas) ein Export in eine Format, welches viele Features hat. Ich werde nochmal bei den Experten nachfragen...

Amiga

holgermappt wrote:

#␣A␣fatal␣error␣has␣been␣detected␣by␣the␣Java␣Runtime␣Environment:
#
#␣␣SIGSEGV␣(0xb)␣at␣pc=0x00007f635a72fd90,␣pid=5344,␣tid=140064691083008
#
#␣JRE␣version:␣7.0_09-b30
#␣Java␣VM:␣OpenJDK␣64-Bit␣Server␣VM␣(23.2-b09␣mixed␣mode␣linux-amd64␣compressed␣oops)
#␣Problematic␣frame:
#␣C␣␣[libxcb-glx.so.0+0xed90]␣␣xcb_glx_get_string_string_length+0x0

Tordanik wrote:

Zu diesem Thema wird sich aber voraussichtlich noch Peda zu Wort melden.

Dann mach ma des doch mal 🙂 Leider erkennt man ja so nicht so viel, aber ich hätte mal darauf getippt, dass der Version-String der da geprüft werden soll 0 ist?!
Kannst du mal bitte sagen, welche Grafikkarte du hast, welchen Treiber du verwendest (möglichst genaue Version, aber vor allem binary oder OS) und dein Monitorsetup (1,2,3,.. Monitore?).

Edit: Um es einfacher auszudrücken: Meiner Meinung nach ist das ein Bug in deinem Grafikkartentreiber. Die Antworten auf meine Fragen wären dennoch interessant 🙂

Amiga4000 wrote:

Fenster sind durchaus ein Problem, das mit multi-texturing kann .obj ned so recht abbilden. Schade, denn fenster geben bei Gebäuden doch schon einen ziemlich guten Eindruck über die Höhe des Gebäudes.
Man müßte die 2 Texturen "baken" - zusammenkleben als eine Textur, das jedoch ist erheblich Aufwand und kostet Speicher. Oder eine Textur mit Fenster je Hauswand-material?

Amiga4000 wrote:

Wir haben ja auch Tools wie DeepExploration zur Verfügung, welches eine Menge 3D Formate lesen und wandeln kann. Aber bei jedem dieser Umwandlungen gehen Informationen verloren.
Deswegen wünsche ich mir (leicht blauäugig wie ein Kind zu XMas) ein Export in eine Format, welches viele Features hat. Ich werde nochmal bei den Experten nachfragen...

Ich hätte da mal noch einen anderen Vorschlag, vielleicht kannst du das ja mal klären bzw. mir sagen ob das ein gangbarer Weg für euch wäre.

Im Povray-Export hatten wir schon mal das selbe Problem und haben das dort mit einem kleinen Hack gelöst: Wir haben einfach für Flächen mit Multitextur vor die Fläche mit der Grundtextur eine zweite Fläche gesetzt (sehr geringer Abstand zur ersten) und der zweiten Fläche dann eben die Fenstertextur verpasst. Wenn das mit der Transparenz klappt, sieht man an den Nicht-Fenster-Stellen die Hausfasade durch und hat quasi Multitexturing. Da dieser Code für Povray schon vorliegt, sollte das verhältnismässig einfach auch für obj verwendbar bzw. erweiterbar sein.

Dafür gäbe es dann aber hoffentlich ne Einladung in den Dave 🙂

Moin

Es hört sich interessant an, testen kann man das ja mal - so es nicht zuviel Arbeit macht.

Als guter Test für die ganze Geschichte: meshlab (http://meshlab.sourceforge.net/ ) ist ein kostenloses Tool zum anzeigen und bearbeiten von Meshes (3D Daten). Wenn der das OBJ laden kann, können wir das auch (sozusagen).

Nur eins noch zu den Texturen: Wir müssen das exportierte OBJ derzeitig in VRML konvertieren, da geht natürlich was bei verloren. Auch muß ich bei fast jeder Textur noch Opacity setzen. Ich weiß ned, woran das liegt.
Der Export in ein .obj /.x3d/.dae/* ist ja generell für alle 3D Programme interessant, da kann man ja dann ggf. auch sein Quake mit OSM versehen^^

Und zum Thema DAVE: jeden Donnerstag (im Semester) gegen 16 Uhr ist public date - da basteln wir an neuen Dingen und alten Demos herum. Zu dem Zeitpunkt ist öffentlicher Besuch gerne gesehen - so es mehr als 5 Leute sind, ist eine Voranmeldung gerne gesehen. Je nach dem, wie wichitg der Besuch für unsere Forschung/Projekte ist, mit mehr oder weniger Prominenz vor Ort^^
Sprich: Ein Teilbereich von Graz ohne Texturen ist jederzeit anschaubar, andere Bereiche sind auch schnell importiert, wenn das jetzt mit den Texturen gut geht, dann auch mit texturen^^

Amiga4000

Peda wrote:

Kannst du mal bitte sagen, welche Grafikkarte du hast, welchen Treiber du verwendest (möglichst genaue Version, aber vor allem binary oder OS) und dein Monitorsetup (1,2,3,.. Monitore?).

Ich habe es auf zwei Rechnern getestet, immer der gleiche Fehler. Ich tippe daher auch auf ein Problem in Java oder einem Treiber. Ich kann nur keinen Bugreport machen, da ich noch nicht weiß, wer der richtige Ansprechpartner ist.

Der eine Rechner hat keine Grafikkarte, das macht der INTEL Core i5-3570K. Wie bekomme ich heraus, welcher Treiber verwendet wird? Installiert ist das Paket xf86-video-intel 2.20.3. Es gibt dann noch vaapi-intel-driver 1.0.18 und xorg-x11-driver-video-intel-legacy 2.9.1.

Der Andere Rechner ist ein Lenovo ThinkPad mit den gleichen installierten Paketen. Da steht "Cantiga Graphics Controller". Also wahrscheinlich auch in die CPU integriert.

Was meinst du mit "binary oder OS"? Jeweils ein Monitor. Ich kann es noch mal mit einem virtuellen X-Server (VNC) versuchen.

holgermappt wrote:

Ich kann es noch mal mit einem virtuellen X-Server (VNC) versuchen.

Da kommt zwar das Fenster hoch, aber es gibt dann einen Fehler:

javax.media.opengl.GLException:␣Not␣a␣GL2␣implementation

Version 0.1.9 läuft unter VNC.

Sobald man ein Material taggt wird die Farbe nicht mehr beachtet. Bug oder Feature?
Chris

chris66 wrote:

Sobald man ein Material taggt wird die Farbe nicht mehr beachtet. Bug oder Feature?

Liegt nicht am Programm, sondern am Stil. Und stimmt auch nur dann, wenn das Material im Stil nicht als "colorable" definiert wird. Das ist im Standardstil derzeit bei all denjenigen Materialien der Fall, wo ich schlicht noch keine Graustufentextur gebastelt habe.

Wer sich das Anpassen des Stils zutraut und die richtigen Knöpfe im Grafikprogramm findet, kann dabei auch mithelfen: Die Textur entfärben und mir geben. Dabei sollte die Textur so hell wie unter Erhaltung der Struktur möglich sein, weil man sonst nach dem Mischen zu weit vom angegebenen Farbwert entfernt ist. Eventuell noch den Standardfarbwert anpassen, so dass er in Kombination mit der Textur sinnvoll aussieht.

In Fällen wie brick ist es komplizierter, dort muss man die Textur wohl in zwei zerlegen - einmal mit den Ziegeln in Graustufen (colorable), darüber die Fugen (die nicht mit eingefärbt werden sollten). Das habe ich bislang noch gar nicht versucht und ist wohl auch eine deutlich größere Herausforderung im Umgang mit dem Grafikprogramm.

Nahmd,

Tordanik wrote:

Wer sich das Anpassen des Stils zutraut und die richtigen Knöpfe im Grafikprogramm findet, kann dabei auch mithelfen: Die Textur entfärben und mir geben. Dabei sollte die Textur so hell wie unter Erhaltung der Struktur möglich sein, weil man sonst nach dem Mischen zu weit vom angegebenen Farbwert entfernt ist. Eventuell noch den Standardfarbwert anpassen, so dass er in Kombination mit der Textur sinnvoll aussieht.

Das lässt sich automatisieren, natürlich nur in den durch den RGB-Farbraum gegebenen Grenzen.
Wo kann man ein paar Beispieltexturen abgreifen?

Gruß Wolf

http://wiki.openstreetmap.org/wiki/Texture_Library
Gruß,
Marek

Und speziell von OSM2World: https://github.com/tordanik/isocore

Das ist der Slippymap-Stil, das Texturpack für den Viewer ist aber nur geringfügig anders. Man sieht am Beispiel von concrete auch noch ein Beispiel, wo ich (mit meinen beschränkten Fähigkeiten in der Grafikbearbeitung 😉) von Hand entfärbt habe.

Nahmd,

Tordanik wrote:

Und speziell von OSM2World: https://github.com/tordanik/isocore

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. 😛

Das ist der Slippymap-Stil, das Texturpack für den Viewer ist aber nur geringfügig anders. Man sieht am Beispiel von concrete auch noch ein Beispiel, wo ich (mit meinen beschränkten Fähigkeiten in der Grafikbearbeitung 😉) von Hand entfärbt habe.

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. 🙁

Gruß Wolf

Netzwolf wrote:

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.

Tordanik wrote:

Wer sich das Anpassen des Stils zutraut und die richtigen Knöpfe im Grafikprogramm findet, kann dabei auch mithelfen: Die Textur entfärben und mir geben. Dabei sollte die Textur so hell wie unter Erhaltung der Struktur möglich sein, weil man sonst nach dem Mischen zu weit vom angegebenen Farbwert entfernt ist. Eventuell noch den Standardfarbwert anpassen, so dass er in Kombination mit der Textur sinnvoll aussieht.

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?

Nahmd,

Tordanik wrote:

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.

Am Beispiel Ziegelsteine und Mörtel: wie würde man vorgehen und was sollte man optimal anliefern?

Es wäre ja zu schade, wenn beim Umfärben der Ziegelsteine der Mörtel was abbekommt!

Gruß Wolf

PS: die uncolored Tiles wandern gerade auf den Server. Aber des ziagt sich.

Nahmd,

marek kleciak wrote:

http://wiki.openstreetmap.org/wiki/Texture_Library

[×] done.

Gruß Wolf

Netzwolf wrote:

[×] done.

Wow, ging ja flott. 😬

Am Beispiel Ziegelsteine und Mörtel: wie würde man vorgehen und was sollte man optimal anliefern?

Es wäre ja zu schade, wenn beim Umfärben der Ziegelsteine der Mörtel was abbekommt!

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,

Tordanik wrote:

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.

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= … n=11.47677
http://www.openstreetmap.org/?lat=53.61 … 36&zoom=14

Da sind derzeit alle Gebäude ohne Land im Wasser 😉

!i! wrote:

Es scheint derzeit noch Probleme bei Inseln zu geben:
http://maps.osm2world.org/?zoom=15&lat= … n=11.47677
http://www.openstreetmap.org/?lat=53.61 … 36&zoom=14

Da sind derzeit alle Gebäude ohne Land im Wasser 😉

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,

Tordanik wrote:

Wer sich das Anpassen des Stils zutraut und die richtigen Knöpfe im Grafikprogramm findet, kann dabei auch mithelfen: Die Textur entfärben und mir geben. Dabei sollte die Textur so hell wie unter Erhaltung der Struktur möglich sein, weil man sonst nach dem Mischen zu weit vom angegebenen Farbwert entfernt ist. Eventuell noch den Standardfarbwert anpassen, so dass er in Kombination mit der Textur sinnvoll aussieht.

In Fällen wie brick ist es komplizierter, dort muss man die Textur wohl in zwei zerlegen - einmal mit den Ziegeln in Graustufen (colorable), darüber die Fugen (die nicht mit eingefärbt werden sollten). Das habe ich bislang noch gar nicht versucht und ist wohl auch eine deutlich größere Herausforderung im Umgang mit dem Grafikprogramm.

Ein wenig untergegangen: ich hatte da etwas gebastelt.

Wird ein Tool für diesen Bearbeitungsablauf noch gebraucht?

Gruß Wolf

Netzwolf wrote:

Ein wenig untergegangen: ich hatte da etwas gebastelt.

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! 🙂

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-j … on-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.

Tordanik wrote:

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...:
http://tobias-knerr.de/temp/osm2world-j … on-bin.zip

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.

Tordanik wrote:

http://tobias-knerr.de/temp/osm2world-j … on-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.

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. 🤔 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,

Tordanik wrote:

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

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.

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

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.

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.

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

Daher sind die Fugen auf nicht frontal mit voller Intensität beleuchteten Wänden immer deutlich zu hell.

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

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...

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

Gruß Wolf

!i! wrote:

Es scheint derzeit noch Probleme bei Inseln zu geben:
http://maps.osm2world.org/?zoom=15&lat= … n=11.47677
http://www.openstreetmap.org/?lat=53.61 … 36&zoom=14

Da sind derzeit alle Gebäude ohne Land im Wasser 😉

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 :-)

Ansonsten: Super Sache, das.

Netzwolf wrote:

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

Gruß Wolf

http://forum.openstreetmap.org/viewtopi … 42#p317742

mueschel wrote:

Was mir noch nicht gefällt, ist dass viele landuses und sonstiges "drumherum". Was kann man denn tun, damit das besser wird?

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.

Tordanik wrote:

...
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), ... 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)

EvanE wrote:

Ich habe mir vor einigen Tagen OSM2World 0.1.9 herunter geladen und die Beispiel-Texturen.

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...

unknown material: ROAD_CROSSING_ZEBRA

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

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?

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.

Tordanik wrote:

EvanE wrote:

Ich habe mir vor einigen Tagen OSM2World 0.1.9 herunter geladen und die Beispiel-Texturen.

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...

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

Tordanik wrote:

EvanE wrote:

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)
...
this␣exception␣occurred␣for␣the␣following␣input:
junction␣node␣WO␣for␣(11883764␣at␣50.7080642,␣7.1352432,␣{ref=1,␣highway=motorway_junction,␣...

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

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.

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. 🙂

Edbert (EvanE)

holgermappt wrote:

Tordanik wrote:

So, ich fange mal mit den Abstürzen an...

... Das ist schon ein blöder Fehler, da hier viele Komponenten zusammenspielen und nicht so richtig klar ist, was nun genau die Ursache ist.

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.