简介：这是一份面向3D建模与地理信息交叉领域开发者的Blender开源插件资源，专为在Blender中高效导入、处理和可视化真实地理数据（如OSM、LiDAR、地形影像、地理配准相机）而设计，解决传统3D软件缺乏原生GIS支持的痛点，适用于城市建模、数字孪生、VR地理场景构建等实践场景。压缩包共131个文件，主体为78个Python脚本（实现数据解析、坐标转换、图层渲染等核心功能），辅以32个SVG图标（UI界面资源）、13张PNG示例图（含lidar.png、terrain.png、georefCam.png等典型地理可视化效果），以及README、LICENSE、JSON配置等工程必需文件，整体仅402KB，轻量易集成。已有6855人学习下载，资源结构规范，包含完整插件模块、清晰文档说明与开箱即用的UI组件（ui.py）和版本管理（version），开发者可直接部署调试，快速掌握Blender与GIS数据协同建模的关键流程与代码范式。
1. BlenderGIS 是什么：一个把真实地理数据“搬进”3D建模软件的轻量级桥梁，不是插件市场里那种点几下就出地形的玩具
你有没有试过在 Blender 里拉个平面、加个噪波纹理、再手动调高度——结果发现山脊线歪得离谱、河流走向和卫星图对不上、城市建筑群的位置偏移两公里？这不是你的建模技术问题，是数据源头没对齐。BlenderGIS.zip 这个包，本质是一套地理空间坐标系到 Blender 本地坐标系的精确映射工具集，它不渲染地图，不替代 GIS 软件，也不生成 LOD 模型；它只干一件事：把 OpenStreetMap 的 .osm、SRTM 的 .hgt、GeoTIFF 高程、Shapefile 建筑轮廓这些带真实经纬度坐标的原始数据，无损转换成 Blender 能直接用的网格、曲线、空对象，且保留 WGS84 或 UTM 坐标参考。它适合两类人：一类是做城市数字孪生前期验证的设计师，需要快速把某街区的真实路网+地形导入 Blender 做光照/人流模拟；另一类是地理信息专业学生，想绕过 ArcGIS/QGIS 复杂导出流程，在 Blender 里做三维空间分析可视化。它不是“Blender 地理插件”，它是“地理数据到 Blender 的翻译器”——翻译错了，模型就漂移；翻译准了，连 0.5 米精度的 LiDAR 点云都能对得上街角消防栓位置。压缩包里没有安装程序，没有 GUI 向导，只有 Python 脚本、配置模板和一份写满坐标的 README.md。你得亲手告诉它：“这个 .tif 是 WGS84 UTM zone 50N，原点要锚定在东经 121.47°、北纬 31.23°”，它才肯动。
2. 用 BlenderGIS 在本地跑通最小地形导入：从下载 SRTM 到 Blender 里看见可编辑的网格
2.1 下载并准备真实高程数据：别用随机生成的噪声，要 SRTM v3 或 NASADEM
BlenderGIS 不自带数据源，它只负责解析。最常用、免费、覆盖全球的高程源是 NASA 的 SRTM v3（1弧秒，约30米分辨率）或更新的 NASADEM（同分辨率但修正了云遮挡）。注意：不要下载 GeoTIFF 格式的“伪彩色渲染图”（那是给眼睛看的 PNG/JPG），必须是GeoTIFF 格式的单波段高程值文件（单位：米），后缀为.tif，且内嵌地理坐标系（GDAL 可读取gdalinfo xxx.tif验证）。国内用户常踩的坑是误下 USGS Earth Explorer 上的 “SRTMGL1” 产品——它虽是 GeoTIFF，但默认使用 WGS84 地理坐标系（经纬度），而 BlenderGIS 默认期望投影坐标系（如 UTM）。解决方法有两个：一是用 GDAL 重投影（见 2.2），二是直接改 BlenderGIS 配置（见 2.3）。我一般会优先选后者，因为重投影会引入插值误差，对精度要求高的项目不友好。
提示：SRTM 数据下载推荐 OpenTopography ，输入经纬度范围后选择 “SRTM GL1” 并勾选 “Geotiff (Projected)” —— 它会自动为你生成 UTM 投影的 GeoTIFF，省去重投影步骤。
2.2 （可选）用 GDAL 重投影：当拿到的是 WGS84 经纬度 GeoTIFF 时
如果你已下载了纯 WGS84 的.tif（gdalinfo输出中Coordinate System is:后跟GEOGCS["WGS 84"），需先转为 UTM。假设你要处理上海区域（东经 121.47°，属 UTM zone 51N），执行：
gdalwarp -t_srs "EPSG:32651" -r bilinear -of GTiff input_wgs84.tif output_utm51n.tif-t_srs "EPSG:32651"：目标坐标系为 WGS84 / UTM zone 51N（北半球）-r bilinear：重采样用双线性，比最近邻更平滑，适合高程-of GTiff：输出格式保持 GeoTIFF
执行后用gdalinfo output_utm51n.tif确认Coordinate System is:已变为PROJCS["WGS 84 / UTM zone 51N"。这一步耗时取决于文件大小，1°×1° 的 SRTM 约 20 秒。
2.3 配置 BlenderGIS 导入脚本：关键在import_dem.py的三处硬编码参数
解压3D-BlenderGIS.zip，进入scripts/目录，打开import_dem.py。它不是即插即用的插件，而是需按项目修改的 Python 脚本。核心修改点有三处（行号可能因版本浮动，请搜索关键词）：
# === 修改点 1：指定输入文件路径（绝对路径更稳）=== dem_path = "/home/user/data/shanghai_utm51n.tif" # ← 改成你自己的 .tif 路径 # === 修改点 2：设置地理原点（Blender 世界原点将对应此处经纬度）=== origin_lat = 31.23 # ← 上海中心纬度（度） origin_lon = 121.47 # ← 上海中心经度（度） # === 修改点 3：设置 UTM zone（若用 WGS84 经纬度数据，则 zone=0；若用 UTM 投影数据，填实际 zone）=== utm_zone = 51 # ← 对应 EPSG:32651；若用 WGS84 数据，设为 0为什么utm_zone=0能支持 WGS84？因为 BlenderGIS 内部逻辑是：若utm_zone == 0，则跳过 UTM 投影计算，直接用origin_lat/lon作为地理原点，再将 GeoTIFF 的像素坐标（x, y）通过墨卡托近似公式转为局部米制坐标。这是精度与便利性的折中——对小于 10km² 的区域，误差 < 1 米；超过则必须用 UTM 投影。
2.4 在 Blender 中运行脚本：不是“安装插件”，是“执行文本块”
启动 Blender（建议 3.6 LTS 或 4.0+，兼容性最好），切换到Scripting工作区。点击左上角New新建文本块，将修改好的import_dem.py全文粘贴进去。确保右上角Text下拉菜单中选中该文本块，然后点击右下角Run Script。你会看到 Blender 视口中央生成一个名为DEM_Mesh的网格对象——它就是地形。此时：
- Z 轴方向是真实海拔（单位：米），1 个 Blender 单位 = 1 米；
- X/Y 坐标是相对于
origin_lat/lon的局部平面坐标（单位：米）； - 网格顶点数 = GeoTIFF 像素数，可直接进入Edit Mode编辑、加细分、贴材质。
注意：首次运行若报错
ModuleNotFoundError: No module named 'osgeo'，说明 GDAL Python 绑定未安装。在系统终端执行pip install GDAL==3.4.3（版本需与gdalinfo --version一致），然后重启 Blender。
3. 导入 OpenStreetMap 路网与建筑：用 .osm 文件生成可编辑的 Blender 曲线与实体
3.1 从 OpenStreetMap 提取干净 .osm：避开 Overpass Turbo 的“全要素”陷阱
BlenderGIS 支持直接读取.osm文件，但不是所有 .osm 都能用。常见错误是用 Overpass Turbo 导出“所有节点+方式+关系”的完整快照（.osm文件含<node><way><relation>），这种文件 BlenderGIS 解析极慢，且会把路灯、长椅等无关 POI 也转成物体。正确做法是按需过滤。例如，只提取上海外滩区域的主干道与建筑轮廓：
// Overpass QL 查询语句（复制进 https://overpass-turbo.eu/ 运行） [out:xml][timeout:25]; ( way["highway"~"motorway|trunk|primary|secondary"]({{bbox}}); way["building"="yes"]({{bbox}}); ); out body; >; out skel qt;{ { bbox } }会被 Overpass Turbo 自动替换为当前视图范围；out body; >; out skel qt;表示导出方式（ways）及其组成节点（nodes），不导出关系（relations），大幅减小文件体积；- 导出格式选XML (.osm)，保存为
waitan_roads_buildings.osm。
提示：避免使用
area或rel关键字，它们会触发复杂拓扑解析，BlenderGIS 当前版本不支持。
3.2 配置import_osm.py：控制图层、缩放与几何类型
scripts/import_osm.py是 OSM 导入核心。关键参数在脚本开头：
# === 输入路径 === osm_path = "/home/user/data/waitan_roads_buildings.osm" # === 地理原点（必须与 import_dem.py 中的 origin_lat/lon 完全一致！）=== origin_lat = 31.23 origin_lon = 121.47 utm_zone = 51 # 必须与 DEM 一致，否则路网和地形错位 # === 图层控制：哪些 OSM tag 被转换？=== layers = { "highway": {"type": "curve", "width": 8.0}, # 道路 → 曲线，宽 8 米 "building": {"type": "mesh", "height": 24.0} # 建筑 → 实体，高 24 米（可后续修改） } # === 坐标缩放因子（微调精度）=== scale_factor = 1.0 # 1.0 = 1 Blender unit = 1 meter；若想放大 10 倍做细节，设为 10.0layers字典定义了 OSM tag 到 Blender 几何类型的映射。"type": "curve"生成 Bezier 曲线（适合道路中心线），"type": "mesh"生成闭合面片（适合建筑底面）；height参数仅对"type": "mesh"生效，它为建筑底面 extrude 拉伸高度，不是真实楼高（OSM 的building:levelstag BlenderGIS 不解析）；scale_factor是玄学参数：当导入后物体小到看不见，或大到撑满视图，优先调它而非改origin。
3.3 运行并清理：为什么生成的建筑是“空心盒子”？如何补面？
运行import_osm.py后，你会看到大量命名为building_001,building_002的物体。它们确实是“空心盒子”——因为 BlenderGIS 只生成建筑底面多边形（由 OSM 的way闭合环构成），然后沿 Z 轴 extrude，但不自动封顶/封底。这是设计使然：封底会增加面数且常被地形遮挡；封顶需识别屋顶形状（flat/gabled/hipped），而 OSM 数据极少标注。所以标准流程是：
- 全选所有
building_*物体（Shift + A→Select All by Type→Mesh）； Tab进入编辑模式，A全选顶点；Alt + E→Extrude Faces Along Normals，输入24（与脚本中height一致）；A全选，M→Merge by Distance（合并重复顶点，防后续布尔失败）；P→Separate by Loose Parts（分离每个建筑为独立物体，方便单独赋材质）。
注意：若 extrude 后出现破面（faces with zero area），说明原始 OSM way 有自相交或退化边。用
Mesh > Clean Up > Delete Loose清理，或回 Overpass Turbo 加is_closed=yes过滤条件。
4. 常见问题排查：5 条血泪经验，每条都来自真实翻车现场
4.1 现象：地形网格完全平坦，Z 值全是 0
原因：GeoTIFF 高程值被存储为Int16类型，但 BlenderGIS 默认按Float32解析，导致高位截断。gdalinfo查看Data type若为Int16，则需修改import_dem.py中raster.GetRasterBand(1).ReadAsArray()后的类型转换。
解决：在import_dem.py中找到elevation_data = ...行，在其后添加：
if elevation_data.dtype == np.int16: elevation_data = elevation_data.astype(np.float32) # 强制转浮点4.2 现象：OSM 道路曲线严重扭曲，像被拉长的意大利面
原因：origin_lat/lon与.osm文件实际地理范围偏差过大，导致墨卡托投影畸变放大。例如用北京原点导入上海 OSM，纬度差 10°，横向拉伸超 15%。
解决：用 QGIS 打开.osm，查看图层属性中的Extent（经纬度范围），取中心点作为新origin_lat/lon；或直接用import_osm.py中的bbox参数硬编码范围（需改脚本）。
4.3 现象：导入后物体位于视图外，Shift + C回原点也找不到
原因：BlenderGIS 生成的物体坐标基于地理原点，但若origin_lat/lon设为0,0（赤道本初子午线），而你的数据在上海，那物体实际在(1350000, 3450000)米处（UTM 坐标），远超默认视图范围。
解决：在 Blender 中按N打开侧边栏，切换到View标签页，勾选Lock Camera to View，然后按Home键让视图适配所有物体；或在Outliner中右键物体 →Select，再按.（句点键）聚焦到选中物体。
4.4 现象：建筑 mesh 有孔洞，布尔运算时报错 “No faces selected”
原因：OSM way 的节点顺序非顺时针/逆时针闭合，导致 Blender 生成的面法向混乱，Mesh > Normals > Recalculate Outside也无法修复。
解决：在编辑模式下，选中所有面（A），Ctrl + N→Recalculate Normals；若仍无效，用Mesh > Clean Up > Fill Holes填补小孔，再用Mesh > Clean Up > Delete Loose清理孤立顶点。
4.5 现象：脚本运行无报错，但视图里什么都没生成
原因：BlenderGIS 默认将新物体加入当前 collection（集合），但若当前 collection 被隐藏（眼睛图标关闭）或禁用渲染（相机图标关闭），物体就不可见。
解决：检查Outliner面板顶部的过滤器，确保Visibility（眼睛）和Renderability（相机）图标均为开启状态；或新建一个 collection，拖拽所有新物体进去，再检查该 collection 的可见性。
5. 把真实地理精度锁死：用 CRS 校验、坐标偏移补偿与多源数据对齐技巧
5.1 用 GDAL 和 PROJ 命令行校验 CRS：别信文件名，要看元数据
很多.tif文件名写着 “UTM51N”，但gdalinfo一查却是 WGS84。真正可靠的校验方式是命令行直读 CRS 参数：
# 读取 GeoTIFF 的 CRS 定义（WKT 格式） gdalinfo -proj4 your_file.tif | head -n 5 # 输出类似：+proj=utm +zone=51 +north +datum=WGS84 +units=m +no_defs # 若看到 +proj=longlat，则是经纬度坐标系更进一步，用proj工具验证坐标转换是否准确：
# 将上海外滩经纬度（121.492°E, 31.235°N）转为 UTM51N 坐标（米） echo "121.492 31.235" | cs2cs +init=epsg:4326 +to +init=epsg:32651 -f "%.3f" # 输出：372456.789 3456789.012 ← 这就是 Blender 中该点的 (X, Y) 值把这个结果记下来，在 Blender 里添加一个空对象（Shift + A→Empty→Plain Axes），在Object Properties→Location中手动输入X=372456.789,Y=3456789.012,Z=4.2（外滩平均海拔），它就应精准落在你导入的地形网格上。这是精度的“后悔药”——只要有一个已知坐标的地面控制点（GCP），就能反推所有偏移。
5.2 补偿已知坐标偏移：当 GPS 实测点与 OSM 有 5 米偏差时
现实很骨感：OSM 路网常有 3–10 米偏移（尤其老城区），而你的无人机航拍图或 RTK-GPS 实测点是真值。BlenderGIS 不提供“偏移校正”UI，但可在脚本中硬编码补偿：
# 在 import_osm.py 的坐标转换函数中（搜索 def latlon_to_local） def latlon_to_local(lat, lon): # 原始转换... x, y = transform(lat, lon) # 返回 UTM 米制坐标 # ← 插入补偿：已知 OSM 整体向东偏 4.2 米，向北偏 -1.8 米 x += 4.2 # 补偿东向偏移（+X） y += -1.8 # 补偿北向偏移（+Y） return x, y这个+=就是你的“地理橡皮擦”。补偿值从哪来？用 QGIS 加载 OSM 和你的实测点 Shapefile，用Vector > Geometry Tools > Snap Geometries to Layer，记录平均偏移向量。记住：补偿只加一次，且必须在transform()之后、返回之前。
5.3 多源数据对齐终极技巧：用 Blender 的 Collection Instance 做“地理锚点”
当你同时导入 DEM、OSM 建筑、LiDAR 点云、CAD 底图时，靠改脚本参数对齐效率低且易错。我的习惯是：只用一个 collection 作为地理原点容器，其余数据都以 instance 方式链接进来。
- 创建新 collection，命名为
GeoAnchor_121.47_31.23； - 在该 collection 中添加一个空对象，命名为
Origin_GCP，Location 设为(0,0,0)； - 将
import_dem.py生成的DEM_Mesh移入此 collection，并清空其 Location（Alt + G）； - 将
import_osm.py生成的所有building_*、highway_*也移入此 collection； - 此时整个 collection 的世界坐标就是
(0,0,0)对应121.47°E, 31.23°N； - 后续导入其他数据（如 CAD 导出的
.fbx），先将其整体移动到(0,0,0)，再拖入GeoAnchor_...collection —— 它们就自动对齐了。
这招的妙处在于：你永远只调一个 collection 的位置，而不是几十个物体的坐标；导出 FBX 给 Unity 时，只需导出
GeoAnchor_...collection，地理关系全保留。
我做过最狠的一次是对齐 7 类数据源（SRTM、OSM、1:500 地形图、激光雷达、BIM 模型、监控点位、人流热力栅格），靠这套GeoAnchor机制，3 小时内完成全部空间对齐，误差控制在 0.3 米内。后来我把GeoAnchorcollection 打包成.blend文件，每次新项目直接Append进来，改个名字就能复用。地理数据的确定性，从来不是靠软件有多智能，而是靠你有没有把“原点”钉死在一个不会漂移的地方。
希望帮到你。
本文还有配套的精品资源，点击获取
 / avg() 方法：三种平均值计算方式与源码级原理解析)
