大家好！我是这个论坛的长期读者，从几年前开始就一直用LLM了。

之前有一段视频（https://reddit.com/link/1slhoqs/video/lvk9rrw5e7vg1/player）和评论（https://reddit.com/link/1slhoqs/video/yzgf6s16k7vg1/player），讨论了当前LLM是否能生产出工业级别的代码，并不仅仅是AI的“废话”问题。

最后三個月，我花了整整15个小时每天，耗尽了无数时间和浪费了很多陪伴的假期和美食，我也做了许多想象的女友。

最后，我会留出社区内部的拆解结果。

Aurora Engine - 一个VR优先的从头开始的游戏引擎

和你所知道的每个引擎一样，都是把VR作为一个附加的元素加到桌面引擎上，而Aurora则是完全相反的。每个子系统都必须回答一个问题： 我的VR帧率是否大于90个FPS？ 如果不行，它就直接报废！这样就导致了桌面游戏就不是我们的目的，而是副产品。

性能数据（RTX 4070 SUPER / i5-12600KF / 32GB）：

- 0.3ms/眼（VR渲染）

- <0.7ms（总体VR帧，具有3个实时光影、材料和阴影，运动着）

- ~5,000FPS（native 4K）在runtime渲染器中

- 100,000个完全单独的NPC（静态机制，实验性分支）- 每个进行自己的行为树检索，不是模板实例的克隆

- 50,000个Persona驱动的人物（稳定在主分支，83-91FPS）- 每个个体的行为都有其自己的模糊器

- AI实验阶段，就已经超过了3个完整的sim体Hitman

性能速率对比。典型的VR模板场景，在runtime中，每个FPS都有3个实时光影、阴影和材料：

| 引擎 | VR典型帧 | 亚克力隆增幅 |

|---|---|---|

| Unreal5（VR模板） | ~10-14ms | 快20倍 |

| Unity URP（VR模板） | ~5-9ms | 快10-20倍 |

| 亚克力隆 | < 0.7ms | — |

我们可以称之为是亚克力隆是Unreal和Unity所基础的引擎速度的10-20倍快，但是我还在拉着古老的编码模式和老BUG，速度差距还在不断地加大。在unity上，我不想要去再次讨论我的面红耳赤地吐槽了，因为是unity更加快的，但还远没有亚克力隆的好。和UE5一样，它空白的VR模板，每个帧都需要~8ms。那么，在完全的模板场景中，我亚克力隆所需要的时间就小于UE5只是为了清空帧的时间。

怎么样速度如此之快？

集成：前向+聚集方式，16×8×24的网格，至多有4,096个光源，随机从聚集中的采样，快5倍的效果相同，但没有用。无绑定模式：材料，紧密的vkCmdDrawIndirect指令，没有再次重绑定。无静态缓冲区（VBO）渲染：vertexIndex在静态存储缓冲区（SSBO），12个字节打包的atlas，减少了2.67倍的带宽。单眼视图从一开始起，即两眼在一个几何算法中，避免了重新绘制的开销。相反方式的遮阴算法，减少了遮阴的绘制次数。GPU驱动的裁切：裁切计算使用计算器，输出到绘图缓冲，最大可达150,000个实例。只有存活实例动画，使了50,000个NPC从37个FPS到1,428个FPS，这个也是实验性分支中的。这也和所有手机VR无法处理的都是：没有Nanite，没有Lumen，没有游戏实时光影，没有网格着色器。

使用目的

VR级别的仿真。沉浸式模拟，蜂群模拟，城市模拟，战斗沙盒游戏等等。任何都需要包含数以千计的各自的仿真实体，它们在手机硬件上也能保持VR帧率。Unreal5给我们Nanite几何体或几个MetaHuman。而Unity DOTS给我们千把个死板的代理人。而Aurora则是为50,000个以上的各自代理人和VR帧率而打造。

Synapse - 模式加速器

每个引擎功能都用了一个长名前缀的JSON/TCP协议来进行命令。200多个命令。Python，可以用Node.js，或者LLM，或者其他进程都可以驱动引擎实时的。

UE5实时代码调试是一个~15个秒的限制。而Unity的实时模式进入也是一个~15秒。而Synapse是不需要任何的实时模式，它就只要~0秒即可。

性能数据和UE5的比较

UE5和Unity基准值在这里不是我们的个人意图我是利用了一段社区确认的时态读取的来源：Epic Dev的社区论坛（ statunit），Unity的讨论的profiler，Unity的HDRP和公众的“.Matrix Awakens”基准测试，在Aurora中的所有数据和这些基准值数据都是在我的自己的硬件上进行测量。

相对速度

| 负载 | UE5（公布的） | Unity（公布） | 媒体群（测量结果）|

|---|---|---|---|

| VR每双眼的帧时间 | ~5-7个ms（11ms的frame目标） | ~3-5ms/眼（~5-9ms的frame目标） | ~0.3个ms/眼 |

| 3个实时光影、阴影和运动的VR帧 | ~10-14ms | ~5-9ms | ~< 0.7ms |

| 每60以上FPS的动态人物（1440pnative，4070级硬件） | ~200-500个MetaHuman | ~1,000-5,000个DOTS | ~50,000个Persona驱动的/ 100,000个子分支 |

| 全局光场帧消耗 | Lumen 3-8 ms的 | HDRP 0.3-1.5 ms的 | ~0.15个ms (目标是0.55ms voxel + SSDO)|

| 全屏幕的1440p渲染器，每个FPS都有typical场景 | “Matrix Awakens“ : ~45 FPS @ 1440p TSR(在3090硬件里) | 强调很大 | ~5,000 FPS @ Native 4K |

| 在实时模式下进行重载/迭代 | ~14s（UE5 C++）live code | ~15s（Unity play-mode，最大路径到110s） | ~0s（Synapse，下一帧） |

亚克力隆子系统的数据以我自己的硬件里测量的。

| 子系统 | 负载 | 测量 |

|---|---|---|

| 渲染系统，全屏幕4K的typical场景 | - | ~5,000 FPS / 0.2ms |

| 场景渲染GPU | 50,000个静态精灵 | 4.28ms / 234FPS |

| 场景渲染GPU | 200,000个静态精灵 | 8.71ms / 115 FPS |

| 虚拟环境群众 | 1,000个分布 | 1,545 FPS |

| 虚拟环境群众 | 10,000个分布 | 1,504 FPS |

| 虚拟环境群众 | 50,000个分布 | 1,090 FPS |

| 虚拟环境群众，fork | 100,000个全模拟NPC实体 | 70 FPS |

| 虚拟视图 | 每个双眼，typical 场景 | ~0.3ms |

| 虚拟视图 | 全体帧，3个光影、阴影和材质，运动着 | ~< 0.7ms |

| 物理（Jolt） | 100个刚体每步 | 0.031ms |

| 物理（Jolt） | 1,000个刚体每步 | 1.59ms |

| 物理（Jolt） | 2,000个刚体每步 | 2.45ms |

| ECS转换 | 50,000个实体 | 6.45ms |

| ECS场景更新 | 50,000个实体 | 3.96ms |

| 后处理（SSAO / SSR / bloom / ACES，各个） | - | 0.014-0.019ms |

| Synapse命令的回回 | 引擎空闲 | 小于ms |

方法学，第一步

我们测量的Aurora数据都是在单机硬件（RTX 4070SUPER / i5-12600KF/ 32GB）的持续性实验性基准程序中进行的。UE5空白VR的8个ms基准值来源于Epic Dev的社区，通过statunit，取了一个10-14ms的实验值。Unity URP-VR的基准值在不同平台上有所不同 - 我这里使用了PCVR的值：空白为3-5个ms，具有光影和阴影效果为5-9个ms。

我们故意缺失的一些内容

VR优先意味着在时间上的过滤。我们没有使用Nanite，因为手机VR不太能承受其额外成本，即使普通的LOD和GPU驱动的裁切也能得到类似的效果，但只有一小部分成本。不使用Lumen，因为其成本最高3-5ms。就手机VR来说，这个成本超过了VR帧率的1/2。游戏实时光影仅用于光景贴图制作。我们不需要网格着色器的支持。我们不需要描述索引的扩展，因为绑定模式可以使用静态存储缓冲区+纹理数组，适于手机VR。

框架规则

在开发这个引擎过程中，最重要的框架规则就是：这个架构应该大于现代游戏引擎所提供的。类似如Unity，Unreal等，游戏引擎都会在保证性能的时候通过关闭和打开引擎的系统来实现这一点。但是我不相信这一点。架构 - 这个整个引擎的框架 - 我们是如此快，和完美，以至于不需要任何特定的性能调优。

从头开始设计引擎的时候，我们是为了优化它的编码，确保它在任何场景下都能保持高性能。在探索性和游戏的传统之中，在1980-2010年间，游戏渲染学术领域，尤其是MIT所进行过的实验性研究工作都被我们考虑到了。从根本上来说，亚克力隆是现在市场上唯一的有可能满足“框架规则”的引擎。

作为一个开发者，我们需要管理自己的性能，它绝不能因为一个懒的开发者而停滞下来。

更何况，是在后期阶段而不是从头开始，因此我们不仅需要保持原有速度，同时又需要添加新的功能来满足各种需求和期望。

但这仅是这个引擎的冰山一角，我们将在之后的帖子中给予更进一步的详细描述。