Here are additional details for addon developers about the support of custom map projections.
Custom map projections are supported via the bpyproj library. It was designed as a general library which can be used by any Blender addon dealing with geographical data. It is distributed as a separated Blender addon and can be easily accessed by any Blender addon.
If you would like to use bpyproj with your addon please refer to the dedicated wiki page.
Is there some switch to automatically uv unwrap building walls? If I have a 4 sq mile city section and try to use Smart UV Unwrap, it goes for at least an hour (I cut it short). If I do it on smaller sections, the orientation of the uvs are unreliable. Ordinary unwrap is fast enough, but it doesn’t split any edges, producing a ring of distorted walls per building. Roofs are easy because they all point upward, but I’m not sure how to easily unwrap walls to apply simple textures to them.
By default, in the osm data file I’m using seems like only one roof (a curved one) gets usable uv coordinates. Every other wall vertex seems to map to 0. I see mention of auto-uvs above, is that fully implemented? (I’m using 2.3.3)
Here is the detailed status of the premium version.
The code, materials and default textures are ready. It is the documentation that is missing.
The delay is due to the World Cup. I visited 10 games of the World Cup in 8 cities. But now it is nearly over and I am back to work.
I do hope to release the premium version this month.
The initial release of the premium version will include the following features:
Assignment of UV-coordinates and default materials with diffuse tileable building textures
Default materials and textures to mimic lit windows for a late evening setting
Options to use custom tileable building textures (e.g. from textures.com)
Satellite imagery and web maps projected on a terrain
Subsequent releases will include import of forests, more details and variability for building and other features depending on user feedback.
I prefer not to announce the price before the actual release of the premium version. Believe me the price will be affordable. A discount for the users of the base version will be provided.
I posted some previews before: (1), (2).
The texture were borrowed from textures.com. The premium version will also contain some default tileable building textures under CC0 license (public domain).
As I wrote before, it was the documentation that was missing. The documentation for the key features is to the large extent ready. However, I’d like to document how to use external textures (e.g. from textures.com).
I’m attending the global OpenStreetMap conference to understand the trends in OpenStreetMap and to make useful contacts. I’m also using the opportunity to make photos of windows, doors and shop-windows to use them in the subsequent releases of the addon premium version. That’s the cause of the current delay. I’ll be back to work on Monday.
I think the week 13-17 August, 2018 is a realistic time for the release.
The airport runway is too hilly
It’s due to imperfections of the terrain data.
You’d better to keep the terrain field blank when importing the satellite imagery. Then the satellite imagery will be projected on the flat mesh created by the addon.
A quick render of Paris in the late evening. The default roof shape was set to gabled. Used the setup script neoclassical.py. Get blender-osm (premium) at https://gumroad.com/l/blosm
Get the new version of blender-osm (both premium and base) via the link in your purchase confirmation e-mail! The imported scene looks more realistically now thanks to the randomized level height and default number of levels. The default number of levels can be tweaked in the addon GUI.
Hi, guys. I’m quite new to Blender. I just purchased OpenStreetMap Premium version, but apparently it doesn’t work on well for some reasons. So I followed the github installation workflow, but when I was trying to import the selected area, it showed me these errors. Can someone please help me out? Thanks in advance!!!
I’m sure the developers can give a better answer, but without having studied the code closely, I presume the variable uVecLength should never assume the value zero. I can suggest a workaround, which is just a hack, not a real solution, but at least it’ll get rid of this particular error, even though the rest of the code isn’t guaranteed to work. Line 66 in flat.py says
uVecLength = uVec.length
Leave that line as it is, but insert the following two lines after it:
if uVecLength==0:
uVecLength=0.000001
Make sure to keep the intendation as above. This way, the value uVecLength will never be zero, so you won’t get a divide-by-zero error.
(Incidentally the same code is copied a few lines below in another section, so if the same error occurs there, just rinse and repeat.)
But again, this is a hack and a workaround for something that appears to be a bug in the code. This solution is neither good nor should it be permanent.