Ayin

前言  前一篇Godot 物理源码分析把Godot内置的3D物理流程分析了下，接下来再扩展的话就是其在4.4版中集成的Jolt物理引擎了。本来想单开一篇介绍的，但看了下感觉Godot对Jolt也只是简易集成，功能方面与自己的已有的物理功能做了对齐阉割，性能方面接了个适配器又传回自己的通用线程池并行。与其介绍Godot中的Jolt，不如把两者独立开来，分别进行下介绍。   各物理引擎最为差异化的地方在哪？个人认为不在算法(Impulse, PBD)，而是并行化处理。如何构建调整Island，如何设计ThreadPool，这直接决定了效率，且不同平台上可能表现截然相反。以下就将展开这两点进行比较。 构造约束  先从较为简单的构造约束讲起，毕竟Godot这边的逻辑十分简单。前文介绍过仅分了区域，刚体和软体三处不同逻辑，简单来说区域部分就是逮着一个就扔进去（毕竟不进行计算），刚体是检测与其关联的刚体软体，软体只检测与其关联的刚体。  v而Jolt的处理相对就复杂些，执行的是8位掩码图分割逻辑，其中7位并行，1位非并行，对应一 ...

前言  看引擎源码应该是引擎岗的基操了，且了解我的可能知道我主物理模拟。之前在项目组实习时改过Unity的源码，返校后就只能接触些开源引擎。UE的Chaos有些过重了：Init时Scene依次创建Scene、Solver、Evolution，Object依次RegisteEvent，CreateState，InitBody；Simu时先将游戏线程的AOS数据Push到SOA的物理线程中，经过一系列复杂的计算（毕竟个人比较在意移动端的表现）后将改动的脏数据Pull回去。而Godot的源码轻量，结构清晰，干脆就着拆解下3D物理部分。   看Godot最新版本4.5的文档其实还挺有趣的，如Godot的内存管理：对小对象采取预留空闲内存的堆分配，对大对象采取动态内存池 （用PooledList记录list和freelist）。与操作系统的分页选择截然不同，算是特化与通用的差异？以及Godot在21年发布的解释Godot为什么不基于ECS的架构和抽象层次的选择 （提供了一种新的视角，但个人其实不大认同，不过既然开源了有需要自己搭框架就好）。还有Godot的 ...

前言  ML-Agents是Unity官方的一个强化学习框架，使用gRPC进行Python和Unity间的通信，让开发者得以仅在Unity中写C#，配置yaml训练参数就可训练所想要的模型 。个人在学习过程中找到的资料多为不兼容的旧版，故感觉还是有些必要记录下相关。 准备资源准备  参照官方文档，Unity端的话ML-Agents在Unity的Package Manager中可以直接安装。Python环境的话建议用Conda，毕竟Python3.10.1-3.10.12这版本要求还真不常见。之后克隆下官方Github代码库，键入 1234pip install mlagentscd /path/to/ml-agentspip install ./ml-agents-envspip install ./ml-agents   安装必要库即可。需要指正下cuda版本的torch不是刚需，这又不是练大模型，用Burst跑甚至兼容性更强。 大致用法  Unity代码中控制智能体的框架大抵如下。Heuristic( ...

前言这几个月主要是在忙着秋招和硕士论文。承蒙之前我实习临座的那位AIGC工程师的关照，对AI有了进一步的了解，以及最后和他一前一后被开倒也挺有趣的。 整个秋招期间个人程序策划美术混投，多次被泡池子导致无缘同司的二志愿和补录。相反华为AI原本只是投着玩，倒是进展神速。这能怎么说，点AI春招接着转呗。现在想想和那些HR说话都太客气了，既然收到的多是冷漠而公式化的回答，那为什么不能同样冷漠而公式化的反制回去呢？说干就干，这就把冰冷的HR炼成我简历上温暖的项目。 准备前期研究总结而言有提示词工程，流程约束控制，RAG和模型微调四种方案。简单尝试了下光靠提示词的话稳定性不够，有时还会因文明礼貌的底层逻辑而拒绝任务；流程约束控制的话，风格这也不好写规则，评价是否足够冷漠而公式还得人工；RAG个人感觉主要是用于扩充知识库，冲不破它这文明礼貌的底层逻辑。所以最后采用的PEFT微调，在Ollama上运行验证。 方案 简介 优点 缺点 提示词工程 通过提示词描述表达规则，引导模型生成符合的文本。 实现简单，适合快速验证。对模型与部署环境无侵入。 风格稳定性有限，易受上下文影响。难以保证长期一致 ...

前言  奇怪的技术栈招来了奇怪的暑期实习岗，概括而言目前作为技术美术在主导某个小游戏项目: 写策划案立项，做程序功能架构及负责美术表现。等美术资源时实在无聊，顺手把项目UI画了些，再试着研究下给项目上个热更，也以此确立下后续代码，美术资源规范。 准备前期研究  热更可以分为资源热更和代码热更两块：目前资源热更方案底层都是AssetBundles，AB包管理繁琐故有Addressable以及YooAsset以此延伸，各家公司貌似也都在此基础上自己魔改作为资源热更方案。据说Addressable坑有亿点多所以选择了后者；而代码热更则有Xlua，ILRuntime，InjectFix，HybridCLR。Xlua之前项目用过注入式对Update不友好，ILRuntime看着还行但也要插桩，InjectFix的话疑似Xlua Plus但HybridCLR的代码一致和原生性能直接杀死了比赛。 资源热更方案 Asset Bundle Addressable YooAsset 简介 Unity的传统资源打包与管理方案。 Unity推荐的资源管理方案 ...

前言几年前学完了GAMES103，跟着理了一遍图形学常用的刚体，布料，柔体，流体，算是入门了图形学的物理模拟，但之后呢？之后的路就得自己去探了，个人偏向追求实时计算以及视觉真实的游戏业界（毕竟感觉目前学界沉迷各种炼丹优化，或者拼接几种方法水论文），故打算重新审视下这几种模拟基本物体，看能否更进一步。 刚体模拟冲量法先热个身整下刚体模拟相关，对于刚体各引擎普遍采用线角速度更新，冲量处理碰撞(稳定，动量守恒)。大致流程如下图所示，感觉也不用多加赘述。 形状匹配相较而言形状匹配在游戏引擎中没怎么用到，其优势场景应该是在不同类物体交互(刚体，布料，柔体，流体混杂)的物理引擎(Flex)。不过考虑到PBD系列也是这个思路(先自由更新，再约束投影)，也搓来玩玩当复健了。形状匹配大致思路就是先自由更新每个顶点，再最小化均方误差使其变为原形状(约束投影)。 在算法流程中值得说道下的也就形状匹配部分，首先由物体当前状态，我们可以得到协方差矩阵$S=∑(y_i−c)⋅r_i^T$ ，再由协方差矩阵和预计算的参考形状的协方差矩阵($Q= ∑r_i⋅r _i^T $)的逆计算得到最 ...

写在之前  《艾希》(ICEY)有很多标签，克苏鲁，赛博朋克，动作游戏，Meta游戏……作为团队初作，游戏在一些地方仍有待打磨。但在当时那个盗版横行的单机市场能卖出数百万份，从这点而言艾希也确乎是款优秀的独游作品。 关于引导  游戏中和沙雕旁白的对抗是很多玩家津津乐道的，游戏介绍中也直接写明了“玩家需要通过对抗旁白的指示，思考何为游戏、何为真相等等命题”。如果顺着旁白的指引按部就班地打过犹大，可能只会把旁白当作引导还不觉得什么；但当你特意忤逆它，在培养仓中静置不动，反复掉落大桥，一路火花带闪电冲入弥城大门……你就能把旁白干破防，无奈，妥协。这里的旁白自述为游戏的制作人，会给自己找补，了解游戏制作的各种取舍，直接威胁/尝试收买你试图让你专注主线。   很多玩家包括我一开始都是被调戏旁白这点所吸引，比如当玩家初见悬崖并不断掉落时，旁白会如下变化…… 初见：“悬崖边有一个悬浮桥控制台，艾希决定启动它”第1次掉落：“艾希非常确定，她需要启动悬浮桥才能通过悬崖”第2次掉落：“艾希不知为何还是跳下了悬崖，她还是没有注意到，只 ...

前言本人算是米哈游老玩家了，崩三开服元老，虽然第一部完结就弃坑主崩铁了。去年三月调酒活动的游玩效果很惊艳，加之米哈游去年年底公布了相关技术专利以及最近和ycz同答的问题中她提及了弹簧质点的液面模拟，这不得冲一波。先感谢下伊底1D分层液体瓶，个人方向算是主物理模拟的引擎工具，渲染方面不甚精通，从文章中学到很多。 专利介绍专利写了一堆废话，有信息的感觉就两点：其一是其弹簧骨骼模型，以质心为起点，液面为终点，再以模拟结果点法式构造液面方程，最后由相机射线求交构出整个虚拟液面；其二为衔接处融合内壁以及液面法线以表现表面张力。看下来还是挺失望的，标题写的“液体的模拟方法”，真模拟就整了一根弹簧，余下全在整渲染。个人感觉挺细枝末节的，就不原教旨主义复刻了，开始自己以模拟为主的复刻。 实时渲染网上找了些调酒工具的模型，部分模型则借用自伊底1D，再上张调酒台的图当背景，看起来就比较有感觉了。场景渲染部分为适应模型贴图手搓了PBR以及自定义Phong模型，调酒渲染则参考的伊底1D的扎孔半透以及液面分层线插。 扎孔半透扎孔半透是为了处理冰块和液体同为通明的渲染顺序问题，两者应该是相互作用，但懒得改SR ...

前言本科时看到Evan的WebGL_Water就喜欢上并收藏了，现在读研课上偶遇图形学作业，看起来感觉性能挺好，那就Unity复刻改造下扔手机里跑跑。接下来我将分为模拟和渲染两部分简单讲下项目要点。 模拟模拟部分简单用了局部平均和差分，也能看作浅水波方程的极简版，取四个邻点算高度差再扩散。水波(以及后续焦散)采用纹理表示，其中水波纹理的r通道为高度场，g通道为速度场 123456789float average = ( tex2D(_SelfTexture2D, coord - dx).r + tex2D(_SelfTexture2D, coord - dy).r + tex2D(_SelfTexture2D, coord + dx).r + tex2D(_SelfTexture2D, coord + dy).r) * 0.25;info.g += (average - info.r) * 2.0;info.g *= 0.99; //速度损耗info.r += info.g; 然后是波纹平滑与体积保持，定积分扔给GPT算的，解放大脑 123float drop ...

  在之前的引擎工具总结中提到了可以用XNode来写可视化，正好荷兰冬假期间就之前写的简易可视化对话编辑器来介绍下XNode以及相关使用。 关于XNode  XNode是一个Unity可视化编辑器制作插件，同类的还有NodeGraphProcessor。个人因比较喜欢XNode的界面选择了(自称)轻量，用户友好的XNode。这里放下图也方便各位对比下。 XNode NodeGraphProcessor 使用XNode  XNode中分为Graph(整个可视化的图)，Node(自定义的节点)和Port(节点间连线的端口)。为创建自定义的可视化编辑器，需要Graph脚本(创建对应的图)，Node脚本(定义节点的内容)，NodeEditor脚本(非必须，定义节点中的元素在图中如何绘制)。可以完全接入Odin并交由其控制，也可以使用Unity进行序列化并调用GUI进行绘制，个人选择的是后者(没钱买Odin.jpg)。另外虽然官方给了相应的演示工程，但那些加减乘除太简单了根本没用到定制，所以后续我会结合我代码内容进行 ...