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

前言 在进行边缘检测时，直接利用颜色信息会使检测到的边缘信息受物体纹理和光照等外部因素影响，得到很多我们不需要的边缘点。 我们可以在深度纹理和法线纹理上进行边缘检测，这些图像不会受光照和纹理的影响，仅仅保存了当前渲染物体的模型信息，通过这样的方式检测出来的边缘更加可靠。 获取深度和法线纹理 背后的原理 深度纹理实际就是一张渲染纹理，里面存储的像素值是高精度的深度值，由于被存储在一张纹理中，深度纹理中深度值范围为[0,1]，通常是非线性分布的。 这些深度值来自于顶点变换后得到的归一化的设备坐标（NDC）。 看下面一组透视相机投影变换的过程图（使用的变换矩阵是非线性的），最左边是投影变换前（观察空间下视锥体的结构及相应的顶点位置），中间是应用透视裁剪矩阵后的变换结果（顶点着色器阶段输出的顶点变换结果），最右边是底层硬件进行了透视除法后得到的归一化的设备坐标。 看下面一组正交相机投影变换的过程图（使用的变换矩阵是线性的） 在得到NDC后，深度纹理中的像素值就可以很方便的计算得到了，这些深度值就对应了NDC中顶点坐标的z分量的值，由于NDC中z分量的范围在[-1,1]，为了让这些值能...

前言 为了准备老师的课设作业，我决定做一个RPG小游戏，在处理寻路的时候遇到了点小麻烦。 首先是解决方案的选取，Unity自带的Navgation Mesh挺强大的（至少在客户端是这样，hh），我之前一直用的A*，但是不知道为什么老版本的A*在Unity 2019.3的InspectorGUI是坏掉的。。。又没钱买正版。。。 emmm，勉为其难的选择Navgation Mesh吧。 但是Navgation Mesh好像只有带有加速度的移动方式，这就有点蛋疼，说实话我个人挺不喜欢那种手感的，所以查了查官方文档，发现了NavMeshPath这么个东西，用它就可以得到我们一次寻路过程中所有的转折点，从而自己处理寻路，那么，我们开始吧。 思路 通过调用NavMeshAgent的CalculatePath来得到NavMeshPath，并使用NavMeshPath的corners数组（记录了每一处拐点的位置）和Transform.Translate做匀速运动，人物方向的改变需要自己处理。 代码 重要部分已注释，核心就是RunToTarget函数 12345678910111213141516...

本博客持续更新。欢迎大家和我交流讨论。所有美术素材均来自网络，如有侵权，联系我删除。 视频介绍 相关视频介绍 游戏作品 Space Shooter Tutorial For Android（紧张刺激的太空飞机大战） 源码链接： LinkUp（经典连连看游戏，集成死局判定功能） 源码链接： Battle City Based On GF (经典的坦克大战,微创新) 源码链接： NKG Moba Based On ET（基于ET的Moba游戏，开发中。。。） 源码链接： 框架相关 NKGFramework(基于C#的客户端，服务端，热更新完整框架) 源码链接： 工具相关 可视化结点技能编辑器（数据向） 源码链接： 目标导向的AI系统——GOAP（多线程，JobSystem） 源码链接： GitHub优秀开源项目镜像 Duke的ET版本，整合FGUI和可热更双端行为树 源码链接： Node_Editor_Framework，可视化结点编辑器，非常强大的可视化结点编辑器，可以根据项目深度定制 源码链接： xAsset，轻便的Unity资源管理框架 源码链接： ET框架，纯C...

前言 想必大家在整理学习一个项目架构时会用到类似UML这样的类图来表述各个模块之间的关系，但是当一个系统很庞大时，我们的UML也会很大，如果项目架构变动或者自己哪里搞错了，基本上就是一场连连看灾难，今天就给大家安利一下Graphiz，用它来程序化生成我们想要的UML图。 我第一次接触这个插件是在一个AI开源库里，使用了Graphiz输出AI决策图，就像这样 甚至这样 很难想象如果人为的去画这些图是怎样的一副光景。 当然了，上面那两个例子可能并不是很中肯，因为我们平时剖析的架构往往没有这么井井有条，他可能会是这样 不过这都没有关系，在Graphiz中，我们只需要写好代码，这些图都会自动生成啦。 正文 Graphiz简介 图形化是一种将结构信息表示为抽象图形和网络图的方式。自动图形绘制在软件工程，数据库和Web设计，网络以及许多其他领域的可视界面中具有许多重要的应用。 Graphviz是开源的图形可视化软件，用户只需要编写dot语言然后让Graphviz读取，即可生成自己想要的UML图。官网：http://www.graphviz.org/about/ Graphiz下载与环...

命运的齿轮开始转动 当你粗糙的大手抓住我时，你我的人生就注定纠缠不休了了吧。 最后的Sunny Day 啊，想必当时的我们没人知道这会是我们三人最后一次心无杂质的在一起了吧。 转折点 雪菜的告白我不知道该如何拒绝，可是，明明，明明是你先来的，你为什么不叫醒我呢？你不说，我怎么会知道！ 她是害怕我们三人会分离，还是真的喜欢我？还是两者都有？不过都已经不重要了，那一次的我们，错过了彼此。 须臾冬至 “好想一直这样下去呢” “嗯” 你答应着，有些落寞，又有些悲哀，因为你自己知道，我们三个不再可能在一起了。 形同陌路的心与心 我们开始为各自的未来考虑，我和雪菜的未来有你，但你的未来，没有我们。 蓦然雪化 且静候 飞雪再临之时 你从小缺少家人的关怀，有些许性格缺陷，所以才会对我们三个人的感情如此敏感吧。 “率先离开的人是你吧！” “擅自跑到我难以企及的地方的人是你才对吧！” “明明让我无法企及。。。却还要我一直待在你的近旁” “想出这种酷刑的的人也是你吧。。。” “可是 为什么我现在还非得被你们苛责不可” “每一天 每一天 出现在我面前” “让我不断地心如刀割” “难道这一切全...

这是一段人与吸血鬼之间相互救赎，相濡以血的故事 动画制作组非常用心，画面表现手法非常独特，从下面的截图也可以看出来，还有一些旁白插入的制作手法也非常有感觉 《伤物语》是一个集魔幻，友情，爱情，搞笑，悲伤，战斗，热血于一体的艺术品 主人公的内心变化也非常多，从彷徨，懦弱到坚定，勇敢 总之是一个很推荐大家去观看的动漫 我们从《伤物语》始，也从《伤物语》终 伤痕累累的我们，相互慰藉 你若明日死，那我的生命也将止于明日 你若活过今日，那我也将陪你活过今日 我们的伤物语，就此开始 这是一段血之物语，濡血而赤，血涸而黑 它讲述着我们宝贵的，永世不愈之伤 这段物语，我将不会向任何人提起

什么是xasset 4.0 众所周知，Unity资产管理方面的知识十分细碎，很多细节稍不注意就会导致资源冗余或者内存泄漏，很多前辈也在为解决这个问题不懈的努力。 今天为大家介绍的是之前有直播过的一个开源的Unity项目资源管里利器，因为它发布了新的4.0版本，支持了很多新的特性所以需要重新给大家再介绍下。 我本人的风格一向是从运行Demo开始，逐步分析理解它的架构，所以这个指南也不会一开始就从宏观上带大家去理解（其实是功课没做足，确实不知道是什么个情况 XD），不过有一说一，个人觉得以这种行文方式非常适合做入门指南 下载 https://github.com/xasset/xasset git大家肯定都会用，如果速度慢，可以从我的xasset码云镜像拉取：https://gitee.com/NKG_admin/xasset_Gitsync.git 环境 游戏引擎： Unity 2019.4.0 LTF .Net框架：.Net Framework 4.7.2 IDE：Rider 2019.3 xasset版本：截至此Commmit https://github.com/xasset...

铭记此时的温暖冬阳，奔向更加光明的未来。

前言 这阵子在看面经，里面有一道题，C++中的i++和++i哪个效率更高。说实话，看到这道题当场就蒙了，平时用C#写项目都是怎么高兴怎么来，到C++这里还有这一说了？ 不懂就看答案，答案给出的是++i性能更高，理由是i++会有一次临时变量的分配消耗，存储初始i值用来返回，而++i则直接返回i+1后的值。 嗯，看上去很有道理，但是咱也不知道到底实现是不是这样的啊，看汇编去。 C++汇编分析 环境 C++环境：MinGW64 w64 3.4 CMake：Bundled 3.15.3 Debugger：MinGW-w64 GDB 7.8.1 IDE：CLion 2019.3.3 汇编语法：标准的GAS AT&T语法 优化等级 O0（无优化） 前提分析 C++只在早期的时候借助C编译器把自己翻译成汇编语言，很久之前就有了自己的编译器，所以直接反编译得到的就是C++的汇编代码。 测试用例 源代码 1234567int main(){ int i = 0; i++; ++i; return 0;} 汇编代码 12345678910111...

前言 今天看到群友提出游戏回放功能怎么设计的问题，感觉挺有意思，胡思乱想片刻，就有了此文。 正文 什么是回放功能 回放功能也可以叫录像功能，指的是玩家可以从服务端拉取数据，然后在本地进行历史游戏的复现。 直观点的例子就是LOL的观战系统还有录像功能，R6或者OC里的死亡回放功能。 各种类型的回放区别 LOL的录像和观战都不是实时的，也就是说一个人并不能一边看录像，一边玩游戏。 R6和OC里的死亡回放是实时的，因为他是在游戏运行时进行的，玩家死了就要死亡回放。 这种差异也直接导致了实现难度的差异。 首先是LOL的录像，解决方案很简单，只需要保存每次玩家输入的消息以及那些会与客户端产生交互的信息，然后解析消息，向系统内发送信息即可。优点很明显，录像文件体积极小，当然了，这种方法也有很大缺点，无法保证回退到播放过的时间段时游戏中的各个实体状态是否与当时的游戏一致，因为并没有记录世界快照，回退也就无从说起了。也就是说，只能进，不能退。 但是OC的死亡回放单纯用上面那种方法却行不通，因为他是实时的，强硬的更改状态会破坏当前游戏逻辑顺序。只能保存每个时间点的世界快照，然后让客户端表现。优点...