Home > Articles > Programming > Graphic Programming

Simplifying 3D Graphics Programming for iOS with GLKit

  • Print
  • + Share This
  • 💬 Discuss
Expert developer Erik Buck, author of Cocoa Design Patterns and the upcoming Learning OpenGL ES for iOS: A Hands-on Guide to Modern 3D Graphics Programming, talks with InformIT Senior Editor Dustin Sullivan and explains how Apple's GLKit can help you design your iOS code for optimal graphics performance with minimal effort and overhead.

Dustin Sullivan, InformIT: What is GLKit?

Erik Buck: GLKit is a new framework introduced in iOS 5. It's a collection of C functions and Objective-C classes that simplify 3D graphics programming for iOS. To understand the role of GLKit, consider the landscape without it:

iOS supports two largely incompatible libraries for hardware accelerated 3D graphics. The first, OpenGL ES 1.1, is called "fixed-function" because it provides a fixed set of functions for generating 3D graphics. Some of those functions are very powerful and help you get a basic 3D application up and running quickly, but no finite set of functions will ever meet every need. In contrast, OpenGL ES 2.0 is "programmable" in the sense that custom programs written in the "C like" OpenGL ES Shading Language can run directly on the Graphics Processing Unit (GPU) within iOS devices. The problem is that OpenGL ES 2.0 doesn't include most of those powerful functions present in OpenGL ES 1.1. You have to write custom Shading Language programs to get even the most basic graphics output.

Prior to GLKit, iOS application developers faced with a critical decision: Which version of OpenGL ES should be used knowing that porting an application from one version to another is difficult? OpenGL ES 1.1 is the past and OpenGL ES 2.0 is the future, but 1.1 gives you so much capability for free and 2.0 requires huge upfront effort. OpenGL 2.0 has the potential to generate graphics faster than 1.1, but if you are a novice at Shading Language, your custom programs may run slower than the optimized 1.1 functions built and refined over decades by experts.

GLKit works regardless of whether you choose OpenGL ES 1.1 or OpenGL ES 2.0. If you write your code to use GLKit, porting from one to the other is so trivial, you may not need to alter a single line of your code.

IT: Is GLKit a compatibility layer?

EB: GLKit certainly provides a compatibility layer, but it's much more than that. It's a higher level programming interface for 3D graphics. GLKit provide Objective-C classes to make programmers more productive in the same way Cocoa's Objective-C classes make programmers more productive. GLKit contains powerful reusable components. GLKit reduces the amount of code needed to write sophisticated 3D applications for scientific modeling, augmented reality, image processing, and games. I'd say GLKit is on its way to becoming a complete game programming engine.

IT: So, does GLKit work above the level of OpenGL like Cocoa works above the level of Apple's old procedural Carbon frameworks?

EB: In a sense, that's true. Cocoa was originally a collection of cross platform frameworks built on top of the standard C Posix library of functions. Writing a program with Cocoa enabled trivial porting between flavors of Unix like Solaris, HP-UX, and OpenStep as well as Microsoft Windows. That was never the real reason to use Cocoa technology though. The real reason has always been to benefit from a huge improvement in programmer productivity. GLKit is still small and already improves programmer productivity. It's easy to imagine GLKit growing to become the Cocoa of 3D graphics.

IT: How does GLKit do that? How does it raise programmer productivity?

EB: GLKit encapsulates and standardizes many basic features that every 3D iOS application needs. For example, The GLKView class encapsulates all of the code infrastructure needed to integrate 3D graphics. It ties together Cocoa, Core Animation Layers, and OpenGL ES. The GLKViewController class encapsulates all of the code infrastructure needed for timing synchronized to display refresh, automatically manages resources, and provides iOS standard behaviors like orientation changes and suspension when a phone call comes in. Just those two classes eliminate hundreds of lines of code otherwise recreated for every 3D application, but more importantly, they standardize behavior. The alternative is for every developer to recreate expected behaviors, and some will inevitably implement the behaviors sub-optimally or outright wrong.

As another example, GLKit contains a standard math library for 3D graphics. These math functions may be called hundreds of millions of times per second, so it's critical for them to be fast. Anyone can download a free math library from the Internet, but Apple is uniquely positioned to make their library the fastest available on Apple devices. By inclusion in GLKit, Apple's assumes responsibility to debug and optimize the library. That's another few hundred lines of code no longer needed in every 3D application.

Note: GLKView, GLKViewController, and the math library implement features that don't exist in any version of OpenGL ES. GLKit is not just an abstraction layer for OpenGL ES. GLKit includes capabilities above and beyond.

And how could I fail to mention the GLKTextureLoader class? It makes it trivial to load and configure images called "textures" to make modern 3D graphics look realistic. That's another few hundred lines of code you don't have to write. GLKTextureLoader leverages Apple's tried and true Core Graphics framework in its implementation and insulates you from having to know that library too.

IT: You mentioned that GLKit is still small and may grow. How do you see it changing?

EB: For the first release of GLKit, I think Apple focused on making it easy to get a 3D applications up and running on iOS devices. That's particularly important because Apple wants developers to use OpenGL ES 2.0. GLKit eliminates one of the main reasons developers continued to choose the old 1.1 version. GLKit makes it just as easy to get started with OpenGL ES 2.0 as with 1.1.

I can see GLKit migrating to Mac OS X on the desktop. I don't know Apple's plans, but there's no technical reason for GLKit not to work on the desktop. Developers could then share a 3D code between iOS and Mac OS X.

Most of all, Apple is showing us the direction to the future. GLKit classes like GLKReflectionMapEffect and GLKSkyboxEffect provide powerful features long considered to purview of graphics wizards and game engine developers. GLKit implements them at a level high above OpenGL and makes them simple and accessible for anybody. Apple has barely scratched the surface. I imagine a future GLKParticleEffect class, a GLKArticulatedModelEffect class, and a GLKBillboardEffect class. Particles, articulated models, and billboards are all common wizard level 3D graphics components at like reflection maps and skyboxes. In fact, the examples for my new book, Learning OpenGL ES for iOS: A Hands-on Guide to Modern 3D Graphics Programming, include sample implementations of particle effects, articulated models, and billboards. The examples demonstrate graphics concepts explained in the book and implement some of the book's sample mini-games. I hope and suspect the samples foreshadow Apple's intentions. At least to me, they seemed like obvious extensions to GLKit.

IT: Is your new book about GLKit? Does it augment Apple's documentation?

EB: The new book is about modern 3D graphics programming for iOS devices. It's intended for programmers who want to learn 3D graphics starting from basic principles. It isn't really about GLKit, but GLKit is now the most modern and powerful way to use 3D graphics. The book uses GLKit classes and functions as a guided tour through the related 3D programming concepts. Some GLKit features are partially reimplemented in examples to reveal the underlying technology and concepts. After reading the book, I think you will have a thorough understanding of not only how to use GLKit but how to implement it too.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus