Lom*_*oms 31 c++ graph scenegraph
我已经开始阅读维基百科上的资料,但我仍然觉得我并不真正了解场景图的工作原理以及它如何为游戏带来好处.
Kla*_*aim 25
游戏引擎开发环境中的场景图是什么？
好吧,它是一些代码,可以在游戏空间中对游戏对象进行主动排序,以便快速找到游戏空间中某个点周围的对象.
这样,很容易:
和其他东西.它是关于允许在太空中快速搜索.它被称为"空间分区".这是关于分而治之的.
为什么我要为我的2D游戏引擎实现一个？
这取决于游戏的类型,更确切地说取决于游戏空间的结构.
例如,像Zelda这样的游戏如果足够快以测试屏幕中所有对象之间的碰撞,就不需要这样的技术.然而,它很容易变得非常慢,所以大多数时候你至少设置一个场景图(或任何类型的空间分区),至少知道所有移动物体周围的东西,并仅测试那些物体上的碰撞.
所以,这取决于.大多数情况下,出于性能原因需要它.但是,空间分区的实现与游戏空间的结构完全相关.
使用场景图是否可以替代具有线性实体管理器的经典实体系统？
没有.
无论您如何管理游戏实体的对象生活,空间分区/场景图只是为了让您快速搜索空间中的对象,而不是更少.大多数情况下,它将是一个具有一些对象槽的对象,对应于游戏空间的不同部分,并且在那些槽中,它将是这些部分中的对象.它可以是平的(如2或4中的2D屏幕分隔符),或者它可以是树(如二叉树或四叉树,或任何其他类型的树)或任何其他排序结构,限制您必须的操作数量执行以获取一些与空间相关的信息.
注意一件事:
在某些情况下,您甚至需要不同的独立空间分区系统用于不同目的.通常情况下,"场景图"是关于渲染的,因此它的优化方式取决于玩家的观点,其目的是允许快速收集要渲染的对象列表以发送到图形卡.它不适合执行对另一个对象周围的对象的搜索,这使得很难用于精确的碰撞检测,就像使用物理引擎时一样.所以为了帮助你,你可能会有一个不同的空间分区系统,仅用于物理目的.
举个例子,我想做一个"子弹地狱"游戏,那里有很多球,玩家的宇宙飞船必须以非常精确的方式躲闪.为了获得足够的渲染和碰撞检测性能,我需要知道:
所以我递归地切割了4个部分的2D屏幕,这给了我一个四叉树.四叉树在每个游戏标记中都会更新,因为一切都在不停地移动,所以我必须跟踪四叉树中每个对象(宇宙飞船,子弹,怪物)的位置,以了解哪一个位于屏幕的哪个部分.
实现1.很容易,只需在系统中输入子弹即可.
为了达到2.我在屏幕边框上保留了四叉树(屏幕的方形部分)中的叶子列表.那些叶子包含靠近边界的子弹的ids /指针,所以我只需检查它们是否正在移动以知道我是否可以停止渲染它们并管理碰撞.(可能有点复杂,但你明白了.)
要达到3和4.我需要检索玩家宇宙飞船附近的物体.所以首先我得到了玩家宇宙飞船所在的叶子,然后我得到了所有物体.这样我只会测试与玩家宇宙飞船在周围物体上的碰撞,而不是所有物体.(它有点复杂,但你明白了.)
这样我就可以确保即使数以千计的子弹不断移动,我的游戏也能顺利运行.
在其他类型的空间结构中,需要其他类型的空间分区.通常情况下,卡丁车/自动游戏将有一个"隧道"场景图,因为视觉上玩家只会看到路上的东西,所以你只需要检查他在路上的位置,以检索"隧道"周围的所有可见物体. .
and*_*and 16
什么是场景图？一个场景图包含了所有特定场景的几何形状.它们可用于表示对象相对于彼此的平移,旋转和缩放(以及其他仿射变换).
例如,考虑一个坦克(带有轨道和枪的类型).你的场景可能有多个坦克,但每个坦克的定位和定位都不同,每个坦克的炮塔都旋转到不同的方位角和不同的炮位.您可以在遍历场景图时正确定位仿射变换以正确定位,而不是确切地确定每个坦克应该如何定位喷枪.它使这些事情的计算变得更加容易.
2D场景图:如果您的内容足够复杂并且您的对象具有多个未严格固定到较大主体的子组件,则使用2D场景图可能很有用.否则,正如其他人所提到的那样,这可能是过度的.2D中仿射变换的复杂性比3D情况下要小得多.
线性实体管理器:我不清楚究竟上您通过什么意思线性实体管理器,但如果你指的只是跟踪的东西在哪里放置在场景中,然后场景图,可以使事情变得更容易,如果有一个高场景中各种对象或子对象之间的空间依赖程度.