I’m working with OSM2World during my graduation project. Long story short: I’m using OSM2World in combination with OSM2XODR to create maps to use in driving simulators.
I do this by using OSM2World through a CLI to export an .obj model. However I have noticed the exported model looks quite different in terms of textures/materials compared to what it looks like in the GUI version of OSM2World.
I’ve made screenshots of both the visuals in the GUI version, and the .obj exported through the CLI (imported into Blender):
How can I get the visual quality from the GUI version into the .obj export? Especially the visuals of the roads and trees.
As far as I’m aware, both of these version use the default config.
That your obj output is using the geometry-based tree models instead of texture-based tree models suggests that the default style is not being applied (as opposed to the textures getting lost at some later stage). With the latest version of OSM2World, the default style should be loaded automatically, but you can try if explicitly passing it to the command line with the --config argument makes a difference.
If that doesn’t help, feel free to share the command line call you’re using to produce the obj.
(As an aside: If your tooling supports gltf or glb files, that format can offer higher-quality visuals than obj and is therefore usually the preferred export format for OSM2World scenes. But of course that won’t help if the output is unstyled in the first place.)
Buuut as you can see, it is not quite right yet.
I am also getting quite a lot of errors in the CLI, but it does generate the model.
Errors are a collection of:
“polygon must not be self-intersecting”,
“Degenerate triangle”,
and just “Null” with the stacktrace ending with:
ERROR: null
Caused by: java.util.NoSuchElementException
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:970)
at org.osm2world.math.shapes.PolygonShapeXZ.getPointInside(PolygonShapeXZ.java:152)
...
Also a fair few warnings saying “cannot construct top boundary of wall”
Those errors and warnings in the CLI are most likely “normal” (i.e. they only mean that there are minor flaws on some individual elements in the scene). That hole in the ground is likely the result of one such error.
The output does definitely represent progress: OSM2World is clearly using textures from the style when generating models. Now the textures seem to get lost at a later point in the pipeline. The most likely cause is that the paths to the textures inside the .mtl file aren’t resolved correctly. Unlike glb, an obj model cannot be a single file including everything, but consists of separate files for textures etc. So the texture files need to be present in the correct location. I recommend opening the .mtl file with a text editor, looking at the texture paths (which may be relative to the location of the .obj and .mtl files) and making sure the textures are located where they are expected.
In that case, please check that you’ve set Blender to display materials with textures by selecting “Material Preview” mode instead of the default “solid mode”:
