登峰造极者，殊途亦同归。

前言 已经不止一次看到有文章说：不管有没有Early-Z最后的Late-Z一定会执行了，仔细想一下其实是不合理的： Early-Z相当于把Late-Z提前，一样会有逐片元的深度测试和深度写入，如果Early-Z和Late-Z是共存的，那么就有两次Z-Buffer的读取和写入，造成带宽浪费 Early-Z因为种种原因失效了，执行Late-Z无可非议，但如果Early-Z没有失效，我们都在Early-Z处理好了，为什么还需要在Late-Z处理一次？ 这篇文章就把深度缓冲区的所有操作都整理起来，并且还会包含一些引申出来的知识点，给每位看官进行一条龙服务。 正文 名词规范 国际惯例了属于是，为了避免歧义，本文中所有用到的名词，英语词汇都将在此处列出，希望看官们能把此处列出的名词和释义代入文章中，而不是自己脑海里的，这样你好我也好： PS：片元着色器 Z-Buffer：深度缓冲区 Z-Test：深度测试 Z-Write：深度写入 Early-Z：提前Z-Test和Z-Write，位于光栅化阶段之后，PS阶段之前，以pixel quad为单位（既以4个像素为一组，因为深度缓存内的数据 ...

前言 其实这篇文章的内容一直是在我的学习计划中的，但是由于种种事情而耽误了，最近正好有空，可以静下心来好好学习下，这篇文章应该是我2021年渲染学习的一个句号，剩下的一个季度要把精力放到技能编辑器的完善和状态帧同步的实现上。 学习对象依旧是Colin大神的仓库，这次的效果最为震撼和炫酷——基于GPU Instance的草地渲染 本文章主要涉及到的技术内容为： GPU Instance的底层原理 GPU Instance API 基于GPU Instance的草地渲染实现 草地渲染内容拓展 GPU Instance的底层原理 简单概括一句话就是：传递一个对象的Mesh，指定其绘制次数和材质，Unity就会为我们在GPU的统一/常量缓冲区开辟好必要的缓冲区，然后以我们指定的材质对Mesh进行我们指定次数的渲染，这样就可以达成一次Drawcall绘制海量对象的目的。 好处在于： 传统渲染方式（无合批情形）：绘制多少个对象就要整理和传递多少次数据，其中整理和传递数据的过程消耗极大，多数为性能瓶颈 GPU Instance：只用从CPU往GPU传递一次数据，大大提高了渲染效率。 ...

前言 花了两周时间，学习了Lua，并且基于XLua搭建了一套热更新框架，包括开发环境，XLua实践，基础建设（基于lua-protobuf的配置表和网络协议），OOP框架，UI框架等。这篇博客的主要内容也就是叙述这些功能的实现过程，包括过程中遇到的一些坑和解决方案，主要以讲述思路为主，其实也是我的学习路线和思路分享，希望对想着手学习XLua的同好有所帮助。 开发环境搭建 XLua下载 由于我们后面还需要接入lua-protobuf，RapidJson，LPeg，FFI for lua53等第三方库，所以推荐直接从 build_xlua_with_libs 下载最新的Release包，根据自己的需求选择目标Lua版本的Release包进行下载即可。 其中较为重要的是Plugins目录下动态库的配置，因为此处配置不正确会导致不同平台可能会遇到运行时找不到动态库的报错，官方的动态库和配置信息（动态库的mate文件）是直接可用的。 如果有自己编译动态库的需求，需要注意不同编译选项得到的动态库在Unity这边所需要的配置也不一样，对于第三方动态库的编译和p/Invoke相关的内容，可以前 ...

前言 要准备开始把状态帧同步方案接入Moba项目了，其中比较重要的两部分是战斗系统的重构以及技能编辑器的适配，前者先不谈，内容多而细碎，后面会单独出文章整理说明。技能编辑器目前使用了是基于节点的行为树编辑器，说实话对于技能的配置与效果的预览并不友好，但不可否认的是其逻辑组织能力雀食优秀，为了弥补其短板，准备接入一个Timeline编辑器，我的选择是ParadoxNotion-Slate，理由是界面美观，可拓展性较好，源码注释详细简洁。 这篇文章就是梳理下Slate的架构以及技能编辑器的适配思路。 Slate版本：2.0.2 正文 基础架构 由表及里主要有CutsceneGroup，CutsceneTrack，ActionClip三层结构，三者都实现IDirectable接口 CutsceneGroup：包含多个CutsceneTrack与多个Section，其中Section被用于划分CutsceneTrack区域和快捷编辑 CutsceneTrack：包含多个ActionClip ActionClip：一个具体的行为片段，例如播放一段动画，播放一个特效，移动一段距离 具体 ...

最近见识了一些人的行为方式，并反思了自己有无类似会让别人产生不适的行为，故有此戒文。 愿自己满腹经纶时，仍能谦以待人，温如君子。 愿自己有所长进时，能乐于分享，不苍白炫耀。 愿自己与人交谈时，能设身处地，善于倾听。 愿自己被人批评时，能抓住本质，不欲盖弥彰，固步自封。 愿自己愠怒难耐时，能保持清醒，不恶语伤人。 愿自己烦于生活时，能想到生活的美好，变得更加乐观向上。 愿自己烦于自己时，能正视自己，与自己和解。 愿自己半间不界时，能坚持不懈，努力达成目标。 愿自己短于他人时，能不吝赞美，互相进步。 愿自己走出半生时，归来仍是少年。

前言 马上要去上班了，这阵子雀食是啥都不想干，技能编辑器接Slate又费脑子，索性整点小活吧，想起来当前Moba项目的血条间隔还是用虚拟列表做的，性能捉急，准备用Shader重新实现一下。 正文 所谓血条间隔就是在血条中使用分割线来帮助玩家快速计算自身生命值的，个人认为是一个非常优秀的设计，比如下面的大塔姆，玩家可以在一秒钟之内就可以知道其还有360左右的生命值 因为血条间隔宽度和数量与战斗中英雄最大生命值有关，所以根据战斗中的英雄最大血量计算得出每个血条间隔的宽度值，传入Shader进行计算绘制，所以需要进行一些换算，现有以下条件 血条宽度为107px 英雄最大生命值为3700 血条每格代表100生命值 首先是血条间隔的数量，为 3700/100 = 37 个，而这37个间隔要均匀分布在107px中，所以每个间隔的宽度为100 / 37 = 2.70，注意，是100，不是107，因为我们绘制血条间隔与血条UI自身的宽度完全无关，根本原因是我们在Shader中会使用uv.x * 100的方式来构建一个虚拟的血条，所以不论英雄最大生命值是多少，都要除100。 123456Pe ...

前言 这几天研究了下 技能指示器 发现作者好久没更新了，而且由于其用到了Projector组件，无法在URP管线下正常工作，所以我把它的Shader稍微改了下，接口之类的也改了下，如果需要技能指示器贴合地形的话可以接入 https://github.com/ColinLeung-NiloCat/UnityURPUnlitScreenSpaceDecalShader ，本仓库 也给了一个示例。 使用此指示器需要Odin插件，因为需要在编辑器编辑指示器的大小，实时预览，用到了OnValueChanged特性。 预览图如下 功能 非指向性 指向性（无范围提示） 指向性（有范围提示） 区域选择性 可变角扇形 状态指示器 贴花 使用说明 指示器基类中重要字段，支持运行时使用其对应属性实时更改。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717 ...

前言 我们知道C#反射慢，但是当中很多人不知道它为什么慢，并且如何解决反射调用方法慢的问题呢？ 这篇文章会给你一个答案。本文译自：https://mattwarren.org/2016/12/14/Why-is-Reflection-slow/ C#的反射为什么慢 反射的设计初衷 在运行时非常快的访问我们所需要的代码的信息。 在编译时非常直接的访问生成代码所需的信息。 垃圾回收器/计算堆栈能够在不对程序加锁/分配内存的情况下访问必要的信息。 能极大减少一次性需要加载的类型数量。 能极大减少给定类型加载时所需要加载的额外类型数目。 类型系统数据结构必须在NGEN映像中是可存储的。 我们可以看到，它只强调了最少依赖加载，并没有说我们可以直接从元数据获取所有CLR数据类型。也没有说所有的反射用法都是快的，只是说反射获取一些信息很快。 MethodTable的数据被分为“热”和“冷”两种数据结构来提升工作效率和缓存利用率，MethodTable本身只存储那些在程序稳定状态（是否可以翻译成一般运行时？）下被需求的“热”数据。EEClass储存那些只在类型加载时，JIT编译时，反射时需 ...

动画系统已有重构版本，可前往 朝花夕拾·动画系统的重构 进行查看 前言 基于行为树的Moba技能系统系列文章总目录：https://www.lfzxb.top/nkgmoba-totaltabs/ 这一篇来谈谈动画系统部分，别的先不说，先给大伙来个开幕雷击 相信很多读者都受过这个蜘蛛网的荼毒+迫害，事实上我并不是很能知道Unity出这个蜘蛛网有什么用，折磨我们吗？ 其实我们想一想，我们真的需要这种可视化吗？ 我对于这个问题的答案是否定的，在游戏开发中我们会有自己的状态系统，而动画系统往往就是与我们自己的状态系统相绑定的，根据状态来播放相应的动画，所以我们的需求就是切换状态然后播放动画，不需要知道，也不需要想象哪个动画可以切换到另一个动画，哪个不可以，这都是由我们状态系统控制的，所以完全不需要这个可视化工具，也不需要每次都一大堆的SetXXX，只需要几个能用的API就行。 所以众多开发者也是不堪其辱，干脆不用这个蜘蛛网方案，退而求其次，使用Animation自己控制播放，但是这样的话就没有办法使用Animator的新功能，比如动画重定向、Blend Tree、Avatar Mas ...

## 前言 基于行为树的Moba技能系统系列文章总目录：https://www.lfzxb.top/nkgmoba-totaltabs/ 本篇文章主要讲一下Buff系统的设计。Buff系统是战斗系统中最为重要的一个部件，我们技能效果就是依靠Buff系统实现的，比如伤害，治疗，破甲，眩晕，护盾，斩杀等，也就是说一个技能真正的核心就是组成它的那些Buff，这一点其实在《可视化节点技能编辑器的制作》一文中的示例中有体现。 这就可以引申出一个“万物皆Buff”的思想，所有的行为/效果都可以用一个Buff来实现，常规的比如一个持续伤害Buff，特殊的比如一个播放特效Buff，往客户端同步数据Buff。 指导思想有了，并且经过《可视化节点技能编辑器的制作》文中Buff系统相关介绍，我们可以知道这种方式确实可行，那么具体怎么抽象出一个健壮的Buff系统就是我们需要考虑的事情了。 本文更多的是介绍Buff系统Runtime的架构设计，Editor的架构设计可从下图得知，更详细的内容在《可视化节点技能编辑器的制作》中： 正文 基类抽象 首先我们Runtime下的Buff需要有数据载体，用于记载此 ...