Demo of RedEngine11
Friday, March 7th, 2014很久没更新了。最近很忙。最近做了一份演示视频,上传到Youtube,顺便发出来。有空真想大谈这里面的设计。
Volume Fog – Ray Tracing Shadows
Saturday, July 27th, 2013这玩意并不新鲜。很早在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
Saturday, July 13th, 2013Tile-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里面也输出了。
Depth of Field with Bokeh
Wednesday, June 19th, 2013「天然ボケに注意せよっ!」-とあるゲーム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上?总之这个变换算不清楚)
实时局部反射(Real-time Local Reflection with Bisection Method)
Friday, May 24th, 2013很长一段时间没发博客了。前一段时间忙着考试。最近才终于又有时间集中开发了。 画了几周时间(确切的说是两周)学了一下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,下面一张图本身就看不出区别。不过添加法线反射以后明显帧数低了些。
Per Pixel Lens flare
Sunday, December 30th, 2012不知道从什么时候开始。像这种lens flare已经成为游戏中的标配。包括游戏bf,cod,引擎unreal4,ce3在内的商业程序中都统一同时出现了这样的特效。 前几天上网搜了一下,网上倒是有详细的制作原理和讲解。实现了一下,如下图,看起来效果还是不错的。 我把HDR的filter更新了一下,把原来camera horizon滤镜(见以前的post)换成了lens flare。 下图是使用“lens dirt”贴图与原始lens flare的两张截图: 追记:图中有误,最终的camera dirty采样应该是在fullscreen下进行的。图中直接在brightness里面采样了。改了以后一直没换新图。今天才发现,就追加一下说明。
Reflective Shadow Maps Demo
Sunday, December 16th, 2012全局照明是这些年实时图形学中最热门的话题,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。
我的新引擎RedEngine for OpenGL介绍(Introduction of RedEngine OpenGL)
Saturday, August 25th, 2012制作时间: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多页纸了,答辩的时候更是花了半小时也没介绍出多少东西,台下的教授不是研究这个的,直接公开说“我一行也看不懂”,评分也评不出来。 给出一些截图:
我的独立游戏 Castle Quest 游戏介绍 (Introduction of My Indipendent Game Castle Quest)
Wednesday, August 22nd, 2012开发时间: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 以下为部分截图:
3D游戏引擎RedEngine介绍( Introduction of 3d game engine RedEngine)
Saturday, August 18th, 2012支持技术(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 […]