新的场景编辑器

场景编辑器，又是场景编辑器，大概一年前我曾写过一个基于BSP的场景编辑器，配合当时的引擎。经过这将近一年的时间我对场景编辑器和bsp，portal，pvs又有了更加透彻的了解。

 

可能有的朋友已经用过Unreal，worldcalf(cs的编辑器)等。我总结一下这些编辑器。

 

首先是单位，他们的1米使用的是64各单位。我开始很奇怪为什么用这么不零不整的单位，为什么不用100代表1米，或者1代表一米，这样不是更加自然。但是深入研究发现这样做是有历史原因的。在早期的场景编辑器quake1,2那个时代没有什么所谓的静态模型，场景中的一切都是用编辑器做出来的，需要网上面刷贴图，如果把64作为一米，则可以很好的和贴图尺寸相对应，也就是说一张128x128的贴图他将覆盖4平方米的区域，这样就可以很好的再贴图和场景之间统一单位。

 

然后是为什么要提供三视图（顶视图，俯视图，侧视图）编辑场景，而不向现在的室外场景编辑器直接摆放导入的物体。这是因为他们都是使用室内空间管理的算法管理场景也就是bsp（关于bsp算法可以去google找，有一大堆文章，而且也不是什么新鲜的东西了）。bsp对场景建模有一定要求，要精确的处理墙与墙之间的连接等，如果出现裂缝可能会导致bsp计算错误。而且要确保所有参与bsp运算的固体都是凸的等等。这些是很难在max里保证的，这也是为什么大多数室内场景编辑都要提供创建并编辑固体功能的原因。

 

对于现代的显卡而言降低渲染批次对于性能的提升远高于精确筛拣那几个面，所以现代的bsp室内场景编辑器并不像以前那样事无巨细的编辑，他只是搭一搭场景的结构，剩下的细节用静态模型填充，而且也要过细的摆放固体参与bsp切分。

 

bsp算法不能处理室外场景么？答案当然是否定的，使用unreal制作的大量的机遇室外场景的游戏已经给出了有利的证明。

 

 

下面说一说我的场景编辑器将要提供的功能

1. 第一条没得说，必然要提供固体的编辑，这些是bsp运算的基础，而且要提供固体之间的csg操作，这些都已经在上一个编辑器里面做过了，应该问题不大。

2. 提供静态模型的摆放

3. 提供地形编辑

4. 提供延迟渲染+shadowmap和光照贴图两套光照方案

5. 操作易用性

 

面临的问题主要就是编辑器使用的场景结构是否要在引擎内提供支持，这也是我之前伯克中提到的问题。这种需要编译的场景编辑器，其在编辑器中场景组织方式和游戏真正运行时的场景组织方式是不同的，甚至是质的不同。如果把编辑器模式下的场景组织管理也写道引擎中，那么事实上这种场景使用也只有编辑器用。

当然一种折衷的方案是在构造好固体场景后先进性bsp编译，这时切换到引擎的场景方式，之后的摆放静态模型就喝这个无关了。一旦修改场景固体，则需切换到编辑器场景模式，直到重新编译之火，听起来似乎更复杂了。

如果单纯的使用编辑器场景管理，一个值得担心的问题就是管理效率和有效筛选。这个还需要进一步思考。