LionheadAtGDC2011

http://www.gdcvault.com/play/1014350/Mega-Meshes-Modeling-Rendering-and

全名太长了:MegaMeshes modeling, rendering and lighting a world made of 100 billion polygons

简直是一个微博。

作者是lionhead的一个team的lead programmer, lionhead studio开发了fable和black&white系列的强力工作室。

介绍他们给《milo&kate》开发的游戏（milo真大牌，有人专门给开发游戏）

 

整篇文章看下来感觉挺不爽的，压缩到1/3还差不多，太长了而且有意思的信息密度非常小。

很多大家都熟知的东西还特大篇幅介绍。

 

---

 

MegaMeshes

paper从美术风格开始讲起，这个我很喜欢，程序员就是应该有更好的一个视野。

m&k是走一个小可爱的闷骚路线，polygon的形状很简单，却希望有很大的规模和高质量的lighting。

给人感觉很童话。

 

为了很好的达到这一点，这帮哥们来了个有意思的想法，让artist像雕塑一样工作，而不是create geometry， create 2d texture， 然后map上去。

而是直接在geometry上精雕细琢然后着色，着色就在vertex，需要更细致就把polygon细分，不用texture。

做完这一点之后，工具自动从高精模型上抽取出diffuse map， normal map等， 就和normal mapping产生的方法比较类似。

这个会进一步解放artist的创作力和生产力。

对于整个world，他们希望整个world放在一起来雕琢，当然实际程序中还是要分cluster，但是给artist感觉是浑然一体的。

 

但是这样一来，一个level就会有10billion级别的polygon，所以就需要一个solution来搞定这些，也就是mega mesh tool。

 

从mega mesh这个名字也能看出来会使用类似mega texture的方式来存储，在使用的时候这么大数量的polygon是没法存的，

具体存储和使用的时候会有hierarchy的概念，根据需求load不同的level。

高精度的部分是按照低精度模型顶点加delta的方式来存的，低精度和高精度模型之间有关系的，也就是说修改低精度模型会直接导致高精度模型的update（nice！）。

 

 

---

 

virtual texture

 

mesh都mega了，texture不mega有点说不过去了。

 

---

 

贴图压缩

 

mega tex会导致数据量很大，十几g是小case，需要好好压一压。

 

常用的一切都不给力，

dxt的压缩率不行

jpeg的quality不行（blocky）

最后用的是microsoft research 的Rico Malvar的ptc算法。

http://research.microsoft.com/apps/pubs/?id=101991

结果惊人：

• normal compression ptc：40：1， dxn：3：1
• albedo compression ptc：60：1， dxt： 6：1

但是在其他情况就不知道了，因为这些算法的压缩方式都是很挑源数据，有的就很好，有的一般，正好被lionhead赶上了，结果非常强力。

 

albedo texture

这里利用人眼的一个特点，就是对brightness敏感，对颜色不够敏感，所以使用YCoCg space是一个（luminance，orange，green）这样的组合。然后对orang和green进行ptc encoding压缩。

解压缩的时候就是生成dxt格式的贴图。

结果给出来是：769k：37k==大约20倍的压缩率。

 

---

 

frame analyze

 

分析场景需要那些贴图，lionhead使用把场景render一下，render不带贴图，而且输出的是texture的uv，cpu端读取这个render target就知道那些tile的texture是需要的了。

虽然看起来问题多多，但是用起来还很不错的。

 

流程上是3thread的协同工作，render thread在产生drawcall， virtual tex thread负责texture loading的工作，gpu就render。

这里就是gpu 的pipeline要尽可能的先做其他工作把需求virtual texture loading的部分mask掉。

整个协同上使用fence这些element来同步，fence被gpu consume的时候会向cpu端发event或者callback一些function，导致向virtual tex thread插入一些command， command的执行就是load in texture。

这些load进来的texture都是用来下一帧render的，所以相对还是有空间来load和lock的。

 

texture cache上也传承了传统cache的一些机制，space/temp locality。

 

---

lighting

 

算是realtime gi，但是现在这个词太唬人了，其实只是对常用的indirect lighting做一些调整。

使用spherical harmonics系数存储lighting信息，有lighting propagation过程。

用lookup table来存储sh系数，进而压缩算是一个亮点。

算法效率不高，只能适合小场景，干脆老老实实follow crytek用light propagation volume算了啊。