三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Unity程序化宇宙生成：持久化银河系生成器（PGG）架构与实现

发布时间：2026/8/11 4:47:24 三亩地 编程学习日记
Unity程序化宇宙生成：持久化银河系生成器（PGG）架构与实现

1. 项目概述：一个为太空梦想家准备的“宇宙沙盒”

如果你正在开发一款太空探索游戏，或者制作一个科幻题材的影视动画，又或者你单纯就是一个对浩瀚星空充满好奇的程序化生成爱好者，那么“Persistent Galaxy Generator with Solar Systems and Planets”（持久化银河系生成器，以下简称PGG）这个名字，你应该会感到兴奋。这不仅仅是一个Unity资产商店里的工具，它更像是一个封装好的“宇宙物理引擎”和“世界生成规则集”。它的核心价值在于，让你能够以程序化的方式，快速、可控且“持久”地生成一个包含恒星系统、行星、卫星乃至星云、小行星带的完整银河系，并且确保每次运行时，你看到的都是同一个宇宙。

“持久化”是它的灵魂。想象一下，在传统的随机生成中，每次重启游戏，玩家的飞船可能就置身于一个全新的、陌生的星系，之前的探索记录全部作废。这显然不符合一个沉浸式太空模拟的设定。PGG通过一套确定的种子（Seed）系统和生成算法，保证了生成的宇宙是确定性的。只要种子不变，无论你重启项目多少次，在三维空间坐标（X， Y， Z）为（100， 0， 200）的位置上，永远会有一颗特定的恒星，它周围第三颗行星的大气成分和地表纹理也永远不会改变。这种确定性是构建可探索、可记录、可回溯的宏大太空世界的基础。

它专为那些需要“规模感”和“探索感”的项目而生。无论是开放世界太空游戏（类似《精英：危险》、《无人深空》的早期原型）、科幻RPG的星空背景、战略游戏的星图，还是用于影视预演或科学可视化的动态星图，PGG都能提供一个高起点的解决方案。你不用再从零开始研究天体物理学简化模型、轨道力学算法和GPU星点渲染优化，而是可以直接站在这个工具的肩膀上，专注于你的游戏玩法、叙事和艺术风格。

2. 核心设计思路：分层级的程序化生成架构

PGG的整个系统设计得非常清晰，采用了典型的分层生成策略，从宏观到微观，从抽象数据到具体视觉表现，层层递进。理解这个架构，是有效使用和深度定制它的关键。

2.1 银河系生成层：星海的蓝图

这一层决定了宇宙的“骨架”。你首先需要定义一个银河系的基本参数，其中最关键的就是种子值。这个种子是整个生成过程的源头，它决定了银河系中数千甚至数万颗恒星的分布、类型、亮度等所有宏观属性。PGG通常会模拟几种常见的星系形态，比如：

  • 旋涡星系：拥有清晰的旋臂，恒星密度在旋臂上更高，视觉上最具辨识度。
  • 椭圆星系：恒星分布更为均匀、呈椭球状，适合作为背景或古老星系。
  • 不规则星系：结构松散，生成更具随机性和艺术感。

除了形态，你还需要设定银河系的半径、恒星的密度（核心密、边缘疏）、恒星的总数（这直接关系到性能）以及不同光谱类型恒星（O， B， A， F， G， K， M型，对应蓝巨星、白星、黄矮星、红矮星等）的分布比例。这些参数共同构成了一张宏观的星图。生成的结果并不是立刻创建成千上万个GameObject，而是一套存储在内存或可序列化数据文件中的恒星数据列表，每条数据包含了位置、光谱类型、亮度、质量等属性。

实操心得：在项目初期，不要盲目追求恒星数量。先从一个较小的星系（如1000颗恒星）开始测试性能和视觉效果。恒星数量与后续的恒星系统生成是解耦的，你可以先生成一个庞大的星图数据，但只动态加载玩家附近的部分。

2.2 恒星系统生成层：恒星的家族

当玩家或镜头靠近银河系中的某个特定恒星时，PGG会触发第二层生成：为该恒星创建其专属的恒星系统。这一层的生成规则同样由银河系的种子和该恒星的独立属性（如质量、类型）派生出的次级种子决定。

一个恒星系统的生成主要包括：

  1. 行星轨道模拟：根据简化的开普勒定律，在恒星周围生成一系列椭圆轨道。轨道参数（半长轴、偏心率、倾角）会按一定规则分布，例如内轨道行星通常更靠近黄道面，外轨道可能倾角更大。PGG会避免轨道过于交叉导致视觉混乱和物理碰撞。
  2. 行星数量与类型决定：基于恒星类型（一颗炽热的O型星可能不易形成岩石行星，而一颗稳定的G型星如太阳则更可能拥有宜居带），算法会决定该星系拥有多少颗行星。行星类型大致分为：类地行星（岩石）、气态巨行星、冰巨星等。
  3. 行星基础属性生成：为每一颗行星生成半径、质量、自转周期、轴倾角等物理属性。这些属性会影响后续的地表生成和视觉表现。

2.3 行星细节生成层：世界的雕琢

这是最耗费计算资源但也最体现细节的一层。当玩家进一步接近某颗行星时，PGG会进行第三层生成：创建行星的地表细节。这通常结合了程序化噪声（如Perlin Noise， Simplex Noise）和基于物理的规则。

  1. 地形高程生成：使用多层不同频率和振幅的噪声叠加，生成山脉、山谷、平原、盆地等地形特征。噪声种子来源于行星的种子，确保每次生成一致。
  2. 生物群系/地表类型划分：根据地势高度、坡度、朝向（坡向）以及模拟的“纬度”（离行星赤道的角度）和“湿度”（可通过另一层噪声模拟），将行星表面划分为不同的区域，如沙漠、冻土、岩石地、草原等。每种类型对应不同的颜色贴图或材质。
  3. 特征点放置：在生成的地形上，程序化地放置一些特殊点，比如陨石坑（特别是在没有大气的行星上）、大型峡谷、火山口等。这些点的分布也由噪声控制。
  4. 大气与云层渲染：对于拥有大气的行星，需要生成大气散射效果和动态的云层。云层可以使用平铺的、带有动画的纹理，也可以使用体积噪声进行更复杂的模拟。

2.4 持久化与流式加载：无缝宇宙的关键

“Persistent”不仅指生成的确定性，还意味着状态的可保存。一个完整的宇宙可能包含数百万个可交互实体（行星、空间站、小行星），显然无法全部实时加载。PGG的核心技术挑战之一就是流式加载与卸载。

  • 基于距离的LOD（细节层次）：对于遥远的恒星，它可能只是一个屏幕上的像素点或一个简单的粒子。当玩家靠近时，它变成一个带光晕的Sprite或简单模型。更近时，才加载其完整的恒星系统数据并实例化行星轨道。当玩家登陆行星时，才加载高分辨率的地形网格和纹理。每一层都有对应的生成阈值和卸载阈值。
  • 数据序列化：所有生成规则和种子都需要被保存。通常，你只需要保存银河系的种子、以及玩家已探索并可能改变过的星球状态（如建造了基地、开采了资源）。整个宇宙的“蓝图”可以通过种子随时重建。对于玩家改变的状态，需要单独保存一个增量数据文件。
  • 异步生成：行星地形生成（尤其是使用Marching Cubes等算法生成体素地形时）是CPU密集型任务。必须放在异步线程或Job System中处理，避免阻塞主线程导致游戏卡顿。Unity的Job System和Burst编译器是完成这项工作的理想工具。

3. 核心模块实现与Unity技术栈整合

要将PGG这样一个庞大的系统在Unity中高效运行，需要巧妙地组合多个核心模块和Unity的最新特性。

3.1 数据驱动与ScriptableObject架构

良好的架构是管理复杂系统的前提。PGG强烈依赖于数据驱动的设计，而Unity的ScriptableObject（SO）是实现这一点的完美载体。

  • 银河系配置SO：这是一个核心配置文件，包含了之前提到的所有银河级参数：种子、星系类型、半径、恒星密度曲线、恒星类型分布概率等。在编辑器里调整这个SO，可以实时预览星系形态的变化（需编写简单的编辑器脚本）。
  • 恒星模板SO：定义不同类型恒星（O， B， A...）的视觉和物理属性，如基础颜色、发光强度、模型缩放、宜居带范围计算公式等。
  • 行星模板SO：定义各类行星（类地、气态、冰巨星）的生成参数范围，如最小/最大半径、质量范围、可能拥有的大气类型、地形噪声参数预设等。
  • 生物群系SO：定义不同的地表类型，关联到地形材质、颜色调色板、可能出现的植被或岩石预制体等。

通过组合这些SO，你可以像搭积木一样配置出风格迥异的宇宙，而无需修改代码。例如，创建一个“暗黑奇幻”风格的星系，你可以调整恒星颜色偏暗红，气态行星纹理更诡异，类地行星的生物群系SO关联上哥特式的岩石材质。

3.2 程序化网格与GPU Instancing渲染

渲染成千上万的恒星和行星是巨大的性能挑战。

  • 星点渲染：对于背景恒星，最有效的方法是使用GPU Instancing。你只需要一个简单的四边形（Quad）或一个点（Point）网格，以及一个包含所有恒星位置、颜色、亮度信息的ComputeBuffer或Graphics.DrawMeshInstancedIndirect。在Shader中，根据距离将这些点渲染为带有辉光效果的精灵。一个Draw Call就能绘制整个星海的背景。
  • 行星渲染：对于中距离的行星，它们可能只是一个带有纹理的球体。可以使用LOD Group组件，设置多个不同面数的球体网格，根据距离切换。对于拥有复杂地形的行星，则需要动态生成网格。
  • 程序化地形网格：常见的方法是使用球面映射的噪声生成高度图，然后根据高度图位移一个高精度的球体网格（Icosphere）的顶点。为了优化，可以采用Chunk（分块）系统，将行星表面划分为多个六边形或四边形的块，只生成和加载玩家视野范围内的块。Unity的Job System可以用来并行计算每个Chunk的顶点数据，Burst编译则能极大加速计算过程。
// 伪代码示例：使用Jobs生成地形Chunk [BurstCompile] public struct TerrainGenerationJob : IJobParallelFor { public NativeArray<Vector3> vertices; public float planetRadius; public float noiseScale; public int seed; // ... 其他参数 public void Execute(int index) { // 根据index计算顶点在球面上的原始位置 Vector3 spherePos = ...; // 使用基于seed的噪声，计算该点的高度位移 float height = CalculateNoiseHeight(spherePos, seed, noiseScale); // 计算最终顶点位置 vertices[index] = spherePos * (planetRadius + height); } }

3.3 着色器与视觉特效

视觉表现力直接决定了宇宙的沉浸感。

  • 恒星着色器：需要一个自定义的Unlit或PBR Shader Graph。核心是强烈的自发光（Emission），通常结合一个HDR颜色和强度参数。为了表现恒星的日冕和表面活动，可以叠加一个流动的噪声纹理。对于近距离观察，可能需要实现一个简单的球体模型。
  • 行星着色器：这是最复杂的部分。可能需要一个支持多纹理混合的Shader。例如：
    • 基础颜色层：根据生物群系和高度，从多个平铺纹理中混合出基础颜色。
    • 法线贴图层：提供地表细节。
    • 大气散射：实现瑞利散射（Rayleigh Scattering）和米氏散射（Mie Scattering）来模拟天空颜色和地平线光晕。这在URP/HDRP中可以通过体积雾或后处理栈实现，但在Built-in管线中需要自己编写片段着色器计算。
    • 云层：通常使用一个透明的、带有动画偏移的平铺纹理层，或者更高级的体积云渲染。
  • 太空背景与星云：动态的星空背景立方体贴图（Cubemap）或使用粒子系统模拟遥远的星云。星云可以通过在屏幕空间绘制带有噪声纹理的半透明面片来实现。

3.4 物理与交互模拟

一个可探索的宇宙需要基础的物理模拟。

  • 简化轨道力学：在游戏运行时，完全按照真实的牛顿力学模拟N体运动是不现实的。通常采用简化的“开普勒轨道”模型。每个天体沿着预计算好的椭圆轨道运行，其位置可以通过轨道参数和时间t的公式快速算出，无需实时进行重力积分。这既保证了视觉上的合理性，性能开销也极低。
  • 重力与运动：玩家的飞船或其他动力学物体，可以采用“球状重力”模型。当进入某个天体的重力影响范围（Sphere of Influence）时，飞船的物理引擎就切换到以该天体为中心的局部重力场中，受到指向该天体中心的引力。
  • 碰撞与着陆：行星的地形碰撞体需要与程序化生成的地形网格同步更新。可以使用Unity的Mesh Collider，但对于大规模地形，这性能很差。更优的方案是生成一个简化版的碰撞网格，或者使用高度图生成一个球形的Terrain Collider（如果地形是基于高度图的话）。

4. 性能优化与内存管理实战

程序化生成无限世界的梦想，最终都要面对性能和内存的现实。以下是几个关键的优化战场。

4.1 流式加载与对象池

这是保证游戏流畅运行的核心机制。你需要设计一个管理器（如UniverseStreamingManager），它持续监控玩家（主摄像机）在宇宙中的位置。

  • 分层加载距离：设定多个距离阈值。例如：

    • 100,000 单位：仅作为背景星点渲染。

    • 10,000 - 100,000 单位：加载恒星基本数据，并实例化一个简单的恒星Sprite。
    • 1,000 - 10,000 单位：加载该恒星系统的所有行星轨道数据，实例化行星的简易模型（低模球体）。
    • < 1,000 单位：加载行星的高精度地形，并开始生成地形Chunk。
    • < 100 单位（登陆状态）：加载地表细节物体（岩石、植被等）。
  • 异步操作：所有加载和生成（特别是地形生成）都必须放在async方法或JobSystem中，避免主线程阻塞。使用Addressable Asset System来管理资源加载和卸载是行业最佳实践，它能完美处理依赖关系和内存生命周期。
  • 对象池：恒星、行星的简易模型、小行星等大量重复出现的物体，必须使用对象池。当它们移出加载范围时，不是Destroy，而是回收到池中并重置状态，等待下次使用。

4.2 计算优化：Jobs, Burst, ECS

CPU端的生成计算是性能瓶颈。

  • Unity Job System & Burst Compiler：如前所述，地形顶点计算、噪声生成、天体位置批量更新等计算密集型任务，都应封装为Job，并利用Burst编译成高效的本地代码。这通常能带来数量级的性能提升。
  • Unity ECS（实体组件系统）考量：对于超大规模的天体模拟（例如数万颗小行星的运动），传统的GameObject模式可能成为瓶颈。ECS架构提供了极致的数据局部性和多线程性能。你可以将天体的位置、速度、质量等数据定义为IComponentData，用一个System来并行更新所有天体的运动。但是，ECS的学习曲线陡峭，且与Unity传统的渲染和物理管线整合需要额外工作。对于大多数项目，如果天体数量在几千这个量级，优化良好的GameObject+JobSystem方案已经足够。ECS更适合用于模拟星际尘埃、粒子群等海量实体。

4.3 渲染优化

  • 遮挡剔除（Occlusion Culling）：在太空中用处有限，因为视野通常非常开阔。但对于行星地表，特别是崎岖地形，需要精心设置遮挡区域（Occlusion Area）。
  • LOD（细节层次）：为每一个视觉对象（恒星、行星、飞船模型）设置多级LOD。确保在远处使用面数极少甚至只是一个公告板（Billboard）的模型。Unity的LOD Group组件可以自动管理这一过程。
  • 合批（Batching）：尽可能让静态的天体（如背景恒星）标记为Static，以便Unity进行静态合批。对于使用相同材质的动态行星，确保它们满足动态合批的条件（顶点数、材质等）。
  • 着色器优化：避免在行星着色器中使用过多的纹理采样和复杂的光照计算。充分利用Shader LOD，在远处使用简化版本的Shader。

5. 项目实践中的常见陷阱与解决方案

在实际开发中，你会遇到许多预料之外的问题。以下是一些典型的“坑”及其填平方法。

5.1 精度问题：当数字太大时

Unity的Transform组件使用单精度浮点数（float）来存储位置。在模拟以光年或天文单位为尺度的宇宙时，当坐标值非常大（例如超过1e6）时，浮点数的精度会严重下降，导致物体抖动（Jittering）、物理模拟不稳定、甚至渲染错误（Z-fighting）。

解决方案：

  1. 局部坐标空间（Local Space）：这是最常用且有效的方案。将玩家（或主摄像机）始终置于世界原点（0，0，0）。整个宇宙围绕玩家移动。当玩家“移动”时，实际上是将整个宇宙向反方向移动。玩家的飞船、附近的星球都处于这个局部空间内，坐标值保持在一个较小的、高精度的范围内。只有远方的背景恒星和星图，其“真实”的大坐标用于生成和逻辑判断，但渲染时会被重定位到以玩家为中心的相对位置。
  2. 双精度坐标（Double Precision）：在逻辑计算（如轨道计算、星图存储）中使用double类型，仅在最终传递给Unity的Transform进行渲染前，转换为以玩家为中心的float局部坐标。有一些第三方插件或自定义解决方案实现了双精度Transform。
  3. 坐标重定（Origin Rebasing）：当玩家移动了很远的距离后，执行一次“重定”操作。将世界原点瞬间跳变到玩家当前位置，并相应地重置所有物体的坐标。这个操作需要在一帧内完成，并处理好所有依赖世界坐标的系统（如物理、寻路）。

实操心得：优先采用“局部坐标空间”方案。它概念清晰，实现相对简单，且与Unity的现有体系兼容性最好。你需要编写一个UniverseManager来统一管理这种坐标转换。

5.2 保存与加载：种子与状态分离

如何保存一个程序化生成的、近乎无限的宇宙？答案是将“生成规则”和“玩家改变的状态”分开保存。

  • 保存“蓝图”：你只需要保存银河系的种子（Seed）和所有自定义的生成参数配置（那些ScriptableObject的引用或数据）。这些数据量非常小。下次加载时，用相同的种子和参数重新运行生成算法，就能得到完全相同的宇宙“蓝图”。
  • 保存“状态”：玩家在宇宙中留下的痕迹需要单独保存。例如，在某个星球坐标上建造了一个基地，开采了某个矿点，或者击毁了一个空间站。你需要一个系统来记录这些“状态改变”。通常，这会是一个基于坐标或唯一ID的数据库或字典。保存时，只保存这些改变；加载时，先根据种子生成原始宇宙，再应用保存的状态改变。

5.3 艺术资源管线：风格统一与性能平衡

程序化生成不意味着美术无事可做。相反，它需要美术提供一套高度模块化、可参数化的资源。

  • 材质与纹理：为不同的行星类型（岩石、沙漠、海洋、冰原、气体）制作基础材质。使用可平铺的纹理（Tiling Texture）和可调节的参数（如颜色、粗糙度、细节强度）。利用Shader Graph或Amplify Shader Editor创建高度可配置的材质球。
  • 模型预制体：为地表细节（岩石、植被、建筑物遗迹）制作多种变体的预制体。这些预制体需要优化面数，并准备好LOD。
  • 性能预算：与美术团队明确性能预算。例如，一个地形Chunk最多允许绘制多少个岩石预制体？行星大气的着色器复杂度上限是多少？建立明确的规范，避免后期为了优化而大规模返工。

5.4 调试与可视化：让不可见变得可见

在开发这样一个系统时，强大的调试工具至关重要。

  • 生成调试视图：在Scene视图中绘制Gizmos，可视化显示恒星的影响范围、行星的轨道线、地形Chunk的边界、流式加载的各个距离阈值圈。这能让你直观地理解系统的运行状态。
  • 数据监视窗口：创建一个自定义的Editor窗口，实时显示当前加载的恒星/行星数量、内存使用情况、生成任务的队列状态、当前帧的三角面数等关键性能指标。
  • 种子测试工具：制作一个简单的工具，可以快速输入不同的种子，并立即在Game视图或一个预览小窗口中看到生成的星系形态，方便寻找符合项目艺术风格的“好种子”。

开发一个“Persistent Galaxy Generator”是一个庞大的工程，它涉及程序化生成、计算机图形学、性能优化和软件架构等多个领域。从Asset Store的现成工具入手，理解其设计理念和实现方式，然后根据自己项目的具体需求进行裁剪、扩展和深化，是一条非常高效的路径。这个工具提供的不仅仅是一堆代码和着色器，更是一套构建宏大、可信、可探索的虚拟宇宙的方法论。当你看到玩家驾驶飞船，从一个自动生成的、拥有独特地貌的星球表面起飞，穿越由其恒星种子决定的特定小行星带，最终跃迁到一个由你定义的规则所创造的、浩瀚而持久的银河系中时，那种成就感，正是驱动我们不断探索技术边界的原动力。

编程学习 学习日记 实战经验
← 返回列表