转自原文http://www.cnblogs.com/lookof/archive/2010/03/06/1679633.html 这个问题我也遇到过，确定DX版本和VC版本对应就OK
   
    Ogre3D官方于上个月末放出了1.7的稳定版本。据称该版本与旧版1.6x比起来，改动幅度较大。因此作为一名Ogre使用用户，“与时俱进”既是我的责任，又是变被动为主动的上乘战略。于是，学习新的Ogre系统成为我计划中的一部分。

    与以往不同，新Ogre的编译策略完全采用了CMake安装方式。为此，你首先要下载CMake工具才能安装Ogre。不过，官方在wiki中对如何安装新Ogre进行了详尽的说明，包括在哪里下载CMake以及如何使用它，都有step-by-step的指导。因此只要按照说明来，你“应该”可以顺利地看到通过CMake释放出的Ogre.sln。

    之所以说“应该”，是因为种种原因，还是有相当大的几率会遇到“挫折”。遇挫的可能性取决于与新Ogre有关联的周边配置。拿本人案例来说，就是要看你的DX SDK版本以及VC版本是否一致了。

    具体我的悲惨编译经历如下：

    . 在公司机子上下载Ogre1.7并按指导进行安装，选择VC2003编译器编译，一切顺利，没有见到任何阻碍。很快就看到了Ogre.sln；编译Ogre.sln，全部顺利生成成功。心想新Ogre的用户体验不错嘛，没想到这么顺。注意，此机子的DX9 SDK版本是2009（March）的。

    . 回家后重新下载Ogre1.7并安装，打算给本本也升级至新版。本本的DX9 SDK版本还停留在05年的古董级。就这样，开始，同样的步骤（依然选择了VC2003编译器）——然后，所以但是卡壳了。CMake在处理RenderSystem_Direct3D9时出现问题，具体出错信息想不起来了，抱歉。但稍稍分析一下即知，是找不到DxErr.h这个文件。经过google知道这是一个DX9 SDK新版本里的文件。于是，卸载旧的版本，选择最新的DX9 SDK （2010 February版本，新鲜出炉的呀）安装。

    . 接着重新一开始的步骤——然后，终于见到Ogre.sln了，很好很强大。然后继续Ogre.sln的编译。经过近一个小时的编译——全部生成——除了一个RenderSystem_Direct3D9的工程！我艹，又是它。分析得知，DxErr.h虽然有，但它里面用到的__in却是一个无法识别的符号。继续google，得知__in是存在于VC2005中的一个系统变量。换句话说，如果要使用DX9 SDK(2010 Feb)版，就要用VC2005来编译工程了。

    . 重新卸载了DX9 SDK(2010 Feb)版，下载了DX9 SDK(2009  March)版来装。然后，再次开始编译旅程——终于全部搞定！

    从这里可以看到这个编译过程实际上对 Ogre – DX9 – VC 这条链上的版本有相对严格的要求。Ogre – DX9的环节可能会出错，同样DX9 - VC的环节也可能会出错。

    Done~


ps:  顺便一提，在参观Ogre1.7的地形Sample时，点击Start后会发现程序陷入“死掉”状态，突然就那么不反应了。开始我以为又是什么bug所致，追踪源码后发现，原来是初次运行时Ogre要计算一张1024*1024的光照贴图（见OgreTeerain.CalcLightmap.for.for），此时用时较长，并没有真正死掉，只要耐心等一段时间，就会顺利打开这个Smaple，而且这张lightmap是生成一次，终生受用的。以后只要还是相同的地形，再次打开时直接载入，不必再等那么长的时间了。

      另外，发现Ogre还没有提供对1.7系统的学习指导wiki，我想只有靠自己去摸索了。最好的方法应该就是认真参观各Sample大神了吧。