[SQUARE ENIX 开放会议 2012]
揭晓「Agni's Philosophy」幕后的"技术编"
原文：game.watch 佐藤カフジ
翻译 : Trace译者注：因为i时间有限，翻译和一些语言的组织上的小问题还请见谅
SQUARE ENIX 公司，在11月23日，24日两天召开了名为 [SQUARE ENIX 开放会议 2012]的技术展示的私人会议。已经传播得很广，本会议的日程安排是今年6月E3 2012披露的技术DEMO「Agni's Philosophy」的剖析。
本文是聚焦3D模型的美术工作制作的[艺术篇]之后，由开发职员演讲的支撑「Agni's Philosophy」实现技术的[技术篇]。
这次会议聚焦技术面的4个部分。有[Runtime & Pipeline的构建和最优化]、[实时图形技术解说]、[服务器端路径搜索系统]、[次世代游戏AI架构]。这里以可以看到「Agni's Philosophy」成果的两个部分为中心。
技术推进部是如何驾驭渲染水准的庞大数据的？
关于技术详细会议的第一项，是技术推进部的首席工程师岩﨑浩氏的题为[Runtime & Pipeline的构建和最优化]的演讲。
岩﨑先生的使命是，在「Agni's Phiolosophy」开发时，把视觉工作部门（Visual Works）的渲染影像品质的资源，可以在「Luminous Studio」上实现。以[直面次世代的游戏开发所发生问题]为第一个目标而开始的本项目，首先面对难关的就是岩崎先生
岩﨑先生，首先对第一个问题数据大小进行解说。作为实例披露了「Agni's Philosophy」使用的几个场景的数据量。这些例子里，保守的场景也有500W的顶点数，纹理约1000张，总量有1GB，重厚场景有接近1000W的顶点数，1300张纹理数据量1.8GB。
「Agni's Philosophy」的艺术制作使用MAYA，场景数据完成后转换为FBX的中间格式，再进行FBX到Luminous用的数据转换。在这里进行实况编辑和时间轴编辑，接着合成最终并输出最终数据，大致是这样的流程。
因为这个项目的影像方面的高品质主要是视觉工作部门的工作，Luminous方面的编辑器不太被使用，几乎都是MAYA完成场景数据的特征，这样，MAYA到Luminous的转化工作频繁进行，在这里发生了问题。
岩﨑浩氏（SQUARE ENIX 技术推进部 Lead Engineer）
数据大小的例子。一个数秒结束的场景
关于「Agni's」的数据流
特别致命的是，打开MAYA做成的场景数据，FBX的转换，还有从FBX变换到Luminous用数据部分，对于某个场景使用的时间分别是6分，45分，1个半小时，花费了庞大的时间。因此，这种测试，改善，再测试的迭代周期就崩溃了。随着数据的日益变大，实际已经到了崩坏的地步。
于是，技术推进部把在MAYA侧频繁调整的参数保存为另外一个文件来解决问题，而且在shader变化时，都有不论编译多少次同样的代码都会花费时间的问题。
因为过于巨大的数据尺寸， MAYA的数据转换时间花费过多的问题发生了。
数据流的问题点
对于这个问题为了再利用输出的二进制，用Maya侧的插件，缩短了对应的装载时间。
而且， 对于FBX进行转换花费时间的问题，把一个场景的文件进行编集单位的分割，在Luminous的Rumtime侧导入所谓合并的结构。还有，为了解决在FBX的转换时只能使用1个CPU核的问题，把数据细分后可以用多个PC分布处理的对策，所有问题都[某种程度的解决了]。只是花力气的技巧，但是现实的方法。
版本管理使用的Perfoce也是高负荷而笨重化，据说有了一个晚上数据Commit都没结束的事情.
得到了各种教训，不过主干的「Luminous Studio」全部有了对策