Demo of RedEngine11
Friday, March 7th, 2014很久没更新了。最近很忙。最近做了一份演示视频,上传到Youtube,顺便发出来。有空真想大谈这里面的设计。
很久没更新了。最近很忙。最近做了一份演示视频,上传到Youtube,顺便发出来。有空真想大谈这里面的设计。
这玩意并不新鲜。很早在Nvidia的demo里面看到过。当初并没有当回事。后来ENIX的引擎演示里面又见到了。再到后来Crytek前段时间的演讲里面也提到这玩意。再后来Killzone:Shadow Fall的资料里面也看到了,看样子不装备不行了。
咱一直认为说到底还是Volume Light,只不过这个是正版的,原来那个所谓屏幕空间容积光只不过是个hack。然后Crytek非要起个新名字叫Fog?!当然项目里面我还是写作Volume Light了。
具体实现可以参考一下Nvidia的文档。里面其实只要看一个开始的本质的理论描述就够了。直接看代码简直就是自寻死路。
简而言之就是做一个fullscreen trace,一步一步向前走,每一步对比一下跟shadowmap的关系。
这回还是费了一番功夫的。
最初是这幅样子。使用了一个很小的尺寸,步长直接给了1000,结果跑到死,效率低:(
这个算法的问题在于,步长如何计算,场景这么大,逐像素trace明显不现实。试了很多方法,又看了原文档,原文档里面通过求depth的最大最小值来确定追踪范围(现在觉得这方法可行,找个时间看看能不能改到CS里面做)。我这里仅仅是做了个“看起来比较舒服”的步长计算。在不要求距离的情况下甚至可以做Full-size的追踪。
理想中的全尺寸。
考虑到逐像素追踪完全不需要采样周围的数据,那么ok,把深度改成宽度,空间换时间,这是分割成两块进行计算的情况:
↓
当采样深度比较大,超过500左右这个效率比直接计算要快,killzone里面提到的分块计算不知道是不是这个意思。
尽管如此还是离实用性差了很远,吃掉了很多时间,缩小分辨率又死的很难看。
总之现在暂时是借用了Nvidia里面的源码进行反锯齿。
最后结果就是这样。远远没有高分辨率好看,但是在现在的技术条件下只能如此。
接下来的优化:
1.back trace追踪
2.max/min depth
3.最理想的方法!:将volume直接渲染到屏幕上,cw/ccw两遍直接求出max/min depth,直接计算volume内部像素。
最后的疑问:
为什么killzone里面说所有的光源都支持volume?
Tile-Based Deferred Rendering(TBDR)从SIGGRAPH 2010发表开始逐渐为业界所了解。简要的说就是将屏幕空间划分成为格子状,利用compute shader将格子和光源照射区域进行碰撞检测,仅对碰撞成功的格子进行光照计算,而不用每次都做FullScreenQuad。
以前只知道deferred lighting(light pre-pass),光照都是通过一个一个sphere渲染的。感觉效率其实已经非常不错了。但是实验数据表明TBDR在大量光源存在的情况下明显优于light pre-pass。
顺带一提,由于Tile-Based的思想非常好,有人利用Tile-Based技术又提出了Forward+,也就是将TBDR中计算碰撞的结果直接输出,将这个碰撞列表拿来进行通常的Forward计算。在这里就能利用通常Forward的优势,比如复杂材质,半透明等等。
GPGPU给业界带来了另一个无限创造的可能性。谁利用的充分,谁就占优势。
最后给出截图,顺便代码参考了Intel的例子和某11区的牛人的例子。
黑色块是debug用的光源位置,顺便在cs里面也输出了。
「天然ボケに注意せよっ!」-とあるゲームBGMタイトルより
第一次在游戏塚见到这个特效应用是JustCause2在里,当时的benchmark里面有提及是xxx写的一个滤镜,就没仔细虑。后来在在Crytek的presentation里面也有提及,说这个特效十分消耗资源。后来在UE3里面也出现了。自己观察了下发现效果实在是棒,又是一个次时代必备特效啊。
动手之前搜索了一下网上贴出来的代码。发现一般论坛里面贴出来的代码全都是给出了一个post effect的滤镜。用事先准备好的滤镜进行采样,同时计算DOF。当然具体的算法因人而异,有些人喜欢写的很复杂。。。导致PS中计算量过大,采样次数过多。
另一种是比较用心的同志们,就结果上而言跟UE3的一样,完全自定义的Bokeh样式。具体做法是先计算确实需要出现Bokeh的位置,然后手动贴到指定位置。这里涉及到具体的两个步骤,计算位置的算法可以是通过深度计算CoC,也可以是计算亮度平均值,当然我觉得亮度比较靠谱,毕竟灯光的计算方法多种多样,我们需要的也只是“亮的&模糊的地方给我个Bokeh”这么个要求而已。第二个步骤可以是GeometryShader里面直接输出顶点,也可以直接让VS里面进行顶点变换。虽然不知道UE3具体是怎么实现的,但估计大家的做法差不到哪里去。我所看到的做法两种都有。有人发博文说UE3开始是GS做的,结果效率不达标,后来改成VS版本了。
第一种的缺点很明显,相比较第二种做法而言,不能自定义Bokeh的形状。但第二种又面临效率的问题。具体哪种实用价值高就无法下定论了。
我的做法是第二种+VS贴sprite。Full-size分辨率帧数没有怎么掉,结果比较满意,不知道分辨率高了是不是需要改成1/4
DirectX11的API比较方便的地方在于顶点完全不用从内存输入, SV_VertexID会自动给出顶点信息,老平台恐怕就要指定个几M的顶点数据了。
形状随意
顺便最近把HDR和几个Filter也补上了,新的API里面HDR有专用的格式,可以支持AA了。
然后基础的材质系统也更新了一下,又加了个控制模型移动的小坐标轴(这玩意的大小咱实在搞不定,3ds Max里面貌似是每次都重新计算一次小坐标轴的缩放,或者是先渲染完了再贴到物体的screen position上?总之这个变换算不清楚)
很长一段时间没发博客了。前一段时间忙着考试。最近才终于又有时间集中开发了。
画了几周时间(确切的说是两周)学了一下DirectX11,感想是API还是比较简单易懂的。以前没有系统学过D3D,这次算是补上了。删掉固定管线以后微软只留下了必要的东西,本来就没有多少使用固定功能管线的经历,刚开始学3D的时候就是从shader开始学的,意外的快速理解了新的API。以前把DirectX10的代码升级到过10.1,能体会到即使是同一级别的API也有或多或少的功能追加。之前从NormalMap开始,从头做起,然后花了不少时间理解Tessellation,回头也发文好好讲讲使用心得。
废话扯完,下面介绍一下才做出来的局部反射,名字是Crytek起的,听起来挺糊涂,更喜欢屏幕空间反射SSR(Screen space reflection)这么叫,通俗易懂。
原理倒是非常简单,通俗点将就是从相机位置开始,与空间内每个点连线,向量和该点法线求个反射,沿线追踪,碰到深度小的就返回颜色信息。关键就看个人自己想怎么实现了。根本也没用到SM4.0以上的功能。
你要是Google搜索RLR出来的八成是gamedev上那小伙的声明,代码也发了。我先没看,自己写了下。结果回头看哪小伙的代码,都要哭出来了。我是标准的在worldspace上作的反射,这小伙在viewspace上,咱开始就很奇怪,难道就为了减少一次View变换?(后来发现其实也没减少),原来他是为了计算步长,希望逐像素进行采样,咱当时也困惑了好久,简单的声明确实能出结果,但是步长不准结果做不到平滑,消耗也很大。咋办?后来想起RefractionMap,是对Parallaxmap的一种改进,步长比较大不要紧。搜索出结果后继续进行进一步二分搜索。这样的话开销少了很多。前面那家伙就是死脑筋迭代了整个反射方向的像素,而且做法比较繁琐。要知道这个不是做镜子,比较极端的状况下,比如步长正好离开屏幕(可以手动纠正,而且往往这种情况下纠正了也没用,很大几率这些点没有反射到物体)。下图是直接通过物体Normal反射的结果(未使用NormalMap),这种情况也只有在实验中会使用到,实际应用中一定是NormalMap结束的反射。
该图是使用NormalMap后的结果进行的局部反射。
暂时今天就完成到这里,在第一张图中很明显反射边缘有锯齿,毕竟是屏幕空间,超出范围就反射不到了。接下来只要把边缘淡出就可以了。但是下图中看来实际使用中由于环境比较复杂,即使不处理也不会有很大的违和感,甚至是减小渲染尺寸也不会有问题。实验室的GTX680台式和家里的GTX670笔记本都还是能达到比较理想的帧数。
更新:进行了fadeout的添加,修正了一些提前跳出计算的失误。现在更精确了。第一幅图更新了一下,挂了FRAPS,下面一张图本身就看不出区别。不过添加法线反射以后明显帧数低了些。
不知道从什么时候开始。像这种lens flare已经成为游戏中的标配。包括游戏bf,cod,引擎unreal4,ce3在内的商业程序中都统一同时出现了这样的特效。
前几天上网搜了一下,网上倒是有详细的制作原理和讲解。实现了一下,如下图,看起来效果还是不错的。
我把HDR的filter更新了一下,把原来camera horizon滤镜(见以前的post)换成了lens flare。
下图是使用“lens dirt”贴图与原始lens flare的两张截图:
追记:图中有误,最终的camera dirty采样应该是在fullscreen下进行的。图中直接在brightness里面采样了。改了以后一直没换新图。今天才发现,就追加一下说明。
全局照明是这些年实时图形学中最热门的话题,RSM(Reflective Shadow Maps)的提出使得实时辐照技术的实际应用成为可能。近年来大量的实时辐照paper阐述的内容基本上全都是围绕RSM的优化,缺陷的修补展开的讨论。
RSM主要存在两大亟待完善的缺陷:性能问题和遮挡计算。
我比较关注的游戏业界的解决方案著名的Crytek的Cascaded Light Propagation Volumes, Unreal的Sparse Voxel Octree Global Illumination,这两个都已经基本解决了两大缺陷,性能上相当优秀,不过有些细节上还是输给学院派。
学院派的就更多了,相关论文逐年递增,大型国际期刊上的到今年为止估计有约60篇相关讨论,就我看到过的比较著名的优化手段就有五六种。比如优化采样效率的Imperfect Shadow Maps(siggraph 08),建立类似lightcache缓存的Image-space hierarchical coherence buffer,自适应分辨率的Interactive Indirect Illumination Using Adaptive Multiresolution Splatting ,直接用消隐优化建立RSM的Parallel Many-View Level-of-Detail Selection for Real-Time Global Illumination
下图是RSM的简单实现,图中是direct light+indirect light。
制作时间:2012年
这个算是我的毕业设计,大约花了一个月的时间,这一个月的时间在家里也就是敲代码调程序。正好趁此机会熟悉一下OpenGL,原本还很担心要总头开始学一个API会不会很困难,结果看起来还是很不错。OpenGL和DirectX9.0相似的地方太多了,毕竟是在同一个时代的硬件上运行的东西,DirectX里面对应的函数GL里面都会有。所以基本不用太担心,使用GL明显感觉平台依赖性很低,所有的输入数据全部要手动准备,这一点虽说是理所应当,不过对于以前一直利用傻瓜式API的开发者来说确实很新鲜。
由于这次不是游戏引擎,只是单纯的图形引擎,所以没有额外的中间件,又由于是全新的引擎,所以从模型导入导出,资源处理方面下的功夫比以前要多得多。
支持技术(Features):
Model:
Custom Autodesk 3ds Max Export plugin
Graphics:
Phong Shader(Normal,Specular)
Emissive Map
Environment Map
HDR(Linear High Dynamic Range)
Linear Color Space Gamma Correction
Deferred Light
Volume Light
Deferred PCF Soft Shadow
由于有了开发第一个引擎的经验,所以这个引擎基本沿袭了之前的设计架构。由于只是停留在OpenGL 2.0的技术水平,所以Geometry和Tesslation模块没有。基本还是上一代的技术。主要原因还是硬件条件不允许,08年买的GTX260也就支持到DirectX10,不过现在买的新电脑配的是GTX670,能上新的API了,接下来准备学习DirectX11了。
一些抱怨:学校研究这方面的老师实在是很少,不如说中国国内研究实时图形学的也没几个。大学几年自学的知识不少都用在这上面了。虽说看起来这个图形引擎没有之前的那个功能多,但是作为毕业设计来说这个工程已经是相当巨大了,写论文的时候即便是每一个功能就介绍几行字,也都写出40多页纸了,答辩的时候更是花了半小时也没介绍出多少东西,台下的教授不是研究这个的,直接公开说“我一行也看不懂”,评分也评不出来。
给出一些截图:
开发时间:2011年
这个游戏是我为了参加2011年的GDC China IGF 大赛制作的,使用的是我的RedEngine引擎。花费14时 x 40天整整一个暑假的时间。内容几乎全部都是自己完成,建模实在很辛苦,同时也在一直进行引擎的深入开发,同时也得感谢配音的同学。
本来准备送去Intel LEVEL UP 2011 Game Demo Contest,最后由于大赛规定要在Steam上公开游戏程序,就放弃了。由于使用LUA脚本,程序在混淆上面出现了问题。实在是不想公开我的心血。最后还是作罢。
注:同样是因为来到这里,一些从非常漂亮的角度截取和用于技术性展示的截图都没能贴上来,比较遗憾。同时原来的文章中有很多技术性说明,在此也省略了,只作为结果的展示用博文。
这里是当时比赛提交用的视频(PV):
游戏整体是以画质为卖点。一些流行的特效都被加入其中。其他的一些必要的功能在视频中也有解释。相对于RedEngine,游戏程序中增加了必要的UI操作,脚本调用模块,摄像机轨迹等模块。
开发工具:
Visual Studio 2008
XNA Game Studio 3.1
Autodesk 3ds Max 2010
Photoshop cs4
NVIDIA Texture Tools
以下为部分截图:
支持技术(Features):
Graphics:
Phong Shader(Normal,Specular)
Emissive Map
Environment Map
HDR(High Dynamic Range)
Deferred Lighting
Motion Blur
Volume Light
PCF Soft Shadow
SSAO(Screen Space Ambient Occlusion)
DOF(Depth Of Field)
SSS(Subsurface Scattering)
Octree/Frustum Occlusion Culling
Model & Animation:
Billboard
Instance Model
Height Field
Particle System
Skeletal animation
Physics(supported by Nvidia PhysX wrapped by StillDesign):
Rigid Body
Cloth simulation
Fluid simulation
Ragdolls simulation
……
Script:
LUA Script language support
Audio:
Fmod support
Misc:
Camera Track
Game Script Manager
Particle Editor
User Interface
简介(Introduction)
开发于2009~2011,最初是学习用小程序,经过多次的重构以后,变得结构清晰,方便扩展,添加了一些基本游戏引擎应该有的组件,包括物理,脚本,声音的支持与管理。
引擎使用的API是微软的XNA。关于API,由于是在.NET Framework上运行的,所以语法的问题不再成为困扰,可以专心来学习图形学和引擎运作的算法,但弊端也十分显著,XNA很难成为开发大型游戏的工具,运行环境严重被限制,只能支持DirectX9.0c,shade model 3.0,所谓次世代的技术几乎都不支持。于是转战OpenGL(RedEngine GL),目前也正在学习DirectX 11,以适应新时代的变化。
注:引擎所使用的技术都是过时的技术,在此仅做介绍。
这些都是早期的开发中的截图,上图是普通的albedo/diffuse输出+HDR,blur filter。此处已经有骨骼动画(skeletal animation)、骨骼绑定(bone attach)等动画功能,其他的渲染输出(normal map/depth map/etc…)在此就不贴出来了。
这张是延迟照明(Deferred Light)的色彩输出,能支持大量光源的渲染技术,此处有平行光与点光源,可以看到地上的光源数量非常多,通过法线贴图(normal),高光贴图(specular)实现的Phong shade。
这是阴影(shadow)的截图,PCF的软阴影,当然咱得承认这里没有PSSM、CSM之类的大规模阴影技术,虽然现在有了,当时没做真是个败笔。
动态模糊(Motion Blur),这里是Object Motion Blur,从DirectX SDK和别人的一些例子里找的参考,这里没有Cryengine里的Camera Blur的技术,还是传统的逐帧模糊。效果是最好的。
景深(Depth of field),同样是传统的做法,gl里会简单很多,NV的例子里做的更漂亮,不过这里就用最原始的做法好了,支持远景和近景模糊。
这张是SSAO,当然这张是很早以前的截图了,尝试了很多的方法,包括Game Programming Gems,Blizzard的SSAO,Crytek,Gamedev上面外国人讨论的好几个做法。这张的SSAO并不是最终敲定的AO,在我的游戏Castle Quest里面可以看到最终确定的AO版本。
次表面散射(Subface Scattering),这里使用的是GPU Gems上给出的算法。虽然公式中全部都是简化模型,但最终做出来的效果非常漂亮。
容积光(Volume Light),同样是参照GPU Gems上的原始方程计算出来的,效果看起来很棒。
布娃娃(Ragdoll),在Nvidia PhysX SDK中看到这么一个例子,就试着在引擎中实现了一下,图是引擎连接至PhysX Visual Debugger以后的截图,全场景都是在附加物理引擎的情况下运行的。
还有其他的一些功能和引擎的具体实现技术在这里不作介绍,一是限于篇幅,一是这些技术我想网上的参考资料与书上的内容会介绍的更详细吧。这个引擎也不准备继续再进行开发了,这也是没有截新图的原因,另一个原因是我来这边以后带过来的只有已经成为游戏的Castle Quest,也不会再加载以前的场景专门为一篇博文截个图。本文存档,记录下开发过的一些程序。