游戏引擎中的场景管理——从零搭建你的世界容器

场景管理，说白了就是游戏引擎的「世界容器」。

你想想看，一个游戏里可能有成千上万个物体——角色、树木、灯光、粒子特效。如果让它们各自为政，引擎根本跑不动。我当年刚接触游戏开发时，就犯过这个错：把所有物体塞进一个数组，每帧遍历全部。结果场景里放了500个箱子，帧率直接掉到20帧。嗯，从那以后我才明白——场景管理不是「存东西」，而是「高效地找东西」。

场景管理的核心职责

我个人习惯把场景管理拆成三个层次：

• 空间划分：把大世界切成小块，只处理视野内的物体
• 生命周期：物体的创建、激活、销毁，不能有内存泄漏
• 渲染调度：决定哪些物体该画、按什么顺序画

这三个层次缺一不可。我曾经在一个项目里只做了空间划分，忽略了生命周期管理，结果玩家切换场景时内存暴涨——因为旧场景的物体根本没释放。

空间划分：八叉树与四叉树

最常见的场景管理数据结构，就是空间树。

对于室外大世界，我推荐四叉树（2D）或八叉树（3D）。它们的思路很简单：

• 把整个场景看作一个大的包围盒
• 如果盒子里的物体太多，就切成8个小盒子（八叉树）
• 递归下去，直到每个小盒子里的物体数量低于阈值

这样做的好处是：查找物体时，只需要遍历与视锥体相交的节点，而不是全量遍历。

下面是我手绘的一张八叉树场景管理流程图，你看一眼就明白了：

场景图（Scene Graph）的设计

除了空间划分，我们还需要管理物体之间的父子关系。比如一辆汽车，车身是父节点，四个轮子是子节点。汽车移动时，轮子跟着移动。

这就是场景图（Scene Graph）的用武之地。

一个典型的场景图节点结构：

class SceneNode {
public:
    std::string name;
    glm::mat4 localTransform;   // 相对于父节点的变换
    glm::mat4 worldTransform;   // 世界空间变换（由父节点级联计算）
    
    SceneNode* parent;
    std::vector<std::unique_ptr<SceneNode>> children;
    
    // 渲染相关
    Mesh* mesh;
    Material* material;
    bool visible;
    
    void updateWorldTransform() {
        if (parent) {
            worldTransform = parent->worldTransform * localTransform;
        } else {
            worldTransform = localTransform;
        }
        for (auto& child : children) {
            child->updateWorldTransform();
        }
    }
};

注意这里用了 std::unique_ptr 管理子节点——自动释放内存，避免手动 delete 的麻烦。我早期用裸指针，经常忘记释放，后来统一改成智能指针，内存泄漏问题基本绝迹。

视锥体裁剪（Frustum Culling）

有了八叉树和场景图，下一步就是「只画看得见的」。

视锥体就是摄像机的可视范围——一个平截头体。我们需要判断每个物体的包围盒是否与视锥体相交。

具体做法：

1. 从摄像机投影矩阵提取6个裁剪平面（左、右、上、下、近、远）
2. 对每个物体，用其包围盒（AABB或球体）与6个平面做相交测试
3. 如果物体在任意一个平面的「外部」，直接跳过渲染

场景切换与资源管理

游戏里经常需要切换场景——从主城进入副本，从白天切换到夜晚。这时候场景管理要处理：

阶段	操作	注意事项
卸载旧场景	销毁所有场景节点、释放GPU资源	注意引用计数，避免正在播放的动画被提前释放
加载新场景	从磁盘读取场景文件、创建节点树	使用异步加载，显示加载进度条
过渡动画	淡入淡出、黑屏过渡	在渲染循环中插入过渡状态

我个人习惯用「场景栈」来管理切换。比如玩家进入一个室内场景，把室外场景压入栈底，室内场景放在栈顶。退出室内时，弹出栈顶，恢复室外场景。这样避免了频繁的加载卸载。

实战：一个轻量级场景管理器

下面是我写的一个简化版场景管理器，核心逻辑就几十行：

class SceneManager {
public:
    void loadScene(const std::string& name) {
        // 卸载当前场景
        if (currentScene_) {
            currentScene_->unload();
        }
        // 创建新场景
        currentScene_ = std::make_unique<Scene>(name);
        currentScene_->load();
        // 构建八叉树
        octree_.build(currentScene_->getAllObjects());
    }
    
    void update(float deltaTime) {
        // 更新场景图变换
        currentScene_->rootNode->updateWorldTransform();
        // 视锥体裁剪
        Frustum frustum = camera_.getFrustum();
        visibleObjects_.clear();
        octree_.queryFrustum(frustum, visibleObjects_);
    }
    
    void render() {
        for (auto* obj : visibleObjects_) {
            obj->draw();
        }
    }
    
private:
    std::unique_ptr<Scene> currentScene_;
    Octree octree_;
    std::vector<SceneObject*> visibleObjects_;
    Camera camera_;
};

你看，核心逻辑就三个函数：loadScene 负责加载和构建空间索引，update 负责更新变换和裁剪，render 只绘制可见物体。职责清晰，容易扩展。

避坑指南

最后分享几个我踩过的坑：

• 不要用 std::list 存储场景节点。链表的内存不连续，遍历时缓存命中率极低。用 std::vector 或 std::deque，配合对象池。
• 场景切换时注意资源引用。我曾经在切换场景时直接清空所有纹理，结果发现 UI 还在用其中一张——直接崩溃。后来改用引用计数，场景只释放自己独有的资源。
• 八叉树的阈值要调参。每个节点最多放多少物体？我一般设 8~16。太少了树太深，太多了退化成线性遍历。
• 不要每帧重建八叉树。静态物体（地形、建筑）只建一次。动态物体（角色、子弹）单独维护一个列表，每帧只对动态物体做裁剪。

场景管理是游戏引擎的骨架。骨架搭好了，往上添肉（渲染、物理、音效）就顺理成章。希望这篇实战能帮你少走弯路。

---

公众号:蓝海资料掘金营，微信deep3321