简介本资源为基于Visual Studio 2019预编译的OSG 3.6.5与OSGEarth 2.10配套第三方库面向从事三维地理可视化、虚拟仿真与数字地球开发的C工程师解决自行编译第三方依赖耗时长、易出错的问题。压缩包共约2000个文件以1351个h头文件、56个lib静态库、32个cmake配置、28个inc及22个c源文件为主另含少量dll、hpp与proto文件整体约137.76MB覆盖OSG与OSGEarth编译所需的完整依赖。目录中可见大量时区与地理数据文件如Abidjan、Accra、Shanghai、Tokyo等便于直接用于地球场景与坐标时区相关功能验证。已有626人学习下载适合需要快速搭建OSG/OSGEarth开发环境、跳过繁琐依赖编译环节的中高级开发者参考使用。1. 拿到 OSG 3.6.5 预编译 3rdParty 包先搞清楚它替你省掉了哪三天的编译如果你在 Windows 上从源码编译过 OSG大概率经历过这个流程装 CMake、拉源码、配 zlib、配 libpng、配 libjpeg、配 freetype、配 GDAL、配 curl然后被某个第三方库的链接错误卡住反复改 CMake 变量一天就过去了。OSG 3.6.5 配合 OSGEarth 的场景下第三方依赖的数量还要再翻一倍——GDAL 带 PROJ、SQLite、GeoTIFFcurl 带 OpenSSL 或 schannel还有 osgEarth 自己需要的 leveldb、sqlite3、protobuf 之类。这份预编译好的 3rdParty.zip 就是把这些依赖提前用 VS2019 编译成 lib 和 dll按目录结构摆好你拿到手只需要配几个 CMake 变量就能直接编 OSG 和 OSGEarth 本体。它解决的不是“能不能编”的问题而是“编到一半发现某个库缺符号、版本对不上、Debug 和 Release 混用”这类反复消耗时间的问题。适合两类人一是第一次在 Windows 上搭 OSG OSGEarth 环境、不想在依赖上耗三天的新手二是已经会编但想换一台机器快速复现环境的老手。前提是你的编译器版本和这份包的编译版本一致通常是 VS2019 的 MSVC v142 工具集。2. 3rdParty 包的目录结构与 VS2019 工具集匹配逻辑2.1 预编译包到底装了什么拿到压缩包解压后根目录一般长这样3rdParty下面分bin、include、lib三个主目录lib里再按x64或Win32分平台每个平台下又分Debug和Release。bin里放运行时 dllinclude里是各库的头文件lib里是导入库。OSG 的 CMake 配置里有一组关键变量专门指向这些路径分别是ACTUAL_3RDPARTY_DIR、3RDPARTY_DIR以及每个依赖库单独的XXX_INCLUDE_DIR和XXX_LIBRARY。预编译包的价值在于这些路径下的文件已经按 OSG 的FindXXX.cmake模块期望的命名和位置摆好了你不需要自己去猜某个库的头文件该放哪。常见做法是解压到一个没有中文、没有空格的路径比如D:\dev\3rdParty_x64。路径里有空格或中文CMake 在拼接-I和-L参数时容易出问题这是血泪经验不是玄学。2.2 为什么必须和 VS2019 对齐MSVC 的 ABI 在 v140VS2015、v141VS2017、v142VS2019之间并不完全兼容。预编译包里的.lib是用 v142 工具集编出来的如果你用 VS2017 去链接轻则报LNK2038检测到_MSC_VER不匹配重则链接通过但运行时崩溃。所以第一步是确认你装的 VS2019 带 v142 工具集并且 CMake 生成时指定的是Visual Studio 16 2019生成器。# 确认本机 MSVC 工具集版本输出应包含 19.2x 即 v142 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat cl.exe这段命令的作用是进入 VS2019 的 64 位编译环境然后调用cl.exe查看版本号。19.29对应 VS2019 16.11属于 v142。如果你的输出是19.1x说明当前 shell 进的是 VS2017 环境需要检查vcvars64.bat的路径是否指向 2019。参数上vcvars64.bat不带额外参数就是初始化 x64 环境如果你要编 32 位换成vcvars32.bat但预编译包通常只提供 x6432 位场景要另找。2.3 Debug 与 Release 不能混链预编译包里lib\x64\Debug和lib\x64\Release是分开的。OSG 的 CMake 在 Debug 配置下会去找带d后缀的库比如zlibd.libRelease 下找不带后缀的。如果你在 Debug 配置里误指向了 Release 的库会出现LNK2038的RuntimeLibrary不匹配或者运行到一半堆损坏。我一般会在 CMake 配置阶段就把CMAKE_BUILD_TYPE或生成器的配置类型明确下来不让它默认走 Debug。提示预编译包解压后先别急着配 CMake用dumpbin /headers抽查一两个 lib 的机器类型确认是 x64 而不是 x86能省掉后面一堆链接错误。3. 用 CMake 把 3rdParty 接进 OSG 3.6.5 的完整配置流程3.1 配置 OSG 源码时的关键变量假设 OSG 源码在D:\dev\OpenSceneGraph-3.6.53rdParty 在D:\dev\3rdParty_x64构建目录用D:\dev\osg-build。打开 CMake GUI源码路径和构建路径填好点 Configure生成器选Visual Studio 16 2019平台选x64。第一次 Configure 会报一堆Could NOT find XXX这是正常的因为还没告诉它 3rdParty 在哪。# 命令行方式配置比 GUI 更适合复现 cmake -S D:/dev/OpenSceneGraph-3.6.5 -B D:/dev/osg-build ^ -G Visual Studio 16 2019 -A x64 ^ -DACTUAL_3RDPARTY_DIRD:/dev/3rdParty_x64 ^ -DBUILD_OSG_APPLICATIONSON ^ -DBUILD_OSG_EXAMPLESON ^ -DCMAKE_INSTALL_PREFIXD:/dev/osg-install这段命令里-S和-B分别指定源码和构建目录-G指定生成器-A x64指定平台。核心参数是ACTUAL_3RDPARTY_DIROSG 的 CMake 会从这个变量推导出3RDPARTY_DIR再去各子目录找头文件和库。BUILD_OSG_APPLICATIONS和BUILD_OSG_EXAMPLES打开后会多编一些示例程序方便验证环境是否可用但会拉长编译时间赶时间可以关掉。CMAKE_INSTALL_PREFIX是安装目录编完后INSTALL目标会把头文件、lib、dll 归拢到这里。Configure 完成后在 CMake 的输出里搜zlib、libpng、freetype、GDAL这几个确认它们的_INCLUDE_DIR和_LIBRARY都指向了 3rdParty 下的路径而不是NOTFOUND。如果某个库仍然NOTFOUND说明预编译包里的目录名和 OSG 的FindXXX.cmake期望的不一致需要手动补-DXXX_INCLUDE_DIR...和-DXXX_LIBRARY...。3.2 编译与安装的顺序Configure 通过后Generate 生成.sln然后用命令行编译避免 GUI 里点来点去。# Release 配置编译并安装 cmake --build D:/dev/osg-build --config Release --target INSTALL -- /m:8--config Release指定配置类型--target INSTALL表示编完直接执行安装/m:8是传给 MSBuild 的并行编译参数8 是并行项目数按你 CPU 核心数调整。这一步会花不少时间OSG 本体加上示例程序Release 下大概十几到几十分钟取决于机器。编译过程中如果报某个第三方库的链接错误先看错误里提到的库名再去 3rdParty 对应目录确认那个 lib 是否存在、是否是对应配置的版本。安装完成后D:\dev\osg-install下会有bin、include、lib。把bin加到系统PATH或者在你的项目里显式拷贝 dll。验证 OSG 是否可用跑一下osgversion.exe能输出版本号就说明本体没问题。3.3 接着配 OSGEarth 的注意事项OSGEarth 依赖 OSG所以配置 OSGEarth 之前先让 CMake 能找到你刚装好的 OSG。通常设OSG_DIR指向osg-install\lib\cmake\OpenSceneGraph或者把osg-install加进CMAKE_PREFIX_PATH。OSGEarth 自己还会用到 GDAL、curl、protobuf 等这些同样来自 3rdParty 包。cmake -S D:/dev/osgearth -B D:/dev/osgearth-build ^ -G Visual Studio 16 2019 -A x64 ^ -DOSG_DIRD:/dev/osg-install/lib/cmake/OpenSceneGraph ^ -DACTUAL_3RDPARTY_DIRD:/dev/3rdParty_x64 ^ -DCMAKE_INSTALL_PREFIXD:/dev/osgearth-install这里OSG_DIR是关键指向 OSG 安装后生成的 CMake 配置目录而不是源码目录。ACTUAL_3RDPARTY_DIR同样用于定位 GDAL 等依赖。OSGEarth 的 CMake 对 GDAL 版本比较敏感如果预编译包里的 GDAL 版本和 OSGEarth 源码期望的不一致可能在 Configure 阶段就报错这时候要么换匹配的 3rdParty 包要么在 OSGEarth 里关掉对应驱动。4. 避坑与排查预编译包最容易翻车的五个地方4.1 现象Configure 报 zlib 找不到但 3rdParty 里明明有原因通常是目录层级不对。OSG 的FindZLIB.cmake会在3RDPARTY_DIR下按include和lib去找如果你的解压多套了一层比如3rdParty_x64\3rdParty\include它就找不到。解决方法是把ACTUAL_3RDPARTY_DIR指到真正包含include和lib的那一层或者把内层目录挪出来。4.2 现象链接时报LNK2038提示RuntimeLibrary不匹配这是 Debug 配置链了 Release 库或者反过来。预编译包里 Debug 和 Release 是分开的CMake 在 Debug 下应该找xxxd.lib。检查 CMake 输出里各库的_LIBRARY变量Debug 配置下是否指向了Debug目录。如果预编译包没有提供 Debug 版本那就统一用 Release 编别在 Debug 下折腾。4.3 现象运行示例程序时弹窗缺 dll编译链接都过了一运行就说找不到zlib1.dll或gdal305.dll。原因是 dll 在 3rdParty 的bin目录里没进PATH也没拷到 exe 旁边。解决办法是把 3rdParty 的bin和 osg-install 的bin都加进PATH或者用 CMake 的install规则把依赖 dll 一起拷过去。我一般会在项目里写一个copy_deps的 POST_BUILD 步骤省得每次手动拷。4.4 现象OSGEarth 编译到某个驱动时报 GDAL 符号未定义GDAL 的 C API 和 C API 在不同版本里符号有变化预编译包的 GDAL 版本如果和 OSGEarth 源码不匹配就会在链接osgEarthGDAL之类的库时缺符号。先确认 3rdParty 里 GDAL 的版本号看gdal_version.h再对照 OSGEarth 源码的CMakeLists.txt里要求的版本范围。不匹配的话要么换 3rdParty 包要么在 OSGEarth 里把对应驱动关掉先保证核心库能编过。4.5 现象CMake 每次 Configure 都重新找库缓存不生效有时候改了ACTUAL_3RDPARTY_DIR但 CMake 还用旧路径是因为缓存里已经存了XXX_LIBRARY的值。解决方法是删掉构建目录里的CMakeCache.txt重新 Configure。或者用cmake -U XXX_*清掉相关缓存变量。这个坑不常遇到但一旦遇到会让人怀疑人生以为预编译包坏了。5. 验证环境是否真正可用跑一个最小 OSGEarth 地球5.1 用 osgearth_viewer 做冒烟测试OSGEarth 编完后会生成osgearth_viewer.exe这是最直接的验证工具。准备一个最简单的.earth文件加载一个在线或本地的影像图层看能不能渲染出地球。如果osgearth_viewer能启动并显示地球说明 OSG、GDAL、curl 这条链路都通了。!-- minimal.earth最小地球配置只加载一个本地影像 -- map nameminimal options profileglobal-geodetic/profile /options image nameworld drivergdal urlD:/data/world.tif/url /image /map这个.earth文件里profile用global-geodetic表示全球地理坐标image的driver用gdal表示通过 GDAL 读影像url指向一个本地 GeoTIFF。如果你的环境里 GDAL 没配好这一步会直接报错错误信息里会提到 GDAL 的驱动名。跑通这个再逐步加高程图层、矢量图层。5.2 检查 dll 依赖的笨办法如果osgearth_viewer启动就崩又没明显报错用dumpbin /dependents看它依赖哪些 dll逐个确认这些 dll 在PATH里能找到。常见缺失的是gdal305.dll、proj_9_0.dll、curl.dll、libcrypto-3-x64.dll。这些都在 3rdParty 的bin里把它们所在目录加进PATH就行。我习惯在开发机上把 3rdParty 的bin和 osg-install 的bin永久加进用户环境变量省得每个项目都配一遍。5.3 一个容易忽略的细节PROJ 的数据文件GDAL 依赖 PROJ 做坐标转换PROJ 需要proj.db和一堆数据文件。预编译包里如果带了share\proj目录要设PROJ_LIB环境变量指向它否则 GDAL 在打开某些带投影信息的影像时会报“找不到 proj.db”。这个坑很隐蔽因为不带投影的影像能正常打开一带投影就失败。设好PROJ_LIB之后最好用gdalinfo验证一下。从那以后我每次拿到新的预编译 3rdParty 包都强制走一遍“dumpbin 查架构 → 配 CMake → 编 OSG → 编 OSGEarth → 跑 osgearth_viewer”这个流程不跳过任何一步。希望帮到你。本文还有配套的精品资源点击获取