13.1 公告板

        公告板在多数的英文教程中译为Billboard，我们平时逛街的时候，总会看到路边摆放着的交通指示牌、商场周围的广告牌等。这一章我们所学的“公告板”就跟这些指示牌、广告牌等在概念上很类似。只不过这里的“公告板”的概念和用法会更加简单。

        在Ogre中（事实上在计算机图形学中也是如此），公告板是在场景中随摄像机角度的变化而变换方向的简单四边形。也就是说，公告板的角度会根据摄像机的位置进行相应的调整，使公告板的正面法向量总是与摄像机方向相同。

        通常公告板随着摄像机的视方向旋转以便与摄像机的视线方向对齐。为了效率考虑，公告板与摄像机的视线方向对齐，而不是与从公告板到摄像机的向量对齐。大部分情况下两者没有明显的区别。如果想使用后一种的对齐形式，也可以办到，可以牺牲一些性能作为代价，这个我们在之后的章节会介绍。

        图13-1中展示了公告板的朝向位置。

图13-1：在（a）中公告板正朝向摄像机。

在（b）中，摄像机已经移动并且公告板也旋转自动朝向摄像机。

 

        具体来讲，公告板的应用是十分广泛的，我们可以把它想象成一个可以放置任何东西的大的容器，也或者是可以把它想象成一个表层。我们可以将公告板放置在场景中的任何位置，放置好以后，它就会一直朝向摄像机方向，即随着摄像机方向的变换而转动自己的角度。我们可以把普通的文本或是渲染纹理等一些基础的东西放置在公告板上，也可以通过放置一张图片来实现这个图片上的内容要反映的效果，比如我们可以放置一张硝烟滚滚的图片来模拟这种烟雾缭绕的效果。在一些大型的网络游戏中，我们通常会看到一些角色的头上会顶着一些随着角色移动而移动的文字或是图标等等，比如角色名字，这就是通过公告板实现的。

 

笔者注：         为了提高执行效率，公告板虽然面向摄像机方向，但实际上并不是严格面向从公告板到摄像机的向量，而是有一定的误差，在大多实际应用中，这些误差并不明显。 我们在设计程序的时候可以实现让公告板来“分毫不差”的与摄像机向量对应，不过这会影响系统地执行效率。公告板本身看似很神奇，但是它只提供了一种在三维世界中创建特效的装置。公告板在默认情况下是有Ogre进行管理的，当然我们也可以从Ogre的手中将公告板“接管”过来，但这种做法是不被推荐的。

 

13.1.1公告板集合

        公告板不能独立存在，它们也不能自我渲染，它们必须属于某个公告板集合。公告板集合可认为是一组公告板的管理器，公告板集合内的所有公告板有相同的尺寸、相同的材质等等，这样做的原因是相同的尺寸和材质有助于提升计算机的计算和渲染效率。如果一个公告板集合拥有的公告板数量比较多的时候，使用相同的尺寸、相同的材质是十分必要的；不过当公告板集合中的公告板数量很少时，就没必要非得限制其中的公告板尺寸和材质等的一致性了。当然，我们单独改变一个公告板集合中的某一个或某几个公告板的尺寸或材质，但这样做会导致计算机计算和渲染性能的下降，因为公告板集合本身在设计的时候就是针对相同尺寸或材质的公告板进行优化的。  

        Ogre认为公告板集合是一个独立可操作的单位，集合中的公告板要么都不渲染，要么全部进行渲染。当然，我们也可以对集合中的某个单独的公告板进行操作，但这样做也会导致系统效率的下降。

 

笔者注：         集合中公告板的位置是相对于集合在场景中挂载场景节点的相对位置。因为所有集合中的公告板都是用了相同的材质，进而可以在相同批次中被渲染，这就意味着对于GPU渲染来说200个公告板和2000个并没有什么大的不同。

 

13.1.2公告板池（Billboard Pools） 

                                                       

        在Ogre中使用公告板以及公告板集合的时候，我们需要像使用其他资源一样，对公告板以及公告板集合进行管理，公告板集合聚集在一起就形成了公告板池，公告板池的尺寸对应着公告板池内公告板集合的数量。Ogre会提前做好创建公告板的工作，以便在必要的使用提供给用户使用。公告板池内有两个队列：活动队列和空闲队列，分别用于盛放活动状态和空闲状态的公告板。公告板池的大小可以动态的扩大，可以通过代码将其在需要的时候扩大到原有尺寸的2倍，当然，公告板池尺寸的扩大就意味着要消耗更多的计算机资源来对其进行处理，从而会影响计算机的运行效率，实际应用中并不推荐这种扩大公告板池尺寸的做法，通常为保证系统的效率还是会选择原有公告板池的大小。                                                                             

13.2 粒子系统

        下面请读者思考一下，当我们在3D场景中添加一个人物模型的时候，只需要在程序中添加一句代码就可以轻松的实现，这是因为这个要添加在场景中的3D模型是一个“整体”。那么，我们在3D场景中要如何实现下雨的效果、喷泉喷放的效果、以及爆竹爆炸的效果?相信细心的读者已经可以发现，诸如下雨的效果、喷泉喷放的效果、以及爆竹爆炸的效果这些效果的对象：雨水、喷泉、炸裂的爆竹等等都不是一个独立的“整体”，那么这些效果在Ogre中要如何实现呢？下面，让我们马上来学习粒子系统这一节，相信在这之后读者朋友就可以轻松的实现这些效果了。事实上，粒子系统是3D程序中产生多种视觉特效的基础。虽然有些时候我们也可以用一些其他的方式来实现这些特效，不过使用粒子系统的好处就在于它的简单性。

13.2.1 粒子系统基础与3D场景

        粒子系统可以使用相应的脚本来定义，相对于硬编码的实现方式，脚本显得更加容易修改、而且脚本可以更好的为读者使用。如同Ogre系统中任何其它可以通过脚本来定义的系统一样，你也可以完全通过代码来创建和配置粒子系统。在粒子系统中所使用的粒子脚本在实际的使用中其实是一个粒子模板，你可以通过它在程序中产生多个实例。换句话说，你如果想创建多个相同的粒子效果，你不用定义多个粒子脚本，只要从一个脚本创建多个实例就好了。

        粒子系统会被挂到场景节点上，因此，节点的平移，缩放，旋转会关联到粒子系统，影响粒子反射。进一步说，粒子会被发射到世界空间中，这意味着当场景移动时，它会牵连到发射器，但已经发射出去的粒子不受影响。但是随着场景节点的变换，粒子发射器却跟随着一同产生相应的变换，发射出来的粒子却被遗留在后面（这就好像，移动的燃烧物遗留下来的烟迹一般）。假如需要这些粒子受结点的影响，可以把粒子发射到本地空间(local space)中。粒子系统不能无限制的发射粒子，它有一个限额（quota)。一旦到达限额，粒子系统不会再发射粒子，直到已经存在的粒子消亡。在默认的情况下，这个限制的数量是10，所以在你真正的应用中，需要把这个数值扩大到你需要的量上面。

 

笔者注：         粒子系统必须拥有一个发射数量的配额，这就是它发射粒子的数量限制。一旦发射出来的粒子总数达到了这个限额，粒子系统就会停止发射，直到已经存在的粒子在达到其生命周期消失后，然后才能继续发射新的粒子。在默认的情况下，这个限制的数量是10，所以在实际应用中，需要及时设置这个数值已达到我们期望的目的。

 

13.2.2 创建第一个粒子系统

        在进行详细介绍Ogre的粒子系统之前，我们同样先来看一个简单的示例，让我们一睹Ogre中的粒子效果。

        同样，我们使用我们在前面章节保存的模板代码，修改createScene函数中的内容如下：

void createScene() { Ogre::ParticleSystem*partSystem =mSceneMgr->createParticleSystem("Smoke","Examples/Smoke"); mSceneMgr->getRootSceneNode()->attachObject(partSystem); }

        编译并运行程序，你将会看到以下效果：

        代码分析：

        我们可以看到通过简单的两行代码就可以看到一个相当不错的烟雾特效，其实读者朋友应该不难想象，虽然我们在程序中只加了两行代码，但是大部分的内容都和我们定义材质的时候一样，粒子脚本允许你实例化的在你的脚本中定义粒子系统，而不必在源代码中进行设置，使得你做任何修改都能得到快速回应。在程序代码中，我们只需