Blosm for Blender: what the free build gives you and what Pro adds

One Blender addon sold as a free build and Pro

Blosm pulls real places into Blender instead of leaving an artist to model a city block by hand. It downloads buildings from OpenStreetMap, Google 3D cities and real world terrain data, then assembles them into the scene. The project was formerly known as Blender-OSM, and that older name still appears in every link the page hands out, a small trap for anyone hunting for support or filing a bug. Two builds ship under one name: a base version that can be downloaded for free, and a Pro version sold separately, with the author's own note that paying is optional and simply funds development. Support runs through a support e-mail address, a facebook page, a twitter account, a blenderartists.org thread and the repository's own issues page. The addon source code is published, and buyers of the paid build receive that same source as part of the purchase.

No install command exists, only two gumroad links

A first run begins at a purchase page, not at a shell prompt. The README gives no installation command, no configuration file keys, no environment variables and no command line flags, which fits an addon that Blender loads rather than a program you invoke. What the page does supply is one gumroad URL per build, plus two wiki pages: one titled Premium-Version for the paid build, one titled Documentation for the base version. On compatibility, the only release on record is v2.4.21 for Blender 2.79, dated 2021-01-02, while the last push to this repository landed on 2026-09-08. That distance between the recorded version and the recent commits is the number to check before buying, because the page names no minimum Blender version and lists no files, so both facts have to be confirmed by hand.

Buildings are rebuilt from height and floor count

Buildings arrive with no texture in the base build, and their geometry comes from tags rather than from any surveyed model. Height and number of floors are what shape the result. A building with a complex structure is composed into several 3D parts instead of one shell, and a large number of roof shapes is supported. Where a terrain object exists, buildings are placed on it automatically, so errors in the height data get absorbed into placement rather than leaving slabs hovering over a hillside. What you end up looking at is massing geometry: volumes derived from tags, with no surface detail at all. That serves a wide shot, a massing study or a background plate well. It does not serve a plan where the facade needs a texture map or the window grid has to be modelled by hand.

Roads, paths and railways keep width as Blender curves

Linear features get their own representation, and it is not meshes. Imported roads, paths and railways have width, and they are represented by Blender curves with a profile object. A curve carrying a profile can be re-proportioned after import and can follow a height change, which is the practical difference from a mesh road you would have to rebuild to change its width. Projection stays conditional, exactly as with buildings: if a terrain is provided, roads are projected on it. Without terrain, the network arrives without elevation context and has to sit on whatever ground the scene already holds. The page does not document which curve types get used, nor whether the profile object is a circle, a rectangle or a custom shape, so the cross section has to be read off in the viewport after the first import.

Terrain at about 30 meter resolution anchors everything

The terrain importer is why the rest of the addon keeps talking about terrain. It downloads real world elevation data at a resolution of about 30 meter, and that word about is the page's own hedge rather than a survey standard anyone can plan against. Two things hang off it. GPX tracks can be imported and projected on the terrain, so a recorded route becomes a curve following real ground. And every conditional statement elsewhere, buildings placed automatically, roads projected, water and vegetation draped, depends on that terrain object existing first. The order of import is not documented anywhere on the page, even though each projection step is described as automatic rather than as something you adjust afterwards.

Rivers, lakes and vegetation stay flat polygons

Water and green areas come in as polygons, not as volumes. A river has no depth in this pipeline and a forest has no canopy height; what arrives is an outline. The saving move is the familiar one: if a terrain is provided, these polygons are projected on it, so a lake stops hovering above a valley and reads as a surface cut into ground. Without terrain they stay flat, and aligning them is left to you. This is the clearest split in the project. The base build hands you cheap, editable outlines, and the Pro list is where forests and single trees come back as 3D objects, something the base feature list never claims to do.

Pro adds texture baking, lit windows and tree objects

The Pro list is where the visual layer lives. It adds one-click baking of multiple textures into a single texture for 3D Tiles, import of buildings from OpenStreetMap with default materials, tileable building textures and UV-mapping applied, and default materials and textures to mimic lit windows for a late evening setting. It also imports forests and single trees as 3D objects, accepts custom tileable building textures such as sets from textures.com, and projects satellite imagery and web maps onto a terrain. Read against the base list, the difference is not that Pro pulls more data. It pulls the same buildings and the same elevation, then changes what happens to the surfaces afterwards. Baking several textures into one for 3D Tiles is the item that points at a streaming pipeline. By contrast, nothing in the base list explains how Google 3D cities, named in the project title, are fetched, which is the largest gap a buyer has to close elsewhere.

The default branch holds no code and only README.md

Here is the detail a skim misses. The project description says the source code is in the branch `release`, while the default branch is named `info`, and the only top level entry listed is `README.md`. Clone the default branch expecting source and you get a readme and nothing else. The rename adds a second layer: the repository is called vvoovv/blosm, but the wiki, the wiki images, the issues tracker and the forum thread all point at vvoovv/blender-osm. None of that stops the addon from loading. It does mean the documentation you follow lives under a different name than the project you found, and that both names have to be kept straight when you file a bug or check whether a fix landed. Switch to the code branch before you file anything.

Editorial conclusion

Adopt Blosm when you need real massing, real roads and real elevation inside Blender and can accept untextured geometry from the free build. Walk away if your scene needs surface detail or scanned assets, since that arrives only with the paid Pro build. Before paying anything, read the wiki Documentation page, confirm the addon still loads in your Blender version, and check which branch actually holds the code. Bring the terrain in before the buildings and roads, since every projection step is written as conditional on that object existing first.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vvoovv/blosm on GitHub