1: Particle Systems: More Fun and Easier Than You Think in Objective-C

Encoder Denso QR Bar Code in Objective-C 1: Particle Systems: More Fun and Easier Than You Think

You are going to be drawing a whole slew of textured quads onto the screen. However, generally a quad is only four vertexes. So, what is up here You are going to be rendering all your particles in the same draw call, and they are not connected, so you will need to figure out a good way to draw them all. If you use GL_TRIANGLES, then you are basically just draw each triangle individually. Every quad is just two triangles and six vertexes. This has the advantage of being very simple to program. You could also use GL_TRIANGLE_STRIP and connect each quad with degenerate triangles. A degenerate triangle is a triangle where the three points lie on a line. You can see in Figure 1-8 how this works. A triangle with colinear points has no area, so the renderer will throw it out. The easiest way to connect two meshes with a degenerate triangle is to just duplicate the last vertex of the first mesh and the first vertex of the second mesh and then add them together. This basically inserts two colinear triangles into the strip so that the rendered effect is two separate quads. This means, on average, each quad requires six vertexes, just like the GL_TRIANGLES method.

Figure 1-8. With GL_TRIANGLES, you have two separate polygons drawn individually. With GL_TRAINGLE_STRIP, all the polygons are connected, so you have to basically put two degenerate triangles in between the two separate quads.

Using degenerate triangles makes the code just ever so slightly more complex for very little practical gain. I always pick the simpler of two choices, so you are going to stay with GL_TRIANGLES in this chapter.

You have preloaded your particles, so now you need to assign your textures:

-(void)setParticle:(NSString*)atlasKey { BBTexturedMesh * quad = [[BBMaterialController sharedMaterialController] quadFromAtlasKey:atlasKey]; self.mesh = [[BBTexturedMesh alloc] init]; [(BBTexturedMesh*)mesh setMaterialKey:quad.materialKey]; [(BBTexturedMesh*)mesh setAtlasKey:quad.atlasKey];

You will grab a prebuilt quad from the material controller (more on this in a moment). You don t want to set your mesh to be the same as the quad s mesh because you are going to be mucking with the internal bits of our mesh. Instead, you will make a fresh one and copy over the parts you care about:

// need to calculate the min and max UV CGFloat u,v; NSInteger index; minU = minV = 1.0; maxU = maxV = 0.0; CGFloat * uvs = [quad uvCoordinates]; for (index = 0; index < quad.vertexCount; index++) { u = uvs[index * 2]; v = uvs[(index * 2) + 1]; if (u < minU) minU = u; if (v < minV) minV = v; if (u > maxU) maxU = u; if (v > maxV) maxV = v; }

To be as efficient as possible, you will be building the UV coordinate array alongside the vertex array during the update phase. To do this, you will need the min/max of your UV coordinates. You calculate those from the texturedQuad and store them for later:

mesh.vertexes = vertexes; [(BBTexturedMesh*)mesh setUvCoordinates:uvCoordinates]; mesh.vertexStride = 2; mesh.renderStyle = GL_TRIANGLES; }

Lastly, you point the mesh vertexes and UV coordinates back at your big buffers that you have already malloced. OK, there is something called a mesh and a material controller that I haven t really talked much about. The mesh is basically just a holder for the OpenGL vertex data arrays. The render controller uses the mesh to do the final rendering. That is why you need to give it information like the renderStyle and the vertexSize.

The material controller is a handy class that does all the heavy lifting for loading and processing texture atlases. In this case, you have a texture atlas file called particleAtlas.png and a texture metadata file called particleAtlas.xml. The XML file contains the information required to generate the UV coordinates for all the images in the atlas. The material controller loads all those textures when the scene is loaded and stores them in a string-keyed dictionary. So, to get a textured quad from the atlas, you just ask for it by name, like so:

BBTexturedMesh * quad = [[BBMaterialController sharedMaterialController] quadFromAtlasKey:atlasKey];

In this case, the quad will be the particle texture that you want to associate with this emitter. OK, now you want to set up the update loop in the emitter:

-(void)update:(NSTimeInterval)deltaTime { [super update:deltaTime]; // update active particles -> move them for (BBParticle * kid in childrenParticles) [kid update:deltaTime]; // build arrays [self buildVertexArrays]; // emit -> add new particles [self emitNewParticles:deltaTime]; }

It s a simple loop: update the current particles, and emit new particles. Changing the order that you call these methods will have very subtle effects on the working of the emitter, but mostly any order will work just as well as the next. For instance, I could emit new particles before I build the arrays. This means that the new particles will get rendered for one frame before ever moving. This might be what you want. I have put the emit last so that those particles will not get rendered until they have been updated at least once.

-(void)buildVertexArrays { vertexIndex = 0; for (BBParticle * particle in childrenParticles) { // check to see if we have run out of life, or are too small to see // and if they are, then queue them for removal if ((particle.life < 0) || (particle.size < 0.3)) { [self removeChildParticle:particle]; continue; // skip to the next particle, no need to add this one }

This is the heavy lifting method of this class. This is where you do the real work of taking all your particles and making OpenGL-compatible vertex and UV arrays. You first reset vertexIndex, which is the instance variable that will keep track of where you are in the arrays, so it is pretty important.