OSG开发笔记（三十六）：osg3.4.0基于windows平台msvc2017x64编译器编译并移植Demo

前言

  本篇编译osg3.4.0的msvc2017x64版本，之前使用的都是mingw32版本。

 

OSG编译

步骤一：下载解压

  下载3.4.0版本。
  

步骤二：使用cmake配置

  

  

  

  因为是64位，可以通过后续配置cmake用x64，也可以直接选择构架：
  

  继续：
  

  要修改下安装的路径，方便提取库：
  

  默认是32位，发现后续vs更改不行，得在cmake处更改，查看“入坑一”，修改如下图：
  

  修改后需要重新configure。

步骤三：生成工程

  

  

步骤四：打开vs2017打开工程

  

  装了多个vs，可能会打开错误，如果打开不是使用vs2017就自行使用
  

步骤五：VS2017编译

  编译debug版本，先创建x64版本
  

  卡住了，等一会儿：
  

  然后编译：
  

  

  编译release版本：
  

  

  

步骤六：安装到目标位置

  安装debug版本：
  

  

  安装release版本：
  

  

  检查install的文件：
  

 

OSG原Demo迁移

  移植Demo过来，复现过去的两个bug，一个是从相机旋转中心，一个是球体透明截面
  测试都使用纯C++原始代码修改，非自建的引擎，也不是osgQt。
  

 

入坑

入坑一：模块计算机类型“x86”与目标计算机类型“x64”冲突

问题

  这是个常规问题了，关键在于已经设置了x64怎么出来还是x86_32，好几年没弄，又卡了一下。
  

原因

  这是平台解决方案是x64，但是默认没有x64，还得新增配置，又由于新增解决方案卡住了，笔者就只新增活动方案，下面没点了，正确要勾选如下图：
  

  经过测试还是不行，再往前退，在CMake配置得时候指定x64：
  

解决

  在CMake配置得时候指定x64：
  

  然后重新再来一遍即可。

入坑二：编译运行直接异常

问题

  运行直接崩，一般是dll依赖缺少，检查了不缺。
  

尝试

  使用纯Qt程序，排除掉osg的，使用纯Qt程序，也是崩溃，本身Qt装的可能有问题，继续研究
  

  新建了个新的是可以：
  

  怀疑是osg得shadow文件夹内部有问题，删掉shadow，再运行裸的只有界面的程序（去掉了osg的其他依赖）：
  可以运行：
  

  然后拷贝添加osg发现崩了，发现没有拷贝dll过去，检查脚本：
  

  有问题，以为是没复制过去覆盖32位的，复制过去也崩了，单独运行，还是0x7B错误，这是库连接错误，不理解了，后来经过dll对比，发现时间与32位一致，那么问题的原因就是晚上有点事，第二天上午才看，以为编了覆盖了64位的，实际没编译，install还是32位的，所以编译写程序还是连续时间比较好，第二天：
  

  重新编译并且install发现，时间还是没变，只好删除了build文件夹重新弄了，以为是粗心，结果不是，那么点击重新编译：
  检查了是生成了：
  

  但是install拷贝过去就是之前的时间：
  

  搞蒙了都（理论上一个build也可以更改参数然后install到不同文件夹，但是这里不管了）。

解决

  build全删掉，一刀切，从头新建build重新来一遍，确保生成了64位的并提取出来。
  

  这里还少了release库，弄完好，再测是没问题了。