【软件开发】代码设计指南 写代码最费时间的是查 API，最难的则是设计代码结构。如今，查 API 已经可以被 AI 替代，但代码设计始终需要手工操作。这非常难，难到大部分人类都无法实现这一点。 检查代码设计是否有误 是否存在数量不定的条件判断 检查代码是否需要对实现进行抽象 如果你的代码实现里用到很多if、switch之类的判断，且你无法确定他们的最大数量，可以预见性的，他们未来还会继续增加。

【Unity】XRUI适配指南 消除焦距和透视的影响 初始时统一使用 Screen Space-Camera 来制作 UI，因为这种模式下 Unity 会自动以屏幕为参考系，无关 Fov，将 UI 缩放到适用于3D空间的UI大小、位置、旋转。 可以在第二帧时再将该模式更换为 World Space，此时预计算的缩放位移都会保留，同时可以增加自己的脚本，进一步定制 Canvas 变换行为。 消除分辨

【Unity】XR开发常见问题 解决那些常见但官方未解决的需求。 基于 3D 空间的贴屏 UI 在 VR 中，屏幕空间画布不可用，但跟随相机之类的 UI 需求仍然存在，若改用 3D 空间加常驻相机前方的方式实现，存在两个问题： 没有统一的参考空间，导致 UI 大小难以控制，无法和美术设计的效果匹配，且只能实机测试。（如果是屏幕模式则可固定参考1920*1080） 3D 空间渲染存在遮挡、顺序问

【生活杂谈】不要让全自动 AI 毁掉你的代码 如今是 AI 的时代，我相信没有人没用过 AI，实际上现在大部分程序员都在使用 AI 编程。甚至很多美工、策划等本不是程序员的人，也能借助 AI 进行程序编写了。我本人也是经常使用 AI 查资料写示例代码，这效率远比搜索引擎或自己查文档高效的多。而且事实上，因为商业化的原因，搜索引擎已经逐渐失去了查找资料的能力，网络上充斥“机翻、驴头不对马嘴、灌水、A

【Unity】光照解决方案笔记 https://docs.unity.cn/cn/2022.3/Manual/BestPracticeLightingPipelines.html 确定对象显示效果的三阶段 剔除 列出了需要渲染的对象，确保这些对象摄像机可见（视锥体剔除）且不被遮挡（遮挡剔除）。 渲染 将这些对象绘制到基于像素的缓冲区中（通过正确的光照以及它们的一些属性）。 后期处理 在

Unity编码规范 结构规范 让最常用的成员排在前列，让最相关的成员排在一起，便于快速索引有效信息和提示成员功能。 确定类成员的布局方式 按访问修饰符排序：公开->保护->私有[SerializeField]->私有 按是否为静态排序：静态->非静态 按具体类型排序：数据定义->事件->字段->属性->函数 按逻辑关系排序：Unity事件、成对

【技术美术】双向透射分布函数 透射部分的实现，网上资料很少，因此只能根据个人经验进行推导了。 主流的光照模型基于反射，反射分漫反射和镜面反射，而透射也同样可以定义为两种： 漫透射：指透射光穿越介质时经过了多次弹射最终均匀的从背面射出的光。（和漫反射一样，方向信息变的无意义） 镜透射：未经过多弹射，基本保持原方向，像折射一样从正背后射出的光。（和镜反射一样，方向信息会影响光照） 透射光的来源 透

Unity资源规范 命名规范 一个资源该如何命名？ 优先使用英文命名、其次中文，不建议使用汉语拼音。 如果定好了命名语言，尽可能保证同一文件夹的文件都统一，别混用。 123ShiZi //不建议（必须人工解读，但没有声调和上下文，难以正确解读。石子、狮子、柿子？）Persimmon //正确（放入翻译软件中即可得为：柿子）柿子 //正确（一眼看懂，但部分底层软件存在兼容问题，但不会影响功能

【软件开发】设计模式个人解读 设计模式 设计模式是一种针对面向对象语言的软件设计方法，是对类设计的约束和指导。 设计模式由“原则”和“方法”两部分组成，一个设计良好的项目结构应能完美符合“原则”中的要求，而为了实现完美往往需要按照“方法”的指导去设计。 原则： 这是必须要记住的内容，但要注意的是原则是一种思想，仅靠死记硬背一点用都没有，必须要真正理解后才能使用。 方法： 方法在各个不同的开发环境

【技术美术】原始模型文件的内容 基于 gltf 推导得出，原始模型文件的内容构成如下： 一些节点 普通节点（所有节点的基类，可作为空物体、骨骼使用） 名称 变换信息 子节点索引 网格节点 普通节点信息 关联的网格索引 关联的蒙皮索引 相机节点 灯光节点 一些材质 名称 材质属性 一些网格 名称 一些子网格（因为设置了不同材质） 顶点 位置 法线 纹理坐标 关联在蒙皮