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 […]