陈飞舟
剑网3的DX11的3D引擎故事15：很多人会问，为什么3D大神参与度比较少，其实主要的原因是因为剑网3的还有很多后期功能和优化工作要做，同时西山居当时准备开2个新的端游项目，急需要将现有引擎SDK化;而且我们内部还启动了一个编辑器的改善项目(这又是另外一个故事了)，也是3D大神盯着的。
剑网3的DX11的3D引擎故事16：一开始一方面是阅读代码，同时也在考虑很多基础的设计，特别是接口部分，我们还希望能支持回放，因此想引入一个命令队列，这样的话，方便多线程，也方便将3D的行为存盘，用于回放，甚至可以方便定位BUG。因此在前期做了很多预研究性质的开发。
剑网3的DX11的3D引擎故事17：开发分成几个部分，一个是模型的相关部分，一个是地形的相关部分，一个是动作的相关部分，分开阅读引擎的代码，也在思考设计方案，也会写一些小的验证程序。
剑网3的DX11的3D引擎故事18：这个期间也分析了老的文件格式，结果发现了很多可以优化的地方，因为原来的引擎设计比较全面，各种数据都存放，但是在具体游戏中，很多数据是无用的，可以优化掉的，因此顺便帮助现在的3D引擎做了一个是动作文件的优化，一个是地形的优化，效果都不错，极大的减少了磁盘IO。
剑网3的DX11的3D引擎故事19：动作的优化还在内部引起一定的轰动，因为缩小到原来的1/10大小，这也是我们没有想到的值，因为动作文件和其他模型文件，纹理不同，是不能异步加载的，因此磁盘io很大程度影响了动作的流畅性。当时3D大神手惊呆了，眼神极其精彩，也有高兴，有人能帮助优化3D引擎到这个程度。
剑网3的DX11的3D引擎故事20：地形的压缩现在基本完成，正在等待发布，因为涉及的更新量很大，还是需要项目组根据实际情况来逐步安排，不过也减少了至少1/3的数据。
剑网3的DX11的3D引擎故事21：来一点小八卦，当西山居老大听说优化的效果怎么好后，将我和3D大神叫过去，我们当时都很开心的准备去接受表扬的，结果老大将我们训了一顿，说为什么在早期的时候没有考虑这些，导致现在优化这么好，说明当时这个的设计太烂了;3D大神当时汗都下来了，我就是傻笑，你们懂得。
剑网3的DX11的3D引擎故事22：由于DX 9c对多线程的支持很差，为了防止磁盘读和文件解析占用主线程的开销，我们设计了一个非常复杂的加载流程，特别是加了插件机制，希望支持不同的文件格式，当时设计出来后，我们也很得意，觉得自己很牛逼，居然能设计出这样的代码，但是当我们看DX11的API，傻了。
剑网3的DX11的3D引擎故事23：由于DX 11引入了一套机制完美支持多线程，我们写的很多代码等于是浪费的，只有在DX9c有价值，而且会将代码复杂度高的很高，特别是后期加功能的人会很惨，当时就陷入很纠结的状态。
剑网3的DX11的3D引擎故事24：另外一个是状态切换的问题，DX9c将每一个状态都单独设置，会导致API调用次数特别多，特别是显卡的状态切换开销是很大的，而DX11直接使用状态块来解决，一次调用切换一批状态，明显效率提升很好，我们如何封装这两种差异，特别让人纠结。
西山居技术中心
我也来爆些3D引擎的开发细节 ：DX9版本最早是单线程设计的，后来要加异步加载机制，由于架构已定很多东西改不动，最终的方案非常复杂。因此DX11版本开发早期就非常看重加载流程的设计。当时想要实现一套支持多种图形API的统一架构，我们花了很多时间来讨论各种方案，推敲细节及其影响。
我也来爆些3D引擎的开发细节2：因为对架构优雅、完美有着一种偏执的追求，花了几个月都没有找到满意的方案，项目进展几乎停滞。当我们决定放弃包袱专注DX11时，事情简单了：只需提供一个加载函数，在主线程调用就是同步加载，在其他线程调用就是异步加载。整个过程非常简单、优雅，符合我们的程序美学。
