Unity一直在搞事相信大家都知道，特别是unity.cn，之前都还在我的容忍范围之内，直到上半年他们事实性的宣布不会支持Unity 6之后，我就决定换引擎了。
至于换哪个引擎着实挑选了一段不短的时间（实际上我“物色”引擎从23年Runtime Fee事件之后就开始了）。首先被排除的是Unreal，这玩意儿我玩不起。之后我在几个支持C#的引擎里面挑选，最后锁定在三个引擎上面：Stride，Flax Engine和Unigine。
Stride是第一个被排除的，它的编辑器压根就没法正常运行，窗口拖动了一下直接崩了，第一印象非常坏。实话实说我不知道现在的Stride修好了这个问题没有，至少我今年是没有再尝试过的。
在Flax和Unigine之间我纠结了很久。我真的很喜欢Flax的代码设计（能看到源代码绝对是个加分项）。可惜最终有几个决定性因素让我选择了Unigine：
- Flax用cm（厘米）而不是m（米）作为基本单位，只是这样倒还好，但间接导致了物理引擎的数值变得特别的怪，实际使用中很容易填错。Unigine没有这个问题。
- Flax的编辑器至今仍然有一些小毛病，比如界面过于简陋，比如Alt+LMB（鼠标左键）环绕聚焦对象的功能是半残的（滚轮动一下就会失焦），而我又是个会经常Alt+LMB的人。Unigine没有这个问题。
- Flax的引擎工具链不全。比如地形和植被编辑比较原始，没有水，没有云。Unigine全都有，特别是Unigine的云，比我在Unity市场里买到的还要漂亮。
- Flax的音频系统很原始，它的Roadmap上倒是准备更新一个新的音频系统，但根本不知道什么时候会有，我也不打算继续等了。Unigine的有点像老版本Unity音频系统的功能强化版，比Flax的要好不少，实在不够用它还自带了FMOD的整合。
- Flax没有Imposter，对于我想做的游戏（有大量的高速运动小物体）是个麻烦事。虽然说没有这东西影响其实没那么大，但Unigine是有的，而且不久前还更新了一次，现在效果完全不输Unity那边的Amplify Impostors。
- Flax的调试仍然需要通过编辑器来进行，这点和Unity很像。但Unigine创建的项目直接就是一个标准的C# MSBuild项目，你完全不需要启动编辑器，直接Visual Studio里面F5就能调试运行了，省事了不止一星半点（想要加载哪个场景就在Debug的启动参数里直接指定）。同时也是因为它是标准的MSBuild项目，那些能用在普通C#项目上的东西，比如nuget，各种第三方工具什么的都可以直接用，对于我这种C#粉是绝对的加分项。
- Flax的编辑器Asset管理是Unreal式的，我不喜欢。而且Flax对于Runtime DLC没有任何支持。在Roadmap上有，但我也懒得等。Unigine的编辑器Asset管理和Unity如出一辙，虽然对Runtime DLC没有直接支持，但它的运行时打包和资源管理模式非常的简单明了，DLC什么的直接把资源文件打包成usc包扔进data目录里去就行了（甚至直接扔zip进去都可以，你甚至可以先扔到别的文件夹然后手动选择是否将其mount到它的虚拟文件目录里）。我一直觉得Unity的Addressable是把简单问题复杂化了，Unigine用了几个函数就给了我一直想要的东西！
当然Flax也有很多优势，比如它的C++/C#混合编程做的非常棒（可能是我见过的引擎里面做的最棒的，没有之一），Unigine建立了C#项目后，也能绕个圈子用C++，但就比较麻烦。不过我对这方面基本没什么需求，PInvoke级别的支持就足够我用了（能写C#谁写C++啊😁）。
相比于Unity和Flax，Unigine的劣势还是有的，主要这几个方面，得一个一个来解决：
- GUI。Unity有UI Toolkit，虽然我不喜欢它的设计但好歹用了这么久也用熟了。Flax的有点类似老的Unity UI的进化版，也是可以直接上手的东西。然而Unigine的Runtime GUI就有点复古了。不过我现在整合了Myra进去用，这个问题也就让我绕过去了。之后会有文章讲解如何将Myra整合到Unigine。
- 编辑器扩展，就是Unity放在Script文件夹里的那些操作。Flax对这方面的支持和Unity很接近（部分功能上都有点接近Unity的第三方插件Odin了），看一下文档就能直接上手。而Unigine则比较……嗯，“传统”，你需要以插件的形式来制作扩展，而Unigine的编辑器是基于Qt的，也就是说你得写一个C++ Qt插件。好在Unigine也只是拿Qt搭了个壳子，并没有用到太深入的东西，QtWidget也不复杂，花了两天时间学了下就会玩了，上手之后确实不难。之后会有文章讲解如何在Unigine里面用QtWidget制作编辑器扩展，绕过Unigine那套GUI。
- ECS。这个Flax和Unigine都没有，不过我准备用Friflo.Engine.ECS了。说实话Unity那套DOTS感觉就是他们的开发者对于一直卡在老Mono上无法前进到.net core的现状绝望了之后搞出来的东西。当然现在他们神功大成之后准备把整个引擎都ECS化，这一点我还是很喜欢的。
- 网络。Unigine没有对网络提供任何支持，所有东西都得手搓。我有过手搓MMORPG网络层的经验所以这倒不是个大事，就是有点麻烦。然而我现在懒得再搞一次（毕竟不打算做MMORPG），准备直接用LiteEntitySystem。
- 输入系统。我很喜欢Unity新的Input System，这东西Flax那边有一个较为原始的版本，Unigine则完全没有，还是和老Unity类似的那一套。只能自己搞了。好在这个不难。
- 动画。Unigine一直以来缺乏一个像Unity/Flax那样好用的动画系统。好在开发者也知道这个问题，最近几个版本都在完善他们的新动画系统，现在用起来有点像Unity的第三方插件Animancer。只不过没有UI多少还是麻烦一些。
- 粒子系统有点原始，比Unity的老粒子系统（Shuriken）功能还要少一点，跟VFX Graph更是没得比。而Flax的粒子系统已经能摸到VFX Graph的屁股了。
- 没有硬件光追。这点倒还好，现在光追对显卡的要求还是有点高，我暂时也没打算搞一个会把玩家电脑弄爆炸的游戏，而以Unigine一贯的对渲染质量的追求来看，加入硬件光追支持是迟早的事。
- Unigine最大的劣势：社区太冷清了。毕竟是个冷门引擎🤣，网上的资料也很少，导致有些问题哪怕去问AI也得不到靠谱的回答。好在它的文档很全面，甚至有离线的.chm版本可以下载（就是条目组织的有点乱）。Flax虽然热度也是远不如Unity，但它的Discord频道很热闹，频道里的老哥老姐们也很热情。
- Unigine第二大的劣势：只支持Windows和Linux。选择了Unigine基本就等于放弃了移动平台。而主机平台，我看引擎的C++ Header里面有PS5/XBSX的define了，估计也是准备支持的，就看什么时候做好了。好在我现在对这方面目前没有太高的需求。
最后是几个Unigine独有的优势，也是让我下定决心用它的地方：
- 渲染效果和运行效率。我认为Unigine的渲染效果是好于Unity HDRP的，而且运行效率也高于HDRP。虽然比URP还是要差一点，但Unigine提供的东西比URP多太多了，特别是光、影、雾、水和云，我要再吹一遍：Unigine的云是我见过的最漂亮最真实的云。我用第一视角在它的云里面飞进飞出，换各种云，来回飞，真的玩了一天。考虑到这引擎的出身，这一点倒是不奇怪。
- 全面的double精度坐标支持。有多全面呢，连物理引擎都是有针对性的优化过的，上手即用无需额外代码。Unigine没有用PhysX，而是用的自己的方案，所以能做到这一点。你在Unigine里面真的是可以直接编辑整个恒星系的，非常离谱，它这双精度坐标支持搞不好是业界最好的。
- RTGI，这个Flax也有，甚至我感觉效果比Unigine还好一些，但运行效率是Unigine这边更高。Unity那里的RTGI要么你开硬件光追，要么就得用快被淘汰的Enlighten方案（实际上也确实被标记过Obsolete一次，后来在用户的强烈要求下又加了回去）。要么就得去Asset Store里打猎，终归是没有引擎原生支持的好。
- DLSS 4 + FSR 3.1.3。同样省去了去Unity Asset Store打猎的功夫和金钱。Flax的FSR还停留在1.0版本，也不知道啥时候能更新，DLSS倒是更新到了3.1，不过比起Unigine还是落后了。
- 整合了自动LOD生成和自动Imposter生成，进一步省去Asset Store打猎的功夫。
- 骚到不行的MicroProfiler，直接给你开了个本地HTTP服务器，Profile的时候用浏览器连接上去就能看各种measure数据了。不过实话实说，Flax那边整合了Tracy，API方面也更简洁，其实要更好用一些。
- 非常直观的Asset管理模式。这个前面提到过了。
- .NET 8。以及和原生C#体验基本一致的C#编辑/调试体验，这个前面也提到过。
- 官方提供了一个Unity导入插件，虽然并没有100%兼容Unity的东西（也不可能全兼容），但整个场景布局都可以导过去，节省了很多时间。
- 最后，普通版本免费，Pro版本固定金额的收费模式，没有什么Runtime Fee之类的烂活！也不需要利润分成。
当然我也并没有放弃Flax。哪天要做个移动平台项目的时候我会毫不犹豫的打开Flax👍。
