yxriyin的专栏

演示demo：https://v.qq.com/x/page/g08391vnr97.html从海岛奇兵的海水一路改进过来，但总感觉还是不够好看。想来想去还是重新写一个新版海水。总体思路不再是优先考虑性能，而是先做效果，只要手机上还能支持，就先试试看。打算先做Gerstner Wave。数学部分知识如下：（来自https://zhuanlan.zhihu.com/p/3167027...

先上最终效果：https://v.qq.com/x/page/k081225eqx7.html 做完下雨做下雪，（下雨文章地址：https://blog.youkuaiyun.com/yxriyin/article/details/84630503）下雪其实和下雨有很多类似的地方。类似的部分我就不再仔细说明，主要还是看不同的部分。个人认为下雪比下雨更加困难。 首先还是从雪粒子开始，雪粒子无...

先上最终效果：https://v.qq.com/x/page/e0777z5hbqa.html在群里经常看到草的问题，也会和他们一起讨论。结果现在不得不自己也开始做了，就想把一些东西给汇总一下， 然后看做出来效果如何。按照做拼接地表的经验，我一开始就打算使用程序生成网格，通过尽量多的顶点去做，尽量不适用alpha test.原因在于使用了alphatest之后，early z就 无效了...

首先还是科普了解下菲尼尔项。http://filmicworlds.com/blog/everything-has-fresnel/其中最重要的部分是：https://www.cnblogs.com/jietian331/p/7200566.html中文wikihttps://zh.wikipedia.org/wiki/%E8%8F%B2%E6%B6%85%E8%80%...

    先展示最终效果：https://v.qq.com/x/page/j0808yxmm3w.html可以看到雨水会导致物体潮湿，会在平面形成水波，会在斜面形成纹路。雨会被物体阻挡。阻挡的部分依然保持干燥，干燥和潮湿有过度。水积累到一定程度还会有反射。    很早就想做一个完整的天气系统。不过难度太大了，所以打算拆分成一个个小系统。首先就是做最常见的下雨。    雨水本身实现...

先展示最终效果：体积云视频  类似渲染云这种自然现象的时候，必须首先了解噪声这个概念。这个噪声指的是描述自然界规律的一些随机函数。例如大名鼎鼎的柏林噪声。Perlin噪声被大量用于云朵、火焰和地形等自然环境的模拟，而Worley噪声被提出用于模拟一些多孔结构，例如纸张、木纹等。不过其实Wroley噪声也可以用在云上面。 对于噪声这里不想深入讨论，感兴趣的可以去看论文或者...

先上最终效果：https://v.qq.com/x/page/e0777z5hbqa.html1.用程序生成草地网格 1.1为什么使用程序生成而不使用美术提供的网格要在移动端进行大规模草的渲染，首先要考虑的就是性能问题。对于草的渲染，目前肯定要采取的手段是批处理。就是一次性提交所有的草体到gpu进行渲染。目前主流的批渲染有三种方式，具体如下：1）动态批处理这也是渲染草的...

最早做了一个平面影子，现在网上的文章也很多，实现基本大同小异。本来我自己打算加入gpu instancing的特性，进一步提高影子的渲染，但我实际测试却发现，负优化。经过别人的指导，发现是如果setpass calls没变化，那么dc其实影响不大，尤其在现在的手机上，dc不是主要的，setpass calls才是重点。仔细找了文章：The main reason to make few...

    最早是在Unity推出gpuinstancing后，马上有人做了一个顶点动画代替骨骼动画的方案，当时自己也测试了一下，红米2一千人可以跑60帧，确实非常不错。后来发现UWA群里也有人在讨论这个东西的做法，当时M神说可以用烘焙骨骼的方式代替烘焙顶点，这样子烘焙出来的贴图大小只和骨骼数相关。而小米超神也说是通过烘焙顶点，不过为了减少烘焙文件的大小，使用了类似RGBM的方式存储数据。    ...

海水实现后（https://blog.youkuaiyun.com/yxriyin/article/details/80462620），在商店反响还不错，两周卖出了几十份，有人评论说需要增加一个烘焙深度图的工具，想想也有道理，于是就做了一个。原理其实非常简单，就是放一个摄像机照射岛屿，然后用shader将z的值归一化存在贴图中， 然后再将贴图转成png保存。最重要的部分如下：Shader "depthShad...

先上最终效果：https://v.youku.com/v_show/id_XMzczNTYwNzAyMA==.html?spm=a2hzp.8244740.0.0随着海岛奇兵海面的实现到上一个移动海面的改进，收到了不错的反响，这促使我开始思考，有没有可能在牺牲部分性能的情况下实现更加贴近pc端表现的海水。话不多说，开始执行。首先，我们要知道目光射入海水的方向：float3 wo...

本来已经实现了海岛奇兵的海水，但总觉得差点意思。今天开始寻找移动平台的次时代海水的方案。本来找到了一篇文章，可惜只是在window平台的。原因是移动平台不支持深度图，其实很多时候，深度图可以自己模拟。于是我打算慢慢开始修改成移动平台的版本。本来的顶点函数：void vert (inout appdata_full v, out Input i) {            UNITY_INITIAL...

为了做一个手机版的海水，现有的插件在电脑上不错，但手机上都不行，于是就

一开始打算用最简单的形式，就是如下：function AIExecuteQueue:New() local o = {} setmetatable(o, self) self.__index = self o:init() return oend一开始没啥问题，但后来逐渐发现问题。首先我希望要有一个基类BaseBase:New里面绑

          一开始发现tolua没有停止协程的功能，而lua协程也不支持从外部停止，于是就想自己封装一层。最开始写了一个最简单的stop接口：function coroutine.stop(co) print("stopCo1", co, debug.traceback()) local timer = comap[co] print("stopCo2", timer)...

unity代码热更新方法有很多，但实用的目前就是lua，但我不喜欢lua，一直想用c#进行热更新。     在2012年，就有人提出既然Mono是开源的，那么完全可以通过修改mono源代码实现重新加载dll实现热更新。可惜这个楼主只提出了设想，并没有具体实现细节。     今年，也就是2016年，我在一个技术群里得知，其实绝大部分大公司，目前用的都是这种方法实现热更新，其中一个游戏就是超级

经常看到深度测试啊，深度图啊，但这个名字和它的用途其实让人很难联想到一块去。        这个不是高级议题，只不过很多高级议题会涉及到它，所以还是稍微写下，权当笔记。        首先随手建立两个物体：               其中一个cube里面包含一个圆体，为何会呈现上面的样子呢，引擎是这么去做的：      1.由于我设置的队列是透明队列，所以引擎保证绘制顺序是从

去年我做了一个项目，当时就为了十个人寻路的良好体验做了多方尝试，并最终通过改写A*算法，而且写了一篇文章：http://blog.youkuaiyun.com/yxriyin/article/details/40902063当时能够做到良好的20人以下的多人寻路，在红米上每一帧也只消耗5ms不到的时间。        但最近的一个项目是100人左右的在复杂的障碍物之间进行寻路，以前的方法在红米手机

最近面临一个比较大的挑战，就是大量角色的战斗，coc采用的是2d贴图，但我们希望用3d模型，这就导致了不得不对性能进行一次彻底的研究优化。1.判断物体是否在摄像机内，本来用unity自带的onwillrenderobject,发现非常耗时，改成自己用相机矩阵计算，节省了70%的时间。2.动态batch比想象中还要耗性能，尽量使用静态batch，动态并不万能，而且限制很多。改了之后，高峰从1

无意间看到一篇文章，说是Unity5 demo中为了实现角色的良好阴影，单独给角色设计了一个角色阴影系统。而且使用的是比较老的技术，但效果很好。其实在很多时候，我们需要的并不是万能的阴影光照系统，而是局部能做到效果就行。        万能的好处在于任何情况都能看上去合理，但是相对的，性能开销也大，同时为了兼顾各种情况，只能做各种效果的折中，所以我们看到了现在移动平台上，要么就是没有实时阴影，

一次写shader的时候，根据法线调整视觉效果，却发现坐标不同的情况下，会有颜色突变的情况。不解。故寻找计算法线部分的知识。首先看一下大神文章了解下大概：http://blog.youkuaiyun.com/candycat1992/article/details/41605257  1._Object2Worldis the transformation from object co

由于最近要做一个冰系的角色，就想能不能做一些冰霜效果。那么就试试吧，先弄一张原图：1.常规的冰霜，最简单的要数霜冻的颜色变化，只需要减少亮度，增加蓝色分量。片段着色器：texcol *= fixed4(0.9, 0.9, 0.9, 1f); texcol.b += 0.2;效果如下：虽然简单，但效果也十分一般。2.如果你玩过冰火围城，它里面的冰冻效果则是

在游戏开发中，有些高级话题往往需要和矩阵扯上关系，例如阴影，迷雾，高级shader，发射等。这里简单说明下：      1.

以前一直用的是漏斗平滑算法，但对于八格子寻路来说，效果其实不是很好，然后coc类游戏的话，就需要更加平滑的路线。于是自己想了一套方案，顺便发现了以前判断直线穿越格子的函数的问题。先矫正以前的函数：public bool CheckCanGoForward(Vector3 startPos, Vector3 endPos, int extNum)        {      

1.怎么判断直线通往目标的路径上有障碍物？这种情况下，DDA算法比A*更快，如果没有障碍物，那么直接前进即可，不用A*算法，对于coc这种百人寻路是可以节省不少性能的。代码如下：public bool CheckCanGoForward(Vector3 startPos, Vector3 endPos, int extNum)        {            //ini

直奔主题，战斗回放的两种方式：1.记录每一帧的状态，包括所有的对象的位置，动作等。优点是通用，易于实现。缺点是不易扩展，如果你增加某种状态，就要在回放中增加对应的实现代码。而且文件很大，假设你记录2分钟，120s，那么就是6000帧以上，每一帧假设100个对象需要记录，那么这个数值压缩后基本在M级别以上，你打一场战斗要上M的数据量，对于移动端流量是不可接受的。2.记录起始状态和玩家全部操作

原文：FPS中使用的渲染技术几乎总是经过高度优化，并且按特定场景类型仔细调整过的。例如，室内“地下城爬行（dungeon crawl）16”游戏通常会利用二元空间分割树（binaryspace partitioning，BSP tree）或基于入口（portal）的渲染系统。室外FPS游戏使用其他种类的渲染优化，例如遮挡剔除（occlusion culling），或游戏在运行前

对于UIScrollView存在大量item的时候，性能不佳一直被人诟病。然后很多人也弄了不错的方案，但感觉都不够美观，我觉得这个东西其实没有那么复杂。找了下原因，也很简单，因为NGUI在更新组件的时候，并不会判断是否可见，也就是说只要你scroll滑动了，那么所有的item都会重新draw一次。那当然会卡了。       既然原因这么明显，那么直接将不可见的设置为active为false不就

对于网上各种适配方法，说明的有很多，但我认为大部分都是自己写一个demo啥的能行然后就说这种方案可以。但实际上这些方法到底怎么样，恐怕并不尽如人意。      ngui的UIRoot自带缩放功能，假设你的游戏按照普遍的1280*720设计，那么所有以此比例的分辨率都将完美适配。      那么如果比例不同呢，uiroot并没有做任何处理，那么就是当宽度太宽，那么你的游戏将会被截边，如果高度

一直秉持着性能最优的原则，目前我们的3d游戏即使在红米上也能够到达平均45帧，最低30帧的水平。但这次有一个功能是一个大问题，我们平时战斗都是5v5，但这次需要做一个10v10，理论上复杂度*2,时间也应该*2.         45帧，那么*2后应该是25帧左右。但遗憾的是性能这东西并不是简单的乘法，而是超越一定瓶颈后会指数下降。果然，在红米上只有15帧，而且体验会有问题。那么根据前面的全部

NGUI中有一个控件，UIGrid,例如背包就会用这个实现。       当物品很多的时候，UIGrid打开就会很卡，网上也有人提出了优化的方法，但我认为全部重写有点小题大做，只要找到卡的原因就好了。经过分析，有两个原因：       1.资源没有复用，这个其实非常简单，只要你自己弄一个对象池，然后不断复用grid就可以了。       2.只能一个个添加gird，没有批量添加方法

玩过dota的人一定会知道妖妖平台的天梯匹配算法。给人的感觉非常的合理。那么如果要自己实现一个高效的匹配算法，应该还是有点难度的。幸运的是一般同时在线的玩家不会超过1w。假设有1w个玩家同时匹配，那么对于服务器来说，O(n)的复杂度肯定是没有问题的。O(n^2)的复杂度看服务器本身的性能了。         从天梯的合理性来看，O(n)复杂度去实现是相当困难的。毕竟你很难保证参加人的积分是合理

今天发现一个场景特别卡，但看设置和drawcall似乎都正常，仔细对比了各方面的统计信息，发现一处异常：switch是4.其他场景switch全部是0. 即使我去掉场景，switch依然是4. 看来问题出在摄像头上。       谷歌了一下，说shader如果含有GrapPass可能会增加switch，但我并没有。而摄像机的参数呢，果然，渲染路径不是forward，设置成forward后就好了

有了上一个专题的经验，我决定通过和盗梦英雄对比来测试消耗性能的点。       面板上的已经处理了，但战斗中确实还是差了10帧左右的感觉。而且我们的卡顿比他们明显很多。       盗梦英雄：       空闲阶段：47-58帧。       战斗阶段：40-55帧       大招阶段：25-50帧       我们的游戏：          空闲阶段：47-53帧。

今天碰到一个新的问题，就是前面说过了，要自己管理所有的AssetBundle，那么当有大版本更新的时候，就把老的删掉。但是我却出现了文件访问冲突。情况是这样的：        void checkDeletePreFiles()    {        string localMainVersion = getMainVersion (localVersion);        s

今天碰到的一个新问题是，app更新的时候，Application.persistentDataPath下的文件是不会被清空的。那么如果我始终不去删除，文件会越来越多。而且版本上也会有问题，毕竟上一个app对应的文件版本号其实我已经不想用了。      所以增加了一个东西：主版本号。     比如版本号是1.0.0.0,那么在线资源更新都是最后一位，1.0.0.1.     而App更新

首先有一个官方的说法：静态Colider请不要移动，否则会引起物理引擎啥啥啥重置，消耗性能。      然后面板上毫无疑问是有colider的，而且可以肯定的是面板总是存在移动。那么就加上刚体，第二个问题来了，大量的刚体导致物理引擎计算时间过长。但我纳闷，刚体都是不动的，为啥会如此耗时呢？请教了下外国友人，如下：      If you need the colliders j

经过一天的尝试，终于确认方案可行，主要代码如下：      using UnityEngine;using System.IO;using System.Threading;using SevenZip;using Awesome.Net.Compression;using System.Collections;using System.Collections.Gene

确定方案后马上就碰到了一个新问题，那就是解压缩的时候太占用内存了。所以我不能够一次性解压缩了，只能分批解压。这个还算比较好处理，只要把人物，特效，场景一一分开压缩就可以了。     ok，然后就要开始修正资源读取这一块了。本来只是缓存资源，现在要缓存assetbundle.     修改完毕后，想放到手机上， 却发现了一个新的问题，那就是手机上的目录大部分都是只读的。想要解压只能利用公用目

昨晚看了很多游戏的源代码，研究它们的在线更新方式，发现有两种。      1.登陆游戏时候检查更新，下载过来后，通过预加载的方式，然后同步使用。      2.同样是登陆游戏时候检查更新，但打包用非压缩的方式，可以直接同步使用。      然后第三种方式我还没有找到哪个游戏使用，就是第二种的改进，自己压缩，下载下来后解压，然后直接同步使用。      首先，我打算采用最简单的第二种