In my June 2006 Dr. Dobb's article "OpenGL and Mobile Devices" (www.ddj.com/mobile/187203532), I examined OpenGL ES, a subset of OpenGL for mobile devices. Since then, the world of mobile devices has radically changed. Mobile devices with 3D graphics are readily available, as are downloadable SDKs from Sony, Nokia, and others. And then there's Apple's iPhone and iPod Touch.
When first announced, what caught my attention was Steve Jobs saying that the iPhone was running a version of OS X. Like every other Mac developer, the first thought that ran through my mind was "I can write software for that thing."
The second thing that went through my mind was "If it's OS X, then it has to be using OpenGL" because OpenGL,the de facto standard for cross-platform real-time 3D graphics, is an integral part of the Macintosh operating system. All we needed was an iPhone SDK. Well, the SDK is finally available and it's a complete XCode suite—compiler and debugger, performance analysis tools, a desktop simulator, sample code, and really good documentation. Frameworks are available for all the core OS X technologies, plus iPhone/iPod Touch specific features such as a touch interface, camera, accelerometer, and (my favorite) OpenGL ES.
The iPhone and iPod Touch both support OpenGL ES 1.1. Of particular interest to me are Vertex Buffer Objects, a minimum of at least one user-defined clipping plane, point sprites, some point parameters (distance attenuation), mipmapping, vertex skinning, and an extension for using a texture as a background image. This is a very capable and feature-rich graphics API, and it's 100-percent hardware accelerated.
The Hardware
The graphics hardware behind the iPhone and iPod Touch is a PowerVR MBX Lite, which uses Tile-Based Deferred Rendering. (Sony Ericsson uses this same chip for some of its cell phones.) In addition to Apple's SDK, you should get the PowerVR developer's notes that include useful performance tips (www.imgtec.com).
There are a few limitations you should know from the start:
- There is no stencil or accumulation buffer.
- There are only two texture units.
- The maximum texture size is 1024×1024 (use power of two only).
- The maximum space for textures and surfaces is 24MB.
- Only 2D textures are supported.
- There is no software rendering fallback.
The PowerVR chip uses a full floating-point pipeline throughout. The OpenGL lighting model is fully hardware accelerated, and there is no need to use fixed-point values for either lighting and material values, or vertex data. For best performance, use directional lights instead of point lights when possible, and try to always use indexed strips for geometry submission. To minimize bandwidth, you can use unsigned byte values for colors, and either unsigned byte or shorts instead of floats for texture coordinates.
Mipmaps (optimized collections of bitmap images accompanying main textures that increase rendering speed) were not available with OpenGL ES 1.0, but are with 1.1. On the PowerVR hardware, bilinear filtering is considered "free", but you should limit the mipmapping mode to GL_LINEAR_MIPMAP_NEAREST for best performance. Loading textures with an internal format of 565 instead of 888 speeds things up, and (if possible) you may want to make use of the PowerVR's native texture compression formats of either PVRTC2 or PVRTC4.
One of the more interesting aspects of the PowerVR chip is that it uses Tile-Based Deferred Rendering (TBDR), in which all rendering commands are queued and no actual rendering occurs until all commands for a given frame are given. The rendering commands are then analyzed, geometry is sorted, and converted into strips. Rendering then occurs. You still need to sort by alpha for transparency, but sorting front-to-back to eliminate overwrite is no longer necessary. (This is somewhat like the "early-z" feature some desktop graphics hardware supports.)
While this has many performance advantages, there is one performance gottcha for desktop OpenGL developers coming to this platform—state changes can be very expensive. While reducing state changes has always been a staple of OpenGL performance techniques, many desktop systems only moderately benefit from excessive texture or other state changes. Nongaming applications typically ignore this advice completely, yet are still able to maintain relatively fast and interactive frame rates.
Not so on the iPhone. One of my personal rendering "magic tricks" involves swapping between mipmapped and nonmipmapped texture modes using the same texture object. When I tried this on my iPod Touch, it ran so slow at first that I thought I was getting a software fallback (which, it turns out, does not exist).
To get best results in a complex rendering (especially if you are making a game), you should architect your rendering code to sort geometry based on rendering state, and not worry about front-to-back sorting as is typical on desktop systems.
