Shaders… The Last Frontier

I can’t remember the first time I promised myself to add shader support to the engine. I even bought a couple of books about it a some years ago. But for some reason it always ended up with the lowest priority. Now I have the chance to redeem myself once and for all. Sort of 🙂

First of all, I’m going with GLSL since I wanted something multi-platform that it can be used on the iPhone as well.

As for the engine, I made some changes to the Renderer class in order to work with shader programs. It’s pretty much the same thing I do for textures: load the program for the first time and then use it repeatedly during the frame update. The program is released automatically when it’s no longer used.

It is also possible to use uniform variables for our programs, although multi-pass rendering is not yet supported.

In order to handle shader programs, I use the ShaderEffect class. Just create a ShaderSource object for each of your shaders, indicating whether your creating a vertex or fragment shader. Then attach them to a ShaderProgram object. Here’s some code extracted from the GLSLSimple example:

And some screenshots:

Pretty simple, yes, but it’s a start. I’m planning on doing some interesting things during the next days like lighting and shadows. Stay tunned.

Terrain Lighting

It’s time to take a break from optimizations and to aim to a more user-friendly feature: Terrain Lighting. Although there are several approaches to accomplish this goal, I’ve chosen a simple, yet effective, technique known as Slope Lighting by which the color of a vertex is calculated by considering the height of its neighbors.

My implementation is based on an article written by Philip Dutré for GameDev.net. Below is a sample of a lightmap generated using this technique along with the resulting landscape with and without textures.

 

The lightmap applied to the terrain

 

 

And the texture

 

 

The final result

 

As you can see from the images, the results are far from perfect. The current implementation does not calculate soft shadows and there are artifacts in the shadow edges, but that’s acceptable for the moment.

About the iPhone Extensions

Some of you might have hear about DogFighter, a flight combat game created by TeraCode Games for the iPhone and iPod Touch. If not, check this video out.

DogFighter was the first commercial game based on Crimild. As part of the development team for that game, one of the many things I learnt from it was what works for an iPhone game and what doesn’t in contrast with a typical PC game. My experience with DogFighter left me with several “do” and “don’t” lessons that lead me to create the iPhone extensions for Crimild.

Simply put, the iPhone extensions are a series of classes and tools that make a developer’s life easier when attempting to port Crimild projects to that particular platform:

CrimildGLESRenderer

As the name suggests, this renderer implementation is based on OpenGL ES. In particular, this renderer supports OpenGL ES 1.5, which is the version we can find in any iPhone or iPod Touch. At the moment of this writing there is no OpenGL ES 2.0 support, but considering the power that vertex and pixel shaders provide for a game engine, it has become one of the major tasks to tackle once I finish my review on the Terrain library.

CrimildView

Derived from UIView, this class provides all of the mechanisms required in order to setup a proper drawing context. It configures the OpenGL ES context and the CrimildGLESRenderer itself.

CrimildViewDelegate

Following the iPhone design patterns, the CrimildViewDelegate protocol defines the methods that a class needs to implement in order to configure, update and shutdown a Crimild application.

Here’s a screenshot of the Terrain demo working on the iPhone Simulator:

The terrain demo working on the iPhone Simulator

That’s it for now. Stay tuned for more insights about the iPhone extensions.