Download the 3D Model: BuildShip.obj

Currently the Nice3D engine does not support shader other than the one in GLKit. Sure, own shader handing is a must have for a modern 3d engine, but Nice3D is not there yet. The other side is a skinning shader alone would not make the creeps walk. It would need to be fed by bone transformations and vertex weights. To get these structures I would have to use an other model format than Wavefront OBJ. I have a COLLADA loader (which would do the trick) integrated into Nice3D already, but it outputs some strange results.

So, how is it actually done?

The animations are done via vertex and normal morphing between keyframes. All keyframes are stored in separate OBJ files. Only vertex positions and normals are exported to the keyframes. The walk cycle for instance is compound of three different keyframes. But still, smooth animation is possible. It is just the matter of interpolating vertex positions and normals between the keyframes. This is how animations were done in Quake II those days.

The technique has some downsides. You can get wobble effects if you rotate joints of your 3d character and are using too few keyframes. An other downside is the fact that storing the keyframe requires of course way more space than storing a skeletal pose. Finally I should not forget to mention, that you need to cache the interpolated animations on the iPad for performance reasons. This leads to more memory consumption and hence less free memory for other fancy things.

The OpenGL profiler in XCode Instruments is quite a nice tool. It records all OpenGL calls and sorts them for performance optimization possibilities. This is a very convenient way to find:

• redundant API calls
• render calls where you should have used indexed rendering
• render calls where you should have used interleaving
• unnecessary state query calls

Instruments shows you what call is redundant and a stack trace to the  invocation in your code. At this point you should know, that redundant OpenGL calls can hurt performance and you should avoid unnecessary OpenGL state changes.

And here comes the scary thing! Almost all redundant OpenGL calls are not from my code but from GLKit. There is for instance every frame a call to glViewport(), even when it does not change. But that is not the serious performance killer. Every time you bind a shader via GLKBaseEffect you get a ton of redundant API calls to OpenGL.

To name a few, there is every time a call to glActiveTexture(), glBindTexture(), glVertexAttrib4fv() and a lot of calls to glUniform4fv().

But this is not Apple’s fault. It is just the fact, that if you want to reduce redundant OpenGL calls, you have to track the OpenGL state and decide if your call would be unnecessary. GLKit is not a engine and therefore cannot track the OpenGL state.

The conclusion is simple. I have to build shader management into the Nice3D engine and kick GLKBaseEffect out. That way the engine gains control over the state changes involved in shader apply and can easily sort out redundant API calls. This would also solve a problem that I have in memory management (see First Memory Profiling).

Note to myself: Nice3D shader management is desperately required. Not only for the above performance issues but also for skeletal animation and nice terrain rendering.

The first and simple one, was just the fact, that even though WOT is an ARC (automatic reference counting) project, you should still have some thoughts on autorelease pools in loops. This works now with the @autoreleasepool blocks.

The second memory issue was unexpected for me. The engine design was chosen the way that every mesh object contains its own GLKBaseEffect shader object. The GLKBaseEffect is the shader class from GLKit by the way. I thought that the GLKBaseEffect would surely somehow cache compiled shader and share them over all instances. But this seems not to be the case. Every time a mesh is cloned to create a new instance of a scene object, the shader in that mesh gets copied, too. But this is finally the reason for a huge memory increase. By huge I mean some value around 500 KB per shader object.

Sine every tower in the game contains at least one mesh and hence a GLKBaseEffect instance, you are not able to place more than 40 towers before you receive the first memory warning.

Long story short, the engine design has changed a bit to work around this memory issue. Every mesh now has to store textures and colors and some other material information, but not the GLKBaseEffect itself. The shader object is now part of the renderer state and exists only once, like a singleton. Before the renderer draws a mesh, it has to apply textures and material information to the shared shader.

In the near future, when I will implement a additional shader handling to the engine, I could move the shader back to the mesh. I think it is more elegant to have the shader assigned to the mesh. But I will have to cache shader programs over all shader object instances to avoid the memory effect from the GLKBaseEffect.