上面的视频是我的下一款游戏作品《Food of the Gods》。这游戏使用了Cocos 2d-x 3.3，视频是从我iPhone上录制的实际运行效果。在这篇文章里我将要介绍我是如何制作它、如何把它跑在cocos引擎上的。对于熟悉cocos官方提供的3D示例游戏 《Fantasy Warrior》的开发者，将会看到以下一些主要不同点：
1. 光照贴图（Light Mapping）：你将看到每件物体都有被照亮并且投射阴影。光影效果的质量是由你的3D工具软件决定的，用3D软件能烘焙出复杂的光效，包括直接光照，反射光照，以及阴影。
2. 顶点合并（Vertex Blending）：请注意看路、草地和悬崖交接的地方，看不到任何可见的接缝。
3. 透明遮罩（Alpha Masks）：灌木如果没有透明遮罩就跟纸片一样。
4. 滤色叠加的公告板（Billboards）：增加一些光束和其他环境的效果。
所有的模型都是用一个叫Modo的3D 软件建模制作的，贴图则是使用Photoshop。关于3D模型的制作和贴图的绘制在此就不再赘述，网上已经有很多教程，在此主要介绍下跟Cocos 2d-x有关的部分。
模型网格和贴图（Meshes and Textures）
如下图所示，每个模型的贴图都是由几个256 x 256或者更小的贴图组成的。同时你也会注意到我把所有的小图片都合在了一张贴图上，这是减少GPU绘制次数（draw call）最简单的方法之一。贴图是从http://www.cgtextures.com 或者网上找的。
为了把这些图片拼接起来，我使用的是Photoshop的补偿滤镜（offset filter）然后在接缝的地方用修复画笔来做一些自然的过渡。为了获得一种油画的视觉效果我会先使用cutout滤镜（注意：cutout滤镜也会使得png格式图片的压缩效果更好），然后在需要的地方绘制一些高光和阴影的效果。我发现如果直接拿照片当贴图的话，当你把它尺寸缩小的时候会出现图像噪点。
另一种方案是为每一个模型网格制作一整张独立的贴图。当网格比较小或者摄像机不是很靠近网格的时候这种方法是可行的。如果你的photoshop技术过硬的话，出来的效果会更好。附带的好处是，因为只使用一张贴图因此只有一次GPU绘制调用。但我不建议采用这种方法来制作第一人称射击游戏（FPS）中的建筑，因为当你走得很靠近建筑物的时候，贴图分辨率过低的问题就会显露出来。我不喜欢用这种整张贴图方法，因为这实在太费时耗力了。这个场景的制作花了我足足四天时间。
光照贴图（Light Maps）
当你做好模型和贴图之后，现在就可以来烘焙光照贴图了。Cocos 2d-x目前还不像Unreal或Unity一样在官方编辑器里提供烘焙光照贴图的功能，但是别失望，大部分的制作3D模型的软件都可以烘焙光照贴图，并且效果比市面上任何游戏引擎的效果还好。首先，在你的3D工具软件里，先给场景打好灯光，照亮场景，然后为每份网格制作第二张UV map。每份网格的表面都必须被映射在0到1范围内的UV 平面上。这听起来好像很复杂且耗时，但在Modo里这是非常简单的。我先后使用 “Atlas map”的UV 工具和“Pack UV”工具，这两个工具会自动将网格展开成一个相当不错的排布图。
这些都完成之后，设置3D工具软件的渲染器为“只渲染烘焙的光照”，然后开始渲染。当然了，如果你想做一些环境光遮罩的效果也是可以的。
你也可以使用一些分辨率较低的光照贴图。有时候这样的效果反而会看起来更好，因为相互混叠的模糊像素会让阴影看起来更柔和。上面的这些建筑都映射到一张512 x 512的光照贴图上。整个场景总共使用了4 张512 x 512的光照贴图。请确保每个小图块之间有一定的空隙，且让你的渲染范围比这些图块的边界多出几个像素。这样可以防止当较低的mip-maps（一种纹理采样）起作用时黑边出现在网格周围的角落里。
最后一点听起来像是3D技术的行话。如果是对Texture Packer熟悉的话，那么其中的“Extrude”值起到的作用就是刚刚我所描述的。对贴图的边缘接缝做一些涂抹处理，这样在精灵之间就不会有那些烦人的缝隙了，那些缝隙在这里会变成多边形边缘的黑边。
如果你想牺牲内存和包大小来提高性能的话，你可以把颜色和光照信息都烘焙到一张贴图上并避免共同使用一张光照贴图。但是这样做的话，同样的像素密度，贴图的大小至少得翻一倍。这完全取决于你个人、以及你游戏的要求。
接下来，添加顶点颜色。我在地形上提供了顶点颜色，这可以让着色器在合成悬崖顶上的草地贴图时，不会有任何可见的接缝。下图中涂成白色的顶点部分可以合成你指定的贴图。在这个例子里实际上我只使用红色通道，当然了根据实际需要你可以使用4个通道（RGBA）去合成不同的贴图。
最后，我把整个场景分成了很多独立的网格（mesh）：每个建筑都有自己独立的网格，地形独立一个网格，水也是独立一个。带透明遮罩的贴图也会有一个网格——比如视频中看到的植物叶子和小旗子。我这样做有两个原因，首先，让地形、建筑、水和带透明遮罩的贴图各自使用不同的着色器。其次，我们打算通过不渲染摄像机范围外的对象来减少性能开支。很重要的一点是摄像机会根据网格的包围盒来决定对象是否可见，因此尽量把网格弄成小块，这样包围盒会比较小。
导出
完成了模型和贴图之后，我们需要把每个mesh导出为一个.fbx文件。幸运的是，大多数的3D建模软件都支持这个功能。Autodesk为此格式提供了一个免费SDK。但不幸的是，Modo 701在导出fbx格式时会出现相当多的错误。因此我必须自己写一些脚本来保证第二组贴图坐标和顶点颜色的正确导出。你可以从我个人网站上的“Modo Scripts”部分下载这个导出脚本。搞定fbx之后，你将需要用到Cocos 2d-x自带的fbx-conv.exe命令行工具，它位于Cocos 2d-x根目录的/tools下。
fbx-conv.exe -a your_mesh_name_here.fbx
使用“-a”参数后，工具会同时导出mesh的二进制文件(.c3b)和文本格式文件(.c3t)。文本格式的文件非常的有用，你可以利用它来查看所有的东西是否被正确导出，但千万不要把它放到resource目录下。如果所有的都被正确地导出的话，你将在c3t文件的开头看到以下的内容：
“attributes”: [{
“size”: 3,
“type”: “GL_FLOAT”,
“attribute”: “VERTEX_ATTRIB_POSITION”
}, {
“size”: 3,
“type”: “GL_FLOAT”,
“attribute”: “VERTEX_ATTRIB_NORMAL”
}, {
“size”: 2,
“type”: “GL_FLOAT”,
“attribute”: “VERTEX_ATTRIB_TEX_COORD”
}, {
“size”: 2,
“type”: “GL_FLOAT”,
“attribute”: “VERTEX_ATTRIB_TEX_COORD1″
}]
注意VERTEX_ATTRIB_TEX_COORD1这个属性。如果没有它光照贴图将无法显示。如果你导出了一张带顶点颜色的mesh，你也应该要看到一个类似的属性才行。还有一点很重要，贴图的坐标也必须按正确的顺序才行。我通常采用的是第一个tex_coord是瓦片贴图，最后一个tex_coord是光照贴图。使用Modo的话，uv maps会按照字母顺序排列。
着色器（Shaders）
我花了很长的一段时间来搞懂GLSL和着色器，但正如编程中经常遇到的，有时候一个点通了，其他的就都好理解了。一旦理解了其中的原理，你便会发现着色器真的很简单。如果你不只是想用Cocos 2d-x来把贴图套到模型网格上的话，你需要学会如何写着色器。目前Cocos 2d-x没有Unreal那样好用的着色器可视化编辑器（visual shader editor），所以我们只能自己动手焊代码。
本节我将讲解我为视频中的游戏场景所写的着色器，并说明我做了什么、为什么这样做。如果你对着色器已经非常熟悉了，那么可以快速跳过本节。
首先，先来看一下如何将着色器应用到模型网格上。
这段代码摘自Cocos 2d-x的测试集cpp-tests工程。如果你用不同的着色器来加载大量的meshes，那么最好根据功能来进行，这样可以避免冗余。那么现在我们只关心如下的代码段，来看下这个着色器。
GLProgram* shader =GLProgram::createWithFilenames(“shaders/lightmap1.vert”,”shaders/lightmap2.frag”)
GLProgramState* state = GLProgramState::create(shader)
mesh->setGLProgramState(state)
Texture2D* lightmap =Director::getInstance()->getTextureCache()->addImage(“lightmap.png”)
state->setUniformTexture(“lightmap”,lightmap)
“lightmap1.vert”是顶点着色器（vertex shader）。如果将其应用到网格上，那么每个顶点的每一帧都将执行这个 *** 作。而“lightmap2.frag”是片段着色器（fragment shader），网格上贴图的每个像素的每一帧都将执行这个 *** 作。我不太确定为什么将其命名为“片段着色器”，我一直认为应叫做“像素”着色器（pixel shader）。从这段描述，我们可以很容易理解为什么大量着色器指令会降低帧率，尤其是你用片段着色器的话。
接下来我们详细地分解顶点着色器：
attribute vec4 a_position
attribute vec2 a_texCoord
attribute vec2 a_texCoord1
这些属性是由渲染器提供的。“a_position”是顶点的位置。“a_texCoord” 和 “a_texCoord1”对应你那两个UV坐标。还记得在.cbt文本格式文件中开头部分的“VERTEX_ATTRIB_TEX_COORD”么？这些值与属性对应起来了。你可以在渲染器中获取更多其他的属性，包括顶点法线（vertexnormal）和顶点颜色（vertex color）。请在cocos引擎的CCGLProgram.cpp中查看完整属性列表。
varying vec2 v_texture_coord
varying vec2 v_texture_coord1
“varying”值将被传到片段着色器中（fragment shader）。片段着色器所需要的任何变量前都需要添加“varying”限定符。这个例子中，我们仅需要知道这两个贴图的坐标。
void main(void)
{
gl_Position = CC_MVPMatrix * a_position
v_texture_coord.x = a_texCoord.x
v_texture_coord.y = (1.0 – a_texCoord.y)
v_texture_coord1.x = a_texCoord1.x
v_texture_coord1.y = (1.0 – a_texCoord1.y)
}
设置顶点位置，拷贝贴图的坐标给varying values，这样片段着色器就可以使用这些值。现在我们一起来分解片段着色器。
#ifdef GL_ES
varying mediump vec2 v_texture_coord
varying mediump vec2 v_texture_coord1
#else
varying vec2 v_texture_coord
varying vec2 v_texture_coord1
#endif
声明从顶点着色器传递过来的“varying” 值
uniform sampler2D lightmap
还记得在将着色器应用到网格时所使用的 state->setUniformTexture(“lightmap“,light map)语句么？这个值就是对应语句中的那个贴图。
void main(void)
{
gl_FragColor = texture2D(CC_Texture0, v_texture_coord) *(texture2D(lightmap, v_texture_coord1) * 2.0)
}
这个语句设置像素颜色。首先你会注意到从未声明过的 CC_Texture0变量。Cocos 2d-x中有大量可在着色器中使用的默认统一变量。再次强调，可在CCGLProgram.cpp中查看完整属性列表。这个例子中，CC_Texture0对应在3D模型中所应用到网格中的贴图。texture2D命令会在给定的贴图坐标中去查找贴图的像素颜色和透明度。它会返回一个包含了那个像素的RGBA值的vec4值 。所以这里我会在UV1中查找到瓦片贴图的颜色值，然后在UV2中查到光照贴图的颜色值，最后把两个值相乘。
你应该注意到了我先是把光照贴图的颜色值两两相乘了。因为贴图颜色值范围为0.0-1.0，所以很显然，如果用白色值vec4(1.0, 1.0, 1.0, 1.0)去乘中间灰值vec4( 0.5, 0.5, 0.5,1.0 )，那么你仍是得到一个中间灰值vec4( 0.5, 0.5, 0.5,1.0 )。将两个值相乘可以使贴图更亮，同时也可以使贴图更暗，这将使你获得一个很好的可变的亮度范围。
1，测试环境
2，为何drawcall多会影响性能
3, 哪些组件支持渲染
4，影响drawcall的因素
5，一句话介绍如何减少drawcall
6，哪些渲染组件不会被渲染
7，减少drawcall的理论（放在第二期）
8，理论指导实践，实践印证理论，demo实 *** （放在第三期）
9，总结（放在第三期）
「测试环境」 :
1.Mac 系统
2.cocoscreator 2.4.x版本
「为何drawcall多会影响性能？」
Drawcall: 绘制调用，指cpu调用图形绘制接口命令gpu进行图形绘制
「每一次绘制前，CPU要准备绘制参数(状态)比如色彩通道(color filter)，绘图方式(shader)等复杂的数据处理，然后Drawcall,如果有大量drawcall，cpu会很“忙”,而gpu的处理能力很强，这时他可能闲置，不能充分发挥应有的能力，导致性能下降。」
「哪些组件支持渲染：」 因为一个drawcall是一次cpu调用图形绘制接口命令 gpu进行图形绘制渲染的过程，所以需要了解cocoscreator中哪些组件支持渲染，才能更好的控制drawcall
**
「影响drawcall的因素：」
1,层级(zindex)
2,材质(Material)（shander,贴图（纹理），混合模式（blend））。只有拥有相同材质的渲染节点 才可能进行批处理，贴图，shader 决定了材质，而层级则决定了相同的材质 是否能 进行合并处理 即合并网格（mesh） 合并drawcall.，
「一句话介绍如何减少drawcall：」 绘制状态的变化 是导致drawcall增多的 主要原因。cocoscreator认为要以深度(zindex)优先的方式对渲染组件进行渲染，并且cocoscreator认为相同的材质可以被批量渲染。所以具有相同材质的并且连续的渲染节点 可以合并渲染 减少drawcall.
「连续：」
1,层级相同添加顺序相邻，
2,层级不同 中间层级没有其他材质的渲染组件。比如 a的层级是1 b的层级是3 在 1-3层级之间没有其他材质的 渲染组件.
「影响drawcall的因素:」
「1，渲染节点（zindex）层级」
zIndex是节点的层级是用来对节点进行排序的关键属性，它决定一个节点 在兄弟节点之间的层级，和谁被优先渲染。
1） zIndex 的取值介于 cc.macro.M IN_ZINDEX 和 cc.macro.MAX_ZINDEX 之间
即 - math.pow(2,15). 和 math.pow(2,15)-1之间。
实际 *** 作中一般是 -1 到 n n一般不会超过1000
2）父节点主要根据节点的 zIndex 和添加次序来排序，拥有更高 zIndex 的节点将被排在后面（后被渲染先被渲染的图在后被渲染的图下面)，如果两个节点的 zIndex 一致，先添加的节点会稳定排在另一个节点之前。排在前面的节点先被渲染，也就是说两张图层级相同 先添加的会先被渲染 显示出来的结果是 在后被渲染的图的下面。
3）节点在 children 中的顺序决定了其渲染顺序。父节点永远在所有子节点之前被渲染
4)node节点放在Canvas或者父节点的zindex默认值是0
5）决定节点层级的另一个因素是siblingIndex 他的权重低于 zIndex 当我们在编辑器上编辑借点的时候 兄弟节点之间的zIndex相同，为什么会出现一个先被渲染一个后被渲染呢 ，就是因为 siblingIndex 不同，排在前面的siblingIndex要小一些后面的要大一些 最终后面的后选择然 层级就在 前面的上边。 也就是说 zindex 其决定性作用，zIndex相同 就比较siblingIndex来判定最终层级。
「2，材质」
1）纹理（贴图）
2）shander：渲染器，能够读懂的点和颜色的对应关系的程序，简单来说就是绘图的方式)
只有拥有相同材质的物体才可以进行批处理。因此，如果你想要得到良好的批处理效果，你需要在程序中尽可能地复用材质和物体。
如果你的两个材质仅仅是纹理不同，那么你可以通过 纹理拼合 *** 作来将这两张纹理拼合成一张大的纹理。一旦纹理拼合在一起，你就可以使用这个单一材质来替代之前的两个材质了。
「哪些渲染组件不会被渲染」
cocoscreator 认为 透明度 === 0. 或者 active = false 的渲染组件 不会被渲染。
机缘巧合，最近接到关于游戏的需求，前后调研了一下Unity3D和CocosCreator，但是考虑到是作为项目的一部分而使用，并且局限于Unity3D的使用条款，为了避免法律问题，最后选择的是使用CocosCreator来实现。第一次接触Unity3D和CocosCreator这类的游戏引擎，大约用了一个月的时间，从学习到项目大部分完成，之后要打包成静态库供其他客户端的同事们使用。学习途径主要是CocosCreator官网文档和官方Demo（看中文的文档就是爽！！！）。本片文章的目的主要是记录一下过程中遇到的问题及解决方案，并不是完整的教程。
本次要做的是一个最简单的跑酷类游戏，无需使用Tiled（地图编辑器），spine（骨骼动画编辑器）。也是做了这个小游戏才发现游戏其实已经发展的很成熟了。
我们可以看到，元素很简单，背景主要有远景、中景，通过设置不同的速度来实现现实中跑动的效果。主要的逻辑实现部分是在前景的任务和障碍物。由于没有使用物理引擎，所以是直接使用CocosCreator的碰撞检测实现的。主人公可以跳跃越过障碍物，撞开障碍物，收集金币。按住屏幕，hero跳起，按的时间长一些，主人公的跳跃也会高一些，自然一些的话还是需要简单的物理公式的。正常情况下hero是在x轴上是没有速度的，一种情况是当障碍物挡住hero时会有一个和障碍物同样的速度模拟阻挡的效果，还有一种情况是阻挡产生之后hero产生了位置上的移动，需要一个速度回到原位置。由于CocosCreator提供了碰撞检测之后的回调函数，所以我们可以很轻松的在回调中做一些相关 *** 作，比如让碰到的金币消失之类的。
有位同事做过cocos2d-x的开发，使用的c++，向他请教了一些基础了知识，但是细节上跟cocosCreator相差恨远，因为cocosCreator是用cocos2d-js框架并配合可视化的编辑器来实现的。由于是先调研的Unity3D，对这种脚本的方式还是比较能够接受的。其核心思想是在组件，在编辑器中制作精灵和动画，然后通过脚本组件来控制其逻辑实现，各种功能都组件化，当我们需要给精灵添加一个功能的时候，就是向其添加一个组件。在这个小游戏的制作过程中用的组件的数量也是有限的，主要是使用了：
编辑器给我们提供了方便的拖拽界面，直接将我们需要使用的图片导入，就会自动生成精灵文件（但是用过Unity3D之后，还是感觉Unity3D的功能集成度更高一些，而且还可以做3D）。
在编写脚本的时候也是不能脱离编辑器的，在编写脚本的时候着实是让我这个ios程序员有点摸不到头脑了，JS的使用方式有点让我不太适应，没有了xcode的提示功能，写起来还是有些费劲的。JS也是边学边写，不过得益于官方的Demo几乎把所有组件都写了一遍，所以就照着葫芦画瓢。写的时候就发现，其实引擎并没有帮我们做很多的工作（Unity3D可以直接在编辑器里设置物理属性，不过听说下个版本的CocosCreator也会有）。在编写脚本的过程中，最复杂的就是hero脚本的编写，需要检测碰撞和处理hero跳跃过程中的不同状态。碰撞检测的话需要自己计算碰撞发生的位置，当做矩形碰撞器来处理的，只计算x轴和y轴的碰撞。x轴发生碰撞的话，hero有一个和障碍物一样的速度，y轴碰撞一直持续的话就是调整hero的y轴的位置，让其在障碍物的顶部。跳跃的过程中完成动画的切换。
与CocosCreator编辑器不同的是，这个编辑器是我写的一个生成障碍物的一个app，可以方便让产品配置障碍物的位置。主要的实现思路是使用UICollectionView，界面非常的简单,主要是配合CocosCreator脚本的实现，需要将颗粒状的障碍物连成一个长的条状，所以需要将界上的障碍物颗粒结构化一下，取到障碍物的最底部的颗粒的位置，然后连接在一起的高度，这样的话就是对每一列的统一种类的障碍物进行深度优先搜索，记录最低点和搜索过的深度，这样的生成的JSON文件在CoCosCreator脚本里就可以直接使用了。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）