Integrating the OSM data
... into my model. Again this turned out to be a little tricky. And I have to admit that I made some mistakes in the past as well.
First to mention is that you may remember me setting up my model in 1:10 scale, having the axis École militaire / Eiffel Tower / Trocadero as my Y orientation. But of course the OSM data is scaled 1:1 and adjusted south to north.
Fixing the rotation wasn't a problem - working with a background image in the past I was lucky to reconstruct the correct angle. But scaling the model with factor 10 turned out to be not really precise - I had to find out that the original model wasn't exactly 1:10 but something like 1:10.4967.
An explanation was easily found: Starting with the project I didn't have any idea of how to use the OSM data at all. In fact I started with screenshots from the OSM map which I puzzled together in Photoshop and set this up as background reference.
I can't remember how I got it scaled - maybe by measuring out some map, then convert it into meters...
Anyway - a little manual tweaking gave me a result that should be precise enough for the future. So we are in real world dimensions from now on.
Second problem was a little harder. It was based in me not being familiar to the OSM addon. So I did some horrible mistakes concerning the workflow.
The addon stores some download information with the file, mainly defining a central pivot for the landscape and all additional downloads, but I think as well informations about scale. This enables you to download data in parts, and these parts fit perfectly (because all of them using the same pivot and scale informatios).
But the moment I started to work with the data (e.g. joining several parts of the terrain to one mesh, appending it into my main Paris file) I lost this information. Means that I was unable to complete the data afterwards using the same settings.
I guess I mentioned before: I started grabbing data using the free addon version, then worked with this stuff. Started modelling the waterfront a.s.o.
Later I decided to purchase the premium version as well and of course wasn't able to reconstruct the original pivot informations (surely I was stupid enough to delete the original .blend files). Therefor the free and the premium material didn't fit together automatically but had to be combined manually.
Furthermore I recognized some minimal differences in size. I don't know why - used the addon with its default settings which should be world scale.
As said the deltas were minimal, but concerning a large area means that buildings differ by several meters at the borders of my area.
Of course I'll have to live with that.
Next step was manualley removing duplicate houses.
As said I downloaded the data in parts - several small adjoining areas. By downloading an area you'll get all the objects somehow being connected to the area. By downloading multiple adjoining areas you'll get all those buildings doubled which are part of both areas.
Doing this automatically by removing double verts indeed isn't a good solution here because this would link multiple house shapes to one cityblock mesh (removing verts at shared corners and edges). I guess I did this mistake once in the past and mentioned it before.
I wasn't really sure about how to handle the vegetation overlay data. As said before I had decided to integrate the water (river) overlays into my mesh to work with waterfronts afterwards. Therefor I used Boolean intersection and Boolean difference as mentioned earlier.
I thought about doing the same with forests and other vegetation. For some reason I preferred this solution instead of projecting/shrinkwrapping the stuff onto my surface. But working with Boolean intersection and Boolean difference here turned out to be impossible because of thousands of small areas being concerned. Boolean modifier surely wouldn't come along with this stuff; resp. it would have taken me ages to check them all.
I had some thoughts about using Knife Project instead, but got away from this as well: Opposite to Boolean modifier this would have cut my mesh (but not producing a separate one), leaving me alone with the same thousands of small areas I'd have to assign some specific material to.
So I decided to stick to the Shrinkwrap solution instead.
Placing the OSM data in my model I decided to concentrate on Arrondissements 7 and 16 for the first time - it's a mass of data anyway, and I have to respect my CPU's abilities.
Tree proxies
Meanwhile I found myself tired of switching between trees and lollipops over and over. I thought about having some kind of proxy system showing me the lollipop trees in viewport by at the same time using the real trees for rendering.
Of course there's an addon for this purpose. Formerly called Proxify, now LODify (from LOD = Level of details). Unfortunately I didn't find a version working with Blender 2.79.
Simple solution: attaching both tree and lollipop to a group, set tree's viewport visibility to "Off" and render visibility to "On"; do opposite with the lollipop. Works like a charme.
I guess it's time to do some test renders again.
Leave a comment
Attention! Comments including hyperlinks or mail adresses within the "Message" field will be automatically spammed.