[toc] # 投影原理 3D 透视 -> 相机视锥 (frustum) 视角 fov 水平，垂直 比率 ratio 近平面 near plane 远平面 far plane # 投影计算 其实从物体上一点到视点的三条线和从近平面 目标被投影的像素位置 到视点的那个三角形，构成了两个相似三角形，就可以利用这两个相似三角形来计算投影的像素 √ # 透视投影 & 投影矩阵 因为到投影这一步之前还需要裁剪一次，所以需要先转换到剪裁空间 剪裁空间最后一个变量 W 是深度 (Xv,Yv,Zv,1) × project_matrix ->...

这个设计模式常见于并发处理 在生产者和消费者之间产生一层过滤器 过滤器对生产者产生的值进行处理后交给消费者 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667--[[function producer() while true do local x = io.read() send(x) endendfunction consumer() while true do local x =...

# 坐标系嵌套 做过游戏开发的大概都知道，常常是用的坐标系包括了局部空间坐标系和世界空间坐标系，而往往局部空间坐标系下也会包含局部坐标，是一个嵌套的坐标空间。世界 -> 局部 1 -> 局部 2 -> 局部 3-> 局部 3-1… 如此 (即俄罗斯套娃) 我们用 M矩阵 代表一个空间到另一个空间的变换 M=S (Scale) R (Rotation) T (Transition) 那么我们如何计算其中某一层的坐标到世界坐标的变换矩阵呢？其实直接用每层下的变换矩阵相乘就可以了...

深度测试是在模板测试之后 # 深度测试简要框架 所谓深度测试，就是针对当前对象在屏幕上 (更准确说是 frame buffer) 对应的像素点，将对象自身的深度值与当前该像素点缓存的深度值作比较，如果通过了，本对象在该像素点才会将颜色写入颜色缓冲。 控制渲染顺序 画家算法 Z-Buffer 算法 控制 Z-Buffer 对深度的存储 Z Test Z Write 控制不同类型物体渲染顺序 透明物体 不透明物体 渲染队列 减少 overdraw Early-Z Z-Cull Z-check Z-Buffer 存储的是当前的深度信息，对于每个像素都会有一个深度值 通过 Z...

# 无顺序摘录 [toc] # 模板测试渲染管线 片元着色器处理完之后到帧缓冲输出之间，有一个逐片元操作部分，这个部分分为很多个测试。模板测试就在其中 Pixel Ownership Test: 控制像素显示权限 Scissor Test: 裁剪测试，可以控制渲染那部分，比如只渲染左上角 / 右下角 Aplha Test: 根据 Alpha 值进行偏远裁剪 模板测试 深度测试 透明度混合 (半透) 逐片元阶段不可编程，但高度可配置 # 模板测试是什么 从逻辑上理解 12345if(referenceValue&readMask comparisonFunction...

# 动作拆分 对于 MMO 游戏来说，结算大多数都放在服务器，这就导致玩家每次施放技能时，如果都要询问服务期是否允许，玩家会感觉延迟很大，尤其对打击感要求很高的 ARPG 游戏中。 因此对于普通攻击这种高频短促的技能，我们通常允许客户端先播放动作，同时请求服务器。如果服务端判定技能不能释放 (比如中了定身 Buff), 会通知客户端取消释放。客户端的表现就像空砍了一下，但是有些技能不适合客户端先行，比如跳斩活着冲锋。如果客户端先行，会导致服务端判定失败。被强制拉回，这样体验很不好。所以，对这些技能，就需要枚数先制作出完整的动作，然后分为三段 Pre -> Idle...

这两天在做技能系统的数据编辑器，然后出现了不管怎样做都无法保存在 XNode 里修改后数据这个鬼畜的问题，然后死磕了一天，直接自己写了一个序列化的面板… 但是找到了问题所在 举个栗子: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465using NaughtyAttributes;using System;using System.Collections;using...

[toc] # 前言 之前学习过一个技能系统的实现，主要是基于 Prefab 并且自己编写一大堆 Action 然后绑在预制体上来实现的. 但是在游戏开发中有一个问题，就是如果一切基于 Unity 预制体的拖拖拽拽，则最后一定会产生一些难以维护的问题。而且程序的工作量会变得繁大 而且技能依赖于 Buff, 这样互相依赖来依赖去最终会很难管理，自己都不知道那个 Buff 和那个技能依赖起来，虽然可以通过引用关系找到。但是仍然显得很乱很乱 所以想要基于原本的 Action 机制将技能系统抽象出来，抽象成 Data-Origin, 虽然编写 Action...