请您帮我弄清楚游戏场景图应包含什么内容？请参阅以下列表：
上面考虑的对象类型。现在来看场景图：
Answers:
我认为大量阅读其他场景图技术正在做什么将为您带来很多好处。
背景
例如，查看Ogre3D描述。它是一个基于场景图的图形引擎，是开源的。我建议您看一下教程，看看如何使用场景节点（注意：我并不是在告诉您学习如何使用Ogre，而是告诉我们Ogre的场景节点和场景管理器具有哪些功能）
SceneNode文档：http ://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html
SceneManager文档：http ://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html
以下链接还值得一看：http :
//sgl.sourceforge.net/#features
这是一个基于OpenGL的场景图解决方案，并且功能页显示了它可以包含的所有节点。
您的建议节点
我认为场景图应尽可能从游戏逻辑中抽象出来，这样就不会出现任何依赖关系问题。对于您的每个要点，我会说以下内容：
游戏演员，
我可能会拒绝。与Ogre相似，我将拥有一个基本的Entity类（其中将包含对象特定的逻辑）和一个带有Scene Node实体的Entity成员指针，以获取渲染对象的适当信息（位置，方向等）。
编辑：我不是说不要在这里的场景图中包括您的游戏演员（否则什么都不会出现：P）我是说要有一个引用逻辑游戏演员类的场景节点，所以您已经游戏对象的渲染和更新仍然松散耦合。
简单的静态游戏对象
是
游戏触发器？
不，对我来说，这听起来像是特定于游戏的逻辑。
游戏灯？
是
游戏摄影机？
是
武器子弹？
不能完全确定这一点，但我可能会说是，但是您可能希望所有子弹都作为子对象到达“ BulletCollection”父场景节点，这样您就可以缓存该位置，而不必遍历场景图需要删除并添加项目符号以进行渲染。
游戏爆炸和特效？
不确定，我让别人回答。
场景图覆盖率
如果级别相对较小，则应该能够将整个级别存储在场景图中，然后使用Octree（通常用于室外环境）或BSP树（通常用于室内环境）优化可见性。
如果您的关卡要大得多，并且您不想执行任何关卡加载，那么这将在流中发挥作用，但这完全是另一个问题。我将从一个较小的层次开始，然后逐步查看在不影响性能的情况下可以进行多大的调整。
结论
对我而言，场景图是游戏循环的“渲染”部分。您不应该将渲染和逻辑更新过于紧密地耦合在一起，否则您将遇到烦人的依赖问题。
我倾向于建议在场景图中放置较少的内容。特别请参见Tom Forsyth的这篇文章：“ 场景图-说不”。
Forsyth文章的症结在于，您不应该试图将一堆无关的东西塞进一个大的主数据结构中。这与我在此答案中提到的想法非常相似，即从游戏中衍生出所有内容GameObject，然后将其全部塞入一个大的异构列表中（这很糟糕）。
相对于树木结构，世界上几乎没有对象真正表现出强大的父子关系。在这里通常使用典型的桌子上的咖啡杯示例-当然，您可以将其视为桌子上的“孩子”……至少要等到敲下来为止。那它真的还是孩子吗？这意味着您的“树”最终可能会变得很浅，并且无论如何都会退化为列表。
因此，我建议您对多个事物使用多个数据结构，因为对这些事物最有意义。例如，将静态几何图形和灯光插入场景图中似乎是一件合理的事情。即使所表示的对象不具有自然的父子关系，它们是静态的事实也意味着您可以为它们提供结构化的父子关系，即使它们从未改变。
游戏演员...我不太确定。实际上，任何趋于移动的事物都意味着您通常需要将它们保持在图形的根附近或不断对其重新父级化（这是一件繁琐的事情，而且效率不高）。
项目符号，触发器，特殊效果和其他暂存对象我将存储在其他位置。渲染图中不应有任何呈现或具有视觉表示的内容（触发器通常是不可见的边界体积，项目符号通常只是射线投射）。您应该努力分离渲染层和逻辑层。
就其价值而言，我从未在为非学术用途而构建的任何渲染器中都使用过树状场景图（显然，我之前已经构建过树状场景图，这就是我得出结论的方式）现在正试图让您同意）。
我使用适合游戏风格（四叉树，八叉树，BSP等）的空间分区方法对游戏中的逻辑实体进行分组/剔除（a）对此帧进行处理并（b）进行渲染这个框架。然后，我最终将列表（b）中的对象集输入到一个系统中，该系统将逻辑对象映射为呈现描述，并根据属性将这些描述分类到存储桶中（例如，任何使用透明性的东西都将被推入存储桶中以用于“填充”应该依次渲染每个存储桶，并为每个存储桶按顺序渲染每个描述。我猜您可以称其为“树”，但它没有展现出典型的状态/传统的面向树的场景图所采用的变换传播方法。