中文第一计算机图形学社区OpenGPU 版权所有2007-2018

 找回密码
 注册

扫一扫,访问微社区

搜索
查看: 20956|回复: 30

【西川善司】[索尼克世界大冒险]图形讲座

[复制链接]
发表于 2012-2-19 21:36:11 | 显示全部楼层 |阅读模式
本帖最后由 trace 于 2012-2-25 22:04 编辑

西川善司为3D游戏粉丝的[索尼克世界大冒险]的图形讲座
3D游戏图形趋势是实时的全局照明


2009年3月13日收录   注:因为是3年前资料,一些技术已经不是最佳解决方案
原文 西川善司
翻译 Trace
校对 千里马肝

原文链接 http://game.watch.impress.co.jp/ ... 0090410_110682.html


会场:世嘉(SEGA)总公司


[索尼克世界大冒险]和[刺猬引擎]的标志

    对于本世代主机的3D游戏图形,用户所期待的,不仅是渲染(Rendering)分辨率和纹理(Texutre)分辨率的提高,还有因为硬件性能提高也要有新的视觉体验。以此目标实现[本世代机上的新视觉体验]的就是这款基于PS3和XBox360开发的动作游戏[索尼克世界大冒险(Sonic World Adventure)],(后面简称索尼克WA)。

    要说起[索尼克]系列,一直都是以游戏趣味为主的作品。但是在本作中,加入了在今后本世代游戏机3D图形的新标准和技术的[实时全局照明(Realtime Global Illumination)](后面简称实时GI), 所以集中了很高的关注度。

    这次,想让大家聚焦这个实时GI,同时也看看索尼克WA的图形。

 楼主| 发表于 2012-2-19 21:37:07 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 22:23 编辑

[索尼克世界大冒险]的图形规格,现在的索尼克角色使用18000个多边形

    这次的采访对象是世嘉有限公司第二CS研究开发部第一程序部游戏总监兼技术总监的桥本善久先生(现在已经是SQUARE ENIX公司CTO了),同为程序员的岩崎浩先生(和桥本一起去了SQUARE ENIX)和荻野晃史先生一共三位。还有,桥本先生在2008年召开的游戏开发者会议CEDEC2008以及2009年在美国召开的GCD2009上登台做了关于[索尼克WA] 演讲。

    首先想整理一下[索尼克WA]的3D游戏图形的基本信息。主人公索尼克在本作游戏中的模型大概是18000多边形,在过场动画(CutScene)中大概是26000多边形。还有,代表性的NPC角色、村民大约是4000多边形,场景中大量聚集的普通村民大约是1800多边形,人形的敌方机器人大约是5000多边形。在1991年的16位机中以Sprite(注:绘制方式)角色首次登场的刺猬索尼克,现在居然成了要用18000多边形的角色,对于老玩家们来说真是深有感慨的信息啊!

[索尼克的特写截图和线框截图]




   
      
[敌方角色的特写截图和线框截图]



    构成1个舞台的建筑物等背景物体的多边形总数,虽然说不同的舞台构成数量也不一样,但大体上是400万到500万左右。那么1帧里,背景就是10万到13万。
【千里马肝注:400万是指整个场景,10万是指同屏。】

    视频帧率在设计上虽然设定了每秒30帧(30fps),但Xbox360版和PS3版由于各种原因在实现上有微妙的改变,Xbox360版中很多的情况是因为会超过30fps所以固定设定为30fps,而PS3版因为帧率的上下幅度很大,所以没有固定30fps而是用可变帧率来实现。

[实际操作场景和线框截图]



      



世嘉有限公司第二CS研究开发部 第一程序部,游戏总监 桥本善久先生


世嘉有限公司第二CS研究开发部 第一程序部,程序员 荻野晃史先生。

    渲染分辨率上,PS3版和Xbox360版都把880x720点作为基础分辨率,在显示时采用了缩放(Scaling)来扩大的方式。还有,Xbox360版和PS3版的抗锯齿(anti-aliasing)都应用了2x模式的MSAA(MultiSample Anti-Aliasing)。根据与视点的距离使显示对象的多边形递减的LOD(Level Of Detail)系统是怎样进行实现的呢?
【千里马肝注:两大主机都是以720P和1080P为高清卖点,这里为什么选880x720的分辨率?880/720=1.22222...好多2,即不是16/9=1.77777...也不是4/3=1.33333...,唯一能想到的理由是节省带宽,但是选880的原因还是不清楚,非要说一个理由的话就是2了……】

桥本先生[关于LOD,几乎什么都没有做。虽说如此,在索尼克WA的制作中,几何体(geometry)方面的负荷几乎没有问题。虽然只要准备用在LOD上的高模和低模(就可以实现),但考虑到成本与效果的对比,还是没有在实作中采用。在索尼克WA上称作LOD的系统,就是纹理的mipmap方面吧。]
【千里马肝注:桥本哥哥你是在开玩笑吧……】

荻野先生[因为PS3版使用了Playstation Edge, 所以在几何性能上不会有问题。PS3的主内存的容量因为很紧张,如果导入LOD功能的话,反而需要考虑低模占用的内存问题了,最后结果是什么都不用做就能解决真是太好了(笑)。]

    到了本时代主机,最近几年的游戏项目中感到多边形数有了很大的提高,关于几何体负荷紧张的传闻也很少听到,虽说如此,最近流行起来的让无数杂兵角色在同一场景内登场的三国无双]和[丧尸围城]那类的游戏作品,现在也同样有必要导入LOD系统。像[索尼克WA]那样同时登场的角色数量虽然并不那么多,但粗略计算了一下近期的游戏作品,没有使用LOD系统的案例也变多了。

    关于物理模拟,采用了[HAVOK5]。HAVOK Physics,主要利用在活动角色之间的碰撞检测和破坏时的碎片散乱等行为控制。在角色和背景的交互时的姿势控制的IK(Inverse Kinematics:逆向动力学)处理上使用了HAVOK Animation。在主要事件场景等的表演上,也要利用动作捕捉。虽然有些任性还是要说,当初作为Sprite角色登场的索尼克,如今也要用到IK和动作捕捉了。

    还有,这次为了[索尼克WA]而开发的引擎,使用了[刺猬引擎](Hedgehog Engine)的名称,今后也预定作为面向PS3用和XBox360用的索尼克系列的标准开发库来使用。

    引擎的开发是从2005年中旬开始,游戏内容方面的开发是在2006年末开始, 引擎的开发虽然是从5人左右的小规模团队开始,但在开发最繁忙的时期,程序团队大约到了40人,设计师和艺术家大约80人,包括其他的计划师,导演,制作人,声音等总计到了一百几十人的规模。那意味着,[索尼克WA]是个相当大的项目。

[HAVOK5]

HAVOK Physics,主要利用在活动角色之间的碰撞检测和破坏时的碎片散乱等行为控制


【千里马肝注:注意上图中sonic的左脚是踩在上面的台阶,右脚踩在下面,这就是IK的优点。同样下图中,如果不使用IK,就很容易让人感觉角色是浮在空中,而没有紧贴地图。】


角色和背景的交互时的姿势控制的IK处理上,要利用HAVOK Animation。

 楼主| 发表于 2012-2-19 21:38:07 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 22:31 编辑

把游戏图形做出皮克斯(Pixar)CG电影的环境感


经常可以听到[在3D游戏图形中把 Pixar touch(皮克斯画风)作为目标]的发言。Valve的[Team Fortress2]的视觉也是为了能再现Pixar touch,设计并引入了独特的Lighting技术。

    [索尼克WA]的视觉,并不是模仿现实世界那样的[照片真实系]的视觉效果。但是,也不是纯粹的卡通系,而是在影像中漂浮着独特的环境感,确实是独特的视觉效果。

    如果从揭穿这个秘密开始,那可以说就是在[索尼克WA]中采用的[实时GI]的效果。那么说,打算引入这个实时GI技术的契机是什么呢?

桥本先生[本世代的游戏图形虽然感觉在Shader上变的丰富了,但平行光源(太阳光之类的落在场景全体上的光源),点光源(局部性的照射全方位的光源)没有被直接照射的位置的阴影都被省略了。开始想到“这样有些欠缺”,于是就成了契机。还有,之后作为长篇CG电影制作工作室,以再现出著名的皮克斯作品的气氛作为目标,推动了实时GI的开发。

    在现实世界中光会在空气中散乱而扩散,被光直接照射到的对象本身会让光反射照到其他对象上而成为2次光源。在现实世界中,这样复杂的反射和扩散会同时多次发生,这个就是真正意义上的环境光(Ambient Light)。

    把这些用计算机图形学来归纳就是[辐射度(Radiosity)]和[光线追踪(Ray Tracing)]。把Radiosity和Ray Tracing在本世代机的游戏图形上实现,GPU的性能还不够。因为,要设计出用模拟来实现这个的方法,而且要考虑在实时中实现。

    开发组为了实现在实时中使用[GI],采用了把实时GI分解成两个技术进行实现的策略。1个是对应不能被破坏或无法移动的背景物体等静止型对象的GI。还有第2个是对应移动或肢体弯曲角色的GI。


在现实世界中的全局照明(Global Illumination)案例。虽然作为实际形态的光源,只有从办公室天花板的荧光灯,但这个光经过红色的文件夹的反射, 这个红色的文件夹就作为2次光源把白色的刺猬纸偶照成红色。如果直率的说,所谓的全局照明就是间接照明和互相放射的照明现象。


CG中再现的全局照明的案例。作为实际形态的光源,虽然只是天花板照明的场景,但光经过左右的红和青的墙的反射,这些就变成了2次光源,很明显的把房间中的对象照上了淡淡的红色和青色。

 楼主| 发表于 2012-2-19 21:39:05 | 显示全部楼层
本帖最后由 trace 于 2012-2-20 00:06 编辑

[索尼克WA]的GI技术(1)----对静态对象(Object)的GI
    静止的对象GI,采用了事前离线计算,把计算结果绘制(烘培)到纹理(Texture)的方法。这种使用事前计算的GI信息烘培出来的纹理,在开发组内被称为[GI纹理](GITexture)

    在游戏的实时渲染中,把这个GITexture作为光照贴图(Light map)来使用。也就是说,作为基本技术,因为光照贴图不会改变,所以渲染也不会有额外的负荷。

    那么,虽然是[反过来和光照贴图没有区别],不过,GITexture的生成,可以配置场景的背景对象和小道具/大道具对象,或是在大局上进行天球光源和电灯类局部照明等等全部光源的设定。这个就是在GITexture上计算的一个单位(为了方便说明把这个称为GITexel )

[GITexture]

显示了GITexture的特殊截图。一旦认真看,就应该会看到斑斑点点一样的东西。这些就是GITexture的计算单位。

    如果从这些GITexel开始向适当方向发出射线(Ray),就会通过提前计算来获得每个GITexel是由什么颜色的光照射到。顺便说一句,发出的射线虽然会被遮蔽(或者是和其他对象有碰撞),还有反射或扩散等情况,但开发了出现这些状况计算也不会发散的方法。

    关于原理简单的解说一下。首先,从每一个GITexel上发射有限个射线(Ray),就可以发现射线碰撞目标的对象上的GITexel。这时如果入射角度和碰撞对象的法线越接近,也就是用越接近直角的形态碰撞,线的密度就越高,也就是用强光传递,要从全部的GITexel开始进行这个计算。进行了这个,场景内的GITexel单位的光传递网络也就生成了。

[GITexture2]



首先,进行光的网络的生成(第一阶段)

    在这个时候虽然还没有进行lighting,但要考虑贴在多边形上的画像纹理的内容,比如处在贴了画像纹理的红色Texel(纹素)的位置的GITexel,就会反射红色的射线。这些在实质上实现了GI效果的特征 [一旦红色物体被光照射,这个就会变成红色的2次光源]。


    这之后,转移到了实际的lighting计算上,作为光源来使用的,有平行光源(Directional),点光源(Point)和天球光(Sky)三种类型。配置了在游戏中登场的这三种光源后,进行计算。从这些光源发出的光,要预先计算是到达了哪个GITexel上(作为direct light来lighting)。这相当于之后的GI计算的光量(light energy)的初始值。


[GI Texture 3]




因为贴图纹理的Texel尺寸和GITexel的尺寸不同(译者注:通常最后生成light map尺寸会比较小,也可以通过“texture atlas”合并到一整张图上),寻求平均值的处理就很有必要了,不过在[索尼克WA]中省略了这个计算。[索尼克WA]中,采纳的是和GITexel中心重叠的画像纹理所代表的Texel颜色。

作为光源用到的有平行光源,点光源,天球光三种类型

在实际的场景中配置了全部的光源,正如之前描述的光的传递网络那样印象


计算流程
  1对各GITexel, 通过光的传递网络对全部直接光进行照明计算,计算结果放到buffer A里
  2 对各GITexel,通过光的传递网络对全部间接光进行照明计算,计算结果放到buffer B里
  3 计算各GITexel的光量(light energy),就是把buffer A和B的内容合算,
  4 为了下一个循环的反复计算,要计算从各Texel发出的光量 (用[光量(light energy)的总数]X[每个素材的反射率]X[系数]÷[和这个Texel连接的GITexel数]来计算)

从(1)到(4)是1次运算里的一个循环。
【trace者注:如上图所示,1~4循环计算1个微平面的入射光能量总和(作为这次的光照计算结果)与微平面的发出光能量(提供给下次计算使用),当所有微平面都进行1~4后,一次光计算完成。】

    要点是为了不会被计算顺序影响,各计算周期用双缓冲来计算。把这些反复进行,光就会弹射(发射的射线开始反射)后多次反射。顺便说一下,把(1)到(4)只进行1次运算,只相当于直接光的照明,所以就没有GI意义的结果。是根据开发组所说,感觉(反射)3次有些不够,9次有些过多,4到6次左右比较合适。

【千里马肝注:参考Radiosity文献,
原文:http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm
译文:http://dev.gameres.com/Program/V ... ity_Translation.htm
注意到文中提到的patch,与本文中的GITexel,以及配图中的GI microfacet是一个概念,目的是通过建立一个单位,来反映周围环境对它,以及它对环境的影响,然后从画面上就会有Global的联系感。那么就像计算光照贴图一样,与其从光线发射ray到物体,不如从物体最终贴图上的texel来发射ray,通过控制texel的面积来决定GI的效果和所需的计算量。】

 楼主| 发表于 2012-2-19 21:39:46 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 22:46 编辑


世嘉股份公司,第二CS研究开发部,第一程序部,程序员岩崎浩先生

岩崎先生[设计上,GITexel的计算单位是可变变化的,大体上一个边是2厘米到3厘米左右。白天的场景即使粗略些也不显眼,不过,夜晚的景色有路灯等的照明带来的GI,非常容易看出来,所以在调整上要多用心]

    还有,发射的射线(ray)碰撞到对象如果是有透过性材质,就会正确的透过,透过的材质颜色也要加上进行处理。举一个易懂的例子,把非洲作为主题的玛祖利地区的帐篷上的房檐。只要看房檐的内侧,就应该会明白帐篷的颜色在淡淡的扩散开。

    设计上,GITexel发射出的射线数量虽然是能够变化的,不过[索尼克WA]的开发中,很多情况是使用250左右个射线,发射方向虽然是从基点向全方位的放射状,但要作出在垂直方向(法线方向)上比较稠密,在水平方向(切线方向)上比较稀疏。即使这样,这个GI计算要对应整个舞台,而且还要在GITexel上发射250个射线,计算量是很庞大的。

桥本先生「对于500米x 500米的地形,让1台PC来计算大概需要用两天时间。做出的GITexture大约是100MB。每一个舞台因为大约有15公里的范围,简单的估计,就会知道GITexture就会有数百MB到1GB以上,计算的时间会用数个月(笑)这样就麻烦了,所以生成GITexture的工具要可以对应分布式计算]

    据说这样GITexture的计算时间就会是数十分之一,最多可以缩短到一百分之一,一个舞台的计算就能缩短到1天到两天的左右了。

[GITexture 4]



生成的GITexture图例

桥本先生[为了这个GITexture计算用的分布处理,在组内扩充了几十台PC。要是这样电力就不够用了,那么就要使用某种特殊的电源,电力不足时把其他不重要工作岗位的电源开关断开(笑)。结果电力增强的工作就省去了]


MI-TRACER的画面

    [索尼克WA]的开发中开发了各种工具,这当中,生成GITexture的工具被命名为[GI-TRACER]。还有,对应GITexture的再现细微凹凸用的法线贴图生成,开发了名为[MI-TRACER]的工具。MI是组内创造的词[Micro Illumination]的缩写。

    基本的GITexture用GI-TRACER作成,为了玩家接近后可以观测到细微凹凸,要对对象的纹理使用MI-TRACER。MI-TRACER的具体应用,主要是石壁的细微凹凸等方面

    计算时间也缩短了,由于生成的GITexture可以放入到Atlas Texture(把很多零散的GITexture放入到一张大的Texture里,减少了浪费),所以在纹理容量上实现了节省。不过最终是保存在实际运行的内存(On Memory)里,怎么都会变大的。

    基于舞台,一个舞台周围的GITexture的总尺寸,在小型舞台上也要200MB左右,在大型舞台上要到达1GB左右的程度。把这些全部保存在显存并不充裕的PS3和XBox360上是绝对不行的。那么通过同步索尼克的移动,把GITexture从media里(如果是PS3就会是蓝光,如果是XBox360就是DVD-ROM,在硬盘中安装的情况就是硬盘)动态Streaming读取的方法。

岩崎先生[作为代替的,游戏中的BGM和Sound是全部放入到运行内存里的,虽然和Sound相关的有些容量限制,不过也分配了40MB左右。1个舞台里使用的BGM和Sound的数量是足够用了。因为索尼克的秒速是100米以上,GITexture的读取是否能赶上让人有些不安,不过设计了对应GITexture的Streaming读取,结果完全没有问题。]

    下面的截图,是场景只应用了GITexture材质纹理,没有GITexture只进行正常Lighting,在正常Lighting上应用了GITexture的完成画面的比较。

    一旦没有GITexture,再看游戏形态的影响,那完全就是对象物体(Object)被放置的感觉,一点没有作为场景的整体感。还有作为映像的立体感和远近感看起来也缺乏。

   一旦加入GITexture,场景里对象的立体位置关系就会在视觉方面容易把握了,气氛和触感更容易作为知觉被传达。

[GITexture 5]

只有GITexture


没有GI只有通常的照明(感觉很多一般的游戏画面就这样)


附加了GI的完成镜头

    还有,GITexture是mipmap的构造(为了适用在远离视点的场所,把低分辨率的纹理预先生成技术),读入的GITexture中,包含了靠近视点位置用的高品质GITexture到远离视点位置的低分辨率GITexture。 游戏中跑动时会动态读取GITexture,也就是GITexture发生切换,为了不会使外观看起来很奇怪,要认真的调整。

[GITexture 6]







GITexture的mipmap level通过颜色区分的可视化画面(level高低按红->绿->蓝)

    还有,[索尼克WA]的发售后,追加的下载内容(DLC)发布了,作为隐藏内容,也收录了本篇中GITexture的高品质版本。「索尼克WA」的用户,一定也要得到追加DLC啊,把正规舞台玩过后,玩过正规舞台后,就可以看出GITexture的品质差异了。

[GITexture的品质差异]





上段是发售版的GITexture品质,下段是DLC版的GITexture品质。

 楼主| 发表于 2012-2-19 21:41:22 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 23:31 编辑

[索尼克WA]的GI技术(2)----动态物体对象的GI


半球Lighting的概念图,是通过顶点的法线向量和天球的角度关系,来决定天球色和地球色的混合程度,设定环境光。

    GITexture的效果虽然很好,但因为用的是预先计算的方法,所以不适用于活动的物体上。一但要实现的话,动态角色的阴影,就会和背景没有整体感,而是感觉在漂浮着。具体的,对于背景的建筑和小道具或大道具物体对象,通过GITexture做成了间接光和互相反射来表现,而动态角色只能从动态(或静态)光源的直接光进行照明(Lighting)。

    开发组感觉在本世代主机的3D游戏图形上,适用于动态角色的GI手法是不可缺少的,一直致力于这个课题。动态的简易GI方法、GI模拟等几个代表性的手法已经实用化了。
【千里马肝注:文中一直在强调“本世代”和“次世代”,通常上市2年后的主流主机会被看作“本世代”,而下一代的概念机或刚上市的新主机,因为机能要强于当下的主机,所以被称作“次世代”。所以并不具体指某一型的主机,而是具有时代的象征。例如:DC和PS2相对于SATURN和PS。】
  
    最简单和古老的就是设定固定的环境光。是从PlayStation时代开始的手法,把一个区域内的光的颜色设定成一种指定颜色的手法。但是所谓的[环境光]是徒有其名,当初,因为只能从光源直接照明生成阴影,一些需要过暗的场合,就要使用这个技巧来达到“阴影的提高加固”的目的(就是指定一个黑色环境光区域,弥补暗度不足)。

    这些进化后的就是[半球Lighting]的技术了。这个是把场景提前计算的GI信息,适当做成有两个方向的环境光,对活动角色追加Lighting的手法. 把前面描述环境光的概念做了扩展,在环境光上拥有两个方向性的手法,把这两个方向的环境光根据角色在场景内的位置做切换,就可以把这个场景的各位置局部间接光和相互反射表现出来了。

    这个半球Lighting的技术, 在PS3的[合金装备固体4(METAL GEAR SOLID 4」)]中也采用了。但是在[MGS4]的案例里,是通过关卡设计师手工的放置半球光源,依赖高超的职业技术来实现的。无论如何,半球lighting都是很经典的手法,

桥本先生[虽然做了各种各样的讨论,不过我们决定把半球lighting改进后的概念导入。在组内是称为[light field]的技术,是比半球Lighting的两方向环境光,在空间内自动的计算出更多方向环境光的配置。

    操作索尼克在场景内走动的话,地面的反射会使得索尼克身体的下方会浅浅的受到地面颜色的影响。一旦接近有颜色的墙壁,索尼克的侧面就会受到从那面墙来的间接照明,浅浅的加上墙壁的颜色。头上生长茂盛的花的角色,受到阳光的直射时,也会把花的颜色淡淡的染上。如果作为画面整体来看,因为GITexture背景和大小道具物体对象的阴影都符合GI lighting,即使对活动物体也可以进行。

[light field]



没有light field(一般的游戏图像就是这感觉)




只显示light field的画面



   
应用light field后的完成截图

    [索尼克WA]采用的[light field], 简单来说就是在那个场景的空间内在适当的距离间隔里, 配置出拥有方向性的环境光。在[索尼克WA]的实现中,各环境光配置成了8个方向发光的方射状配置。感觉上来说,就是在舞台空间里的适当间隔配置了向8个方向发光的光源。

[light field的模式图]


light field的模式图。在这个图里,被设定的环境光虽然只是个点,但有每个点向8个方向发光的印象


和Valve的Ambient Cube概念很相似的[索尼克WA]的light field。

    把这张图用简单案例说明的话,就是将角色用包围自己的8个环境光做Lighting。虽然实现上不同,但概念上和Valve在[Half-Life2]上采用了[环境立方体](Ambient Cube),以及[辐射照度体] (Irradiance Volume)可以说是很接近的。在[Half-Life2]中,根据角色的平均体积,用120cmW X 120cmD X 240cmH的大小把空间分割开,对于每一个区域(Volume),加入怎样的光(光是否出现),都要用离线提前计算出数据表。实时渲染时,每个角色要参考所在位置的Volume,取得进入的哪个Volume的6方向的光,把这些作为拥有方向的环境光来处理。想法和[索尼克WA]的light field很接近。

桥本先生[在索尼克WA中, light field的各点作为数据虽然拥有8个方向的环境光,但因为Pixel Shader有Constant寄存器的关系,和XYZ的直角6方向换算后,就形成了Lighting。对于跨过8个light field环境光的案例,把最近的多个light field采样后根据权重计算平均,再进行后面的Lighting。

    这个light field的设定,波及到了舞台的全体,因为设计师要用手工操作设定这些,所以花费了过多的时间,在正确性方面也留有些担心。那么在[索尼克WA]中,用前面说的到GI-TRACER,可以把这个light field提前计算。

岩崎先生[生成了背景和大小道具对象使用的GITexture之后,使用这个GITexture的场景的light field值也要算出来。light field的大小虽然依赖于场景,大体上把2米到3米为基本,感觉物体很多被配置在建筑物的附近也许会稍微精细些。但是相邻的light field有时同样缺乏变化,因为会归结为一个来处理,所以实际各light field之间的距离是可变长的。]

[light field的区域图]
   
把light field的区域做成可视化的图片。大概可以看明白light field可以用不同的大小来设定吧。

    light field的采样不能在活动角色的多边形面上做处理,而是通过各角色设定好的代表点方式进行处理。这个代表点高度一旦过高,就会影响从下方来的光源,会影响到角色的上半身发生不协调,所以要根据每个角色进行适当的调整。还有,在索尼克的世界观中,没有多少巨大的角色登场,不用考虑在纵方向上跨过多个light field的处理

桥本先生[其实根据材质的不同,不只是法线方向的light field,也要参考和视线向量相对的反射方向的light field。由于这样做,对面的环境光在浸透后也可以在这边溢出,出现微妙感觉的阴影效果]

    把逆光渗透到这边的一样的表现称为边缘光(Rim Lighting)表现。边缘光表现,通常是和光源对视时一样的,大多情况是在容易看到逆光时用来作追加高光的效果。[索尼克WA]中,也要在逆光位置的light field上进行边缘光的表现。因为这样做,就好像场景的间接光中也能表现出像是表面散射那样的淡色阴影和透明感。进一步说,能够表现出活动角色在哪个场景中融入GI的感觉,特别是这个效果在开发组里称之为[GI边缘光]。

GI边缘光(Light Field Rim Light)的概念图


[GI边缘光]   


无边缘光


只有GI边缘光


完成画面

岩崎先生[虽然也讨论过把这个light field用球谐波函数(SH :Spherical Harmonics)来实现的方案,但考虑使用的内存容量和得到的效果平衡时,很清楚这是没有意义的,所以不再采用了。我们实现了拥有8个方向的环境光,即使不使用SH也可以得到足够的品质。]

    球谐波函数作为把分布在全方位放射状的数据值不可逆的压缩手法,在3D图形的应用上发展着,但即使使用球谐波函数第二项,也需要9个必要的系数,所以想要实现的(场景)主题和数据量,以及不能很好的计算平衡性,还是放弃掉比较好。[索尼克WA]的情况中可以说正是那样吧。(阅读Real Time Rendering 3rd P320 获得更多资料)
  
    [索尼克WA]因为有很多跑着穿过的动作镜头,不留神的话,也许就会有用户没有注意到这个GI系统的优点。虽然对游戏的进行是没有意义的,但还是希望让索尼克接近游戏世界里的各种背景物体,以确认这种独特的环境感的Lighting。还有,在过场动画(实时Movie场景)和村子的任务场景里,因为能有效的观察,应该可以同时享受村内探索和探索GI系统的效果。

[完成场景]

背景只有GITexture的状态


索尼克只有light field的状态


GITexture的静止影子


完成画面

 楼主| 发表于 2012-2-19 21:41:56 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 22:57 编辑

[索尼克WA]中HDR渲染技法
[索尼克WA],沿袭了近年来3D游戏图形的趋势,当然,也采用了HDR(High Dynamic Range)的渲染。特别是[索尼克WA]几乎全部的场景都在室外,而且要用让玩家能容易区分[昼夜]时间变化的形态来表现,特别是要活用前面提到的HDR渲染的效果。

在PC上说起HDR渲染,现在从16位的浮点的FP16-64位buffer虽然成为了标准的定义,但在本世代家用机很多是采用了8位整数的int8-32位buffer。上次报道的[METAL GEAR SOLID4]也是那样。本世代的家用机的GPU,XBox360和PS3都是用128位的总线连接显存,只有PC的主流GPU的256位总线一半的带宽,很多情况会作出这样的选择是因为填充率不够。

岩崎先生[索尼克WA的HDR渲染,是整数8888的int8-32位buffer配置, XBox360和PS3都是共通的。把0.0-0.2在0-255上分配,就成了所谓的疑似HDR渲染。虽然在开发初期试着使用了FP16-64位,但性能太紧张,就做成了现在的配置。]

[HDR渲染表现]






上段关闭HDR渲染表现,下段开启HDR渲染表现

    这个正好和[女神侧身像2]等的实现方法相同。这个方法和用通常的LDR(Low Dynamic Range)渲染,把0.0-0.1的亮度分配到0-255上相比较,虽然分辨率只有一半是个弱点,但在[索尼克WA]中,游戏时基本上没有马赫带((Mach bands)的现象。

桥本先生[索尼克WA的情况,没有那种高亮度的震动场景,用最大辉度2.0已经足够了。马赫带不显眼,大概是因为表现单调的物体做的比较少的原因吧。]

    [索尼克WA]的HDR渲染,虽然是用模拟方法实现,但因为亮度2.0作为“真实”HDR渲染,渲染结果显示时,在适当的阶调范围内,进行toon mapping的工程就有必要了

    比如说,进入桥梁下面等昏暗的地方,就会慢慢看到暗处的阶调,面向太阳的景色就可以看到白光溢出。反过来,一旦从暗的地方出来到明亮的地方,光溢出位置的细节就可以慢慢看到。在玩游戏时,注意到这样的HDR渲染Toon Mapping的表现效果的人大概很多吧。

[Toon Mapping]





  
从明亮的地方到暗的地方,还有从暗的地方到明亮的地方。Toon Mapping的效果很受注目。

    [索尼克WA]的Toon Mapping处理,首先获得当前frame的平均亮度,再把这个值用适性阶调来修正, 是一种很正统的技术。但是,在地图内特定的地点,需要配置专用的bounding box,实时的计算平均亮度,再加入补正做调整。
【千里马肝注:HDR不是一个可以放之四海皆准的渲染手法,容易过暗或曝光过度,如何能适配不同场景不同地点,就需要人肉了。】

桥本先生[这些都是为了容易操作游戏的考虑,为了让玩家清楚的看到场景的表现,虽然还有许多理由,不过调整还是必要的啊。原本设计师描绘的纹理,在设计时用适当的颜色来着色,但这些在阶调等级调整中,也有可能会出现那种不能恰当发色的情况。]

    HDR渲染中的经典效果有高亮度溢出表现[bloom]和[star]的表现。在[索尼克WA]中,采用了本世代中成为趋势的缩小buffer的实现。具体的把frame中的高亮度部分在多个不同低分辨率的buffer中抽出,对于这些应用高斯路径,再用bilinear-filter扩大为统一尺寸进行合成。Star效果也是在低分辨率buffer中抽出高亮度部分进行旋转或压缩,把这些展开后合成,就是把高亮度部分放射状伸出的手法了。[索尼克WA]中Star表现的放射方向是4到7个,主要用在夜晚的场景中。

[后处理(post process)效果]



   
夜晚的场景,很容易看明白Bloom和Star等HDR渲染带来的后期处理效果。在玩游戏时那些效果也很受注目!

 楼主| 发表于 2012-2-19 21:42:52 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 23:02 编辑

夜晚索尼克的[WereHog]毛皮(Fur)的秘密
【trace注:这个词来源于WereWolf(狼人),Hog有刺猬的意思,所以WereHog是狼化刺猬的意思。】

    要说起[索尼克WA],索尼克的变身是个热门话题。本作中索尼克到了夜晚就会变身成狼人风格的[WereHog]。一旦变成这WereHog,就成了四脚爬行着跑,能用特殊的手臂伸长动作。迄今为止的索尼克系列中都不曾看到的独特的游戏操作虽然让玩家很享受,从3D游戏图形的观点,WereHog的毛发浓密的姿态很勾起人的兴趣。

    [索尼克WA]中变成WereHog时的毛皮表现,全都是使用了[Fur Shader]。Fur Shader虽然有几个手法,但WereHog上采用的是把毛的断面图做成纹理,在3D模型的表皮多边形上叠加多层的手法。采用了所谓的[Shell方式的Fur Shader]。

    Shell型的Fur Shader也使用在[旺达与巨像](SCE2005)的巨像的毛皮表现和[失落的星球](卡普空2007)的防寒服的领子的毛皮表现中,因为是比较主流的手法,看到的机会也很多。
【千里马肝注:HD复刻版[旺达与巨像]已登陆PS3。失落的星球2也登陆了PS3。】



岩崎先生[毛皮(Fur)的层数大概是15层左右。开发时,设计师可以调整层数和毛的密度等。为了应用在毛皮上,把Shell多边形设置为在引擎里动态生成的结构。所以在建模阶段的角色是没有多层外皮多边形的。事件场景和游戏中,层数是变化的,在事件场景中角色很多情况会大幅度增加,所以层数就要多做。

岩崎先生[毛皮的层数大概是15层左右。开发时,设计师制作了层数和毛的密度等都能调整。因为适用了毛皮的外皮多边形在引擎方面作为动态型生成的结构,所以在建模接的角色中没有多层外皮多边形。事件场景和游戏中,层数是变化的,因为事件场景中角色的特写镜头多层数也会比较多。

[Fur Shader]

毛断面纹理的图例


创作阶段没有毛皮的WereHog


调试画面中登场的没有毛皮WereHog


应用上毛皮的WereHog

    因为[旺达与巨像]中是3到6层,[失落的星球]的防寒服上是8层左右,WereHog皮毛的Shell会相当多。因为 “长毛”WereHog的身份,在这里要强调处理。

    还有,这样做出的[动物毛皮]的表现中,使用Shell方式来表现毛皮在密度上会不足,还有因为位置关系,顶部附近的毛感觉密度不足,把描绘了侧面毛的纹理应用到多边形上再植入角色,和Fin类型的毛皮共通使用的情况很多。

[Fur Shader 2]

NVIDIA的演示。没有毛的模型


只有Shell方式的Fur shader


Fin类型的毛皮


最终效果

岩崎先生[Fin类型虽然是我们在开发阶段就尝试加入的技术,但因为[索尼克WA]的WereHog使用的Shell方式的毛皮层数很多,没有觉得毛的密度不足,就没有采用(Fin类型毛皮)]

    此外,WereHog的毛皮表现,也加入了其他细致的有趣方法。那就是在毛皮的断面纹理上,提前加入了毛的倾斜信息,把这个断面纹理应用到各层的shell多边形,这个倾斜情报就会产生挪动效果。根据各层上微妙的毛断面纹理偏差,实现了毛沿着一个方向倒着生长的表现。这个就是[毛的样子]的表现生成。

[Fur Shader 3]


关注WereHog的毛的样子,因为Fur Shader的方法毛倒竖着

    注意WereHog在手臂周围的毛的方向和手腕周围的毛方向是不同的,这些就是由这种方式来实现的。

桥本先生[这以外,还在毛梢上作出镜面一样的阴影处理,还有内侧的下层Shell的周围因为被遮挡,所以加入了毛梢明亮一些,毛根会变暗的阴影调整。[索尼克WA]的毛皮虽然感觉相当好,但是,会有在景深的表现产生模糊时,毛也会变得模糊就不自然的问题。这个可能是shell方式的Fur Shader的弱点吧,应该如何解决是今后的课题啊]

[景深(DOF)效果]
  
上图是关闭景深效果。可以很清楚的看到毛的样子。下图是开启景深效果。毛和背景一起模糊了。

 楼主| 发表于 2012-2-19 21:43:46 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 23:07 编辑

[索尼克WA]的影子生成
    [索尼克WA]因为是室外场景为主的游戏,在视觉方面,影的存在感很重要。一旦玩着游戏,就会出现Self Shadow,也支持那种其他人的影子投射到自己身上的相互投影,感觉出现了相当好的影子。

    开发团队表示,在[索尼克WA]的影生成中,采用一种改良型的Depth Shadow技法(LSPSM∶Light-Space Perspective Shadow Maps)关于LSPSM,希望参考在本连载以前刊登的[为3D游戏粉丝的XBox360图形和物理引擎讲座],但是那里并没有死规定要把LSPSM实现。在[索尼克WA]中,成为和GI系统协调很好的有趣实现。

[索尼克WA中的影表现]



[索尼克WA]中影的表现是动态生成的影和提前生成的静态影混合的技法。

    首先,落在地形上的背景等物体的影子,实际是通过GI-TRACER生成的GITexture的影子。为了不出现锯齿,虽然应用了soft shadow的 “模糊”,可以认为这些落在地上的影子是提前生成的影子,就是静态的影子。

    但是,一旦让动态的角色在静止的影子附近移动,在动态角色上就会被投射静止物体对象的影子。就好像是提前生成的GITexture上烘培影子,实时的投射在动态角色上一样。这个很有趣,想不出是怎样做到的。

[影生成]

作为GITexture的影子(上),完成画面(下)

[影生成 2]


在GITexture的影响范围内,背景的影子投射在动态角色上的场景
   

    实际是用LSPSM把动态角色和静态物体对象的shadow map生成,但在使用这个shadow map绘制影子的阶段,要做特殊的适应性处理。首先,作为原则,静态物体对象的影子不能绘制在静态物体上。例如,树木的影子,不能通过LSPSM在地面上实时的绘制阴影。

    但是,在动态角色上,要用LSPSM描绘出全部的影子,例如,索尼克的影子即时要绘制在地面上,投射在索尼克身上的树木影子也要在索尼克身上绘制。

    换句话说,静态的GITexture里烘培的影子,在和动态角色交叉时,看起来好像是静态烘培的影子投射到动态角色上一样。实际上,只是用LSPSM生成的静态物体对象的实时影子投射在动态角色来欺骗。

[影子生成 3]




从上开始,只有GITexture预生成的影子,只有LSPSM的影子,把全部的影子用LSPSM生成场合的试验图片(在成品版中这些没有被采用),把GITexture预生成的影子和LSPSM的影子合成的完成画面。

岩崎先生[万一把静态物体的影子全部描绘(使用LSPSM),和GITexture上的影子,重合大概会有不一致的地方。例如,落在地面上的树木的影子,和投射在索尼克身上的树木的影子是不是一致,玩家不会在意的吧。还有,静态对象物体的Shadow map的生成,也可以在和动态角色交错的狭小范围内完成]

如果反过来说,这个技术,把涉及到广阔范围里的静态对象物体的实时阴影绘制全省略了,静态物体的实时阴影只要绘制投射在动态角色上的就可以了,也应该减轻了负荷。这是个很聪明的手法。还有,在[索尼克WA]的LSPSM中,作为生成Shadow map 使用的纹理,使用1024x1024像素大小。

桥本先生[顺便说一句,索尼克的很尖的脑后头发部附近的影子,是用3dsMAX烘培阴影修正后的的效果。在(角色)局部看着特别明显的阴影也要特别重视外观的烘培

[影生成 4]






上面是素体状态。下面是在创作阶段的局部烘培阴影
【千里马肝注:本以为有什么特殊技法,说白了就是静态物体使用baked lighting map + 动态角色的projection shadow,然后动态物体使用全场景(不包含所有动态物体)realtime shadow map做projection shadow,同时利用了LSPSM自动根据camera充分利用shadow map的优点。另外角色还使用了预计算好的ao map来表现自阴影,然后根据我从截图上的观察,应该没有计算self shadow,只是把整个LSPSM的shadow map给projection到角色身上了。从文中了解到LSPSM是1024x1024,而且生成范围是整个场景,所以如果用在self shadow上势必会出现大量artifacts狗牙,从而影响游戏画面的小清新。】

 楼主| 发表于 2012-2-19 21:49:27 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 23:13 编辑

[索尼克WA]图形的其他看点


Valve开发的Half Lambert Lighting

    在[索尼克WA]中,有很多有变化的人类角色作为NPC登场,在lighting上,应用了由Valve实用化的Half Lambert Lighting。
  
    Lambert Lighting用在扩展反射的阴影处理,不依赖视线方向,由光源入射方向和表面方向(法线)计算出阴影的处理方法。这个技法使用[位置的亮度,与这个面的法线与光的入射方向夹角θ的COSθ值成比例]的[Lambert余弦定律]来定义,但实际上一旦使用这个lighting, 明暗就会出现相当强烈区别的倾向。

    VALVE为了得到与GI相似的扩散反射表现,使用了在这个剧烈变化的Cos Curve加入了bias来提升黑暗部分阶调的方法。Lambert余弦法则的Cos Curve(-1,1),乘以 “1/2”变成了一半(-0.5,0.5),加上 “1/2”(0,1)并平方,用这个平缓的Curve做阴影处理。被称作[Half Lambert Lighting]。

    这个Half Lambert Lighting,于[索尼克WA]的GITexture和light field的模拟GI配合的很好,Half Lambert Lighting稳定的阶调表现加上从light field来的淡色阴影的调和,确实酝酿与 [皮克斯]相似的视觉感。

[Half Lambert Lighting]

左图是通常Lambert Lighting的测试截图。阴影过浓,人的皮肤会发黑不自然。右图是在半成品中使用的Half Lambert Lighting的画面

    还有,为了能让人更容易看到法线贴图产生的细微凹凸,从视点位置打了淡淡的光[Camera light].由于这个手法,即使只是从起点稍微移动,也容易看出细微凹凸的高光变化和细微凹凸感。虽然是细小的技术,但在光量少的地方,通过法线贴图来生成细微凹凸表现,无论哪个工作室都会觉得这是辛苦的部分。这个Camera light的技术虽然很单纯,但效果很好。

[Camera light]






上面是关闭Camera light。下面是开启Camera light。在墙壁和地板的法线贴图上出现高光,看起来更立体。得到了接近电影的照明效果。
【千里马肝注:小trick来了,虽然是卡通风格,但也使用了normalmap来表现物体的凹凸,但在游戏中观察时,往往不像使用模型查看器中那样,近距离而且会特地在物体正面打一盏灯来观察。所以本作使用了所谓Camera light的方法,不论实际光源离物体多远,角度多么接近平行,但始终在Camera处有一个light来影响,那么“面对Camera或者称作法线垂直于Camera、画面近距离”的物体的normalmap就更加醒目了。】

    [索尼克WA],虽然不是以和水面的互交作用为主的游戏,但由法线贴图生成的轻微水波效果,由Fresnel反射进行水底和水面的镜像的控制等,做出了相当好的水面表现。
  
岩崎先生[当初开发轻微水波时使用Parallax Mapping,实现了相当立体的微波表现。但是,GPU的负荷也出了问题,以决定由现在的法线贴图来表现。

[水面表现]


   
[索尼克WA]的水面表现很美。Fresnel反射的效果和动态形角色的镜像都会很好的显现,试着去观察吧。

 楼主| 发表于 2012-2-19 21:50:35 | 显示全部楼层
本帖最后由 trace 于 2012-2-19 23:14 编辑

附加---PS3版和XBox360版的辛苦开发


一边画图一边说明的桥本先生

    虽然在最后的游戏规格上,PS3版和XBox360完全没有差别,但在开发阶段有着各自特有的辛苦。

    首先,XBox360版的DVD媒体的容量紧张。要是除去系统等占有的容量,游戏内容能利用到的是2层媒体大约6.2GB。把本世代的高画质游戏内容塞到一张DVD中是相当辛苦的。还有,XBox360因为发售了没有HDD硬盘的主机,所以必须做出只用DVD就能运行,没有使用把压缩的内容在HDD上展开的方法。微软发表XBox360时,主张[次时代游戏媒体不是光盘而是网络],虽然采用了不是次世代光媒体的DVD-ROM,但那个决定对开发方没有给出很好的影响。

    XBox360的GPU因为是3个PowerPC970互换Core让两个hardware thread启动,最多可以同时运行6个线程。[索尼克WA]上,线程0到5的6个线程中,按线程0是主线程,线程1和2和4是HAVOK,线程3是控制动态加载使用,线程5是数据管理处理来分配的。

    因为也有XBox360版先登场的关系,游戏制作没有对XBox360版进行基本设计,而是使用同时移植的形式来做PS3版的开发。

荻野先生[PS3版的开发很困难,在XBox360已有程序库中的机能和函数都要对应移植到PS3上。主内存的处理也很费劲。PS3上的DMA情况,数据是用128byte border,一旦不匹配就不能发挥性能。而且和XBox360的512MB内存自由的使用不同,PS3中分成了主内存256MB和显存256MB。]

    PS3版标准光媒体因为是蓝光,即使是1层也有25GB的容量。正因为这样,虽然不会像XBox360那样媒体容量紧张,但在PS3上主内存不足的问题却浮现出来了。

    最后,虽然主内存怎样做都不够,但PS3的有搭载HDD硬盘,可以作为虚拟内存来使用,于是决定活用这个机能。在[索尼克WA]中,结果是使用了HDD硬盘的256MB作为虚拟内存,和主内存方面的50MB范围作交换来活用。被放在虚拟内存的有Audio,PVS判定, HAVOK的POOL,字体和文字信息,HUD数据,存盘记录数据,RSX(GPU)的管理领域等。

荻野先生[这次的PS3版的开发中,SCE提供的程序库Playstation Edge起了很大的帮助。包括这个,把CELL处理器的SPE(Synergistic Processor Element)在Vertex Shader上活用的Edge Geometry也显著活跃着。不止是Culling,特别是Skinning的效果很厉害,是只用RSX处理的10倍以上吧。虽然和XBox360版有很多的数据是共通化的,但因为活用了这个Edge Geometry的关系,3D模型数据等都施加了PS3专用的优化。]

PS3的CPU,CELL处理器里,能够实际运行的SPE搭载了7个,不过PS3版的[索尼克WA]中SPE使用的方式,SPE1和SPE2为系统活用,空闲时SPE2运行Audio System。SPE3到6是HAVOK和Playstation Edge等,SPE7负责绘制的管理。


3D游戏图形的Lighting向GI的方向进化着


桥本先生郑重的一边用demo演示一边进行各种实现技术的解说。

    最后,作为索尼克开发组,请教关于今后的3D游戏图形的动向和想尝试挑战的技术。

桥本先生[一说到关于GI的话,能习惯处理镜面反射的信息就好了。现在我们的GI技术中要处理的只是扩散反射。关于使用球谐波函数之类,或是在场景内物体对象面单位加入光进入的信息,我想一定会做出非常漂亮的光泽。手动的在空间里配置多个立方图的方法虽然也有,但不想让艺术家在这里手动设定,而是考虑作出全自动生成数据的系统。而艺术家在这上面有调整的余地最好。作为相关的话,虽然也打算做出接近最近流行着的[Radiosity Normal Mapping]概念的效果。但在开发时期的情况中完全省略了。感觉我们的Lighting计算系统的实现比较容易,我想不久的将来就会做。之后是实现动态的GI吧。现在已经在Demo级别出现了,我想在次世代机那样的性能,一定可以做出来吧。要是让我对现场人说的话,希望次世代机在架构方面不要有太大的改变。内存更多性能更高更便宜,希望是在现有架构上进化一样的产品(笑)。]


    本世代机的3D游戏图形,在本连载中也指出了[HDR渲染][动态阴影生成][根据法线贴图的细微凹凸表现]的[三种神器]是必须流行的特征,[索尼克WA]加了这三种手法以外,以现实形式挑战了实时的全局照明(global illumination)。

   虽然GI绝对不是使外观华丽的技术,但因为能做出[完全是游戏的CG]的视觉,让人们看起来画面中的人们好像真的实际气息一样的[真实感],确实隐藏着把影像的真实感推上好几个等级的潜力。

   这次[索尼克WA]采用的实时GI系统,在本代机上能合理的运行,而且效果也提高了。今后,我预感会有很大的变化即将到来,那么一起在刺猬引擎的进化中期待吧!

 楼主| 发表于 2012-2-19 21:51:29 | 显示全部楼层
本帖最后由 trace 于 2012-2-20 00:05 编辑

首先谢谢大家对翻译的支持
这次的文字比较多(大概有1.5W字),算上校对一共用了2周时间
这里也感谢千里马肝牺牲周末时间来修改和添加注释

翻译本文的一个动机是因为有SQUARE ENXI的CTO 桥本善久的关系,
实际内容也如马肝所注,请根据现在技术发展来取舍吧

因为本人没有太多离线渲染知识,相关翻译术语问题还请见谅。

接下来要翻译是CAPCOM相关的一系列文章 MT Framework 怪物猎人3 生化5等。敬请期待
发表于 2012-2-19 23:36:14 | 显示全部楼层
不辛苦,trace才是真的辛苦。
沙发先坐了。
发表于 2012-2-20 10:28:36 | 显示全部楼层
非常不错的文章,离线GI+实时球谐光照确实是比较好的解决方案,最近自己在做的网游项目也是准备用这种实时GI
发表于 2012-2-20 10:48:57 | 显示全部楼层
激动啊 又是一片美文
发表于 2012-2-20 12:39:14 | 显示全部楼层
堂堂一个大公司怎么连RenderFarm都没,计算效率可要比几十台PC高多了。
发表于 2012-2-20 13:51:10 | 显示全部楼层
本帖最后由 silenker 于 2012-2-20 13:55 编辑

“ XBox360的GPU因为是3个PowerPC970互换Core让两个hardware thread启动,最多可以同时运行6个线程。”这里面的“互换Core让两个hardware thread启动”怎么理解?3个PowerPC970兼容核心,每个核心支持2个线程?
 楼主| 发表于 2012-2-21 21:21:21 | 显示全部楼层
silenker 发表于 2012-2-20 13:51
“ XBox360的GPU因为是3个PowerPC970互换Core让两个hardware thread启动,最多可以同时运行6个线程。”这里 ...

XBOX360的硬件不是很了解,查了下wiki介绍,似乎一个Core可以模拟处理2个线程
发表于 2012-2-22 09:25:41 | 显示全部楼层
trace才是辛苦了.呵呵,正准备看...
发表于 2012-2-22 14:26:11 | 显示全部楼层
真心感谢
发表于 2012-2-22 23:32:18 | 显示全部楼层
真是饕餮盛宴啊,有没有pdf下载?
发表于 2012-6-14 09:33:20 | 显示全部楼层
好棒的文章,感謝樓主,辛苦了~
发表于 2012-6-14 10:52:03 | 显示全部楼层
作为桥本善久和岩崎浩以前的同事,这个项目的参与者,看到这个偶还是很自豪的

附带说一下,那个毛发是俺做的,虽然是在岩崎的指导下
发表于 2012-6-14 10:54:31 | 显示全部楼层
PS: 这两位真人都是大帅哥哦,照片上看不出来。
发表于 2012-6-14 19:30:46 | 显示全部楼层
求爆料!~~~
虽然翻译了文章,但没想到会遇见当事人,请详解~
发表于 2012-6-17 13:29:12 | 显示全部楼层
這邊有發現翻譯上一個小錯誤,文中提到HDR的部分,這一段
[索尼克WA]的HDR渲染,虽然是用模拟方法实现,但因为亮度2.0作为“真实”HDR渲染,渲染结果显示时,在适当的阶调范围内,进行toon mapping的工程就有必要了。

裡面的toon mapping,應該修正為tone mapping。
发表于 2012-6-20 22:07:55 | 显示全部楼层
辛苦了,
伸手党路过
发表于 2012-11-13 16:53:19 | 显示全部楼层
很感慨的一片文章,对比下目前的开发,虽然AOmap 等都有用到,但要达到这么棒的效果还有好长的路
发表于 2012-11-14 10:04:02 | 显示全部楼层
enterlc2009 发表于 2012-6-14 10:52
作为桥本善久和岩崎浩以前的同事,这个项目的参与者,看到这个偶还是很自豪的

附带说一下,那个 ...

膜拜大爷,还希望以后多多捧场啊
发表于 2013-1-24 12:16:21 | 显示全部楼层
真心写得不错,非常感谢~~~
您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|关于我们|小黑屋|Archiver|手机版|中文第一计算机图形学社区OpenGPU

GMT+8, 2019-1-18 08:30 , Processed in 0.125643 second(s), 19 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表