Cocoa Design Patterns
Learning OpenGL ES for iOS
Buy at Amazon Now
  • Cocoa Design Patterns
    Cocoa Design Patterns
    by Erik M. Buck, Donald A. Yacktman
  • Learning OpenGL ES for iOS: A Hands-on Guide to Modern 3D Graphics Programming
    Learning OpenGL ES for iOS: A Hands-on Guide to Modern 3D Graphics Programming
    by Erik M. Buck
« Downloading Keynote Presentations Exported as HTML | Main | "Learning OpenGL ES for iOS" has shipped »

Exploring GLKit for Mac OS X 10.8 Mountain Lion

Apple introduced the GLKit framework for iOS 5 a year or so ago. GLKit greatly simplifies programming with OpenGL ES and smooths over some of the differences between OpenGL ES versions making it easier to adopt the latest and greatest graphics technologies.

Mac OS X 10.8, Mountain Lion, brings most of GLKit to the desktop. That's great for the same reasons the framework is great for handhelds. It also makes porting from iOS to the desktop easier.

To get started with GLKit on the desktop, I ported the example program in my InformIT article, Adding Open Source 3D Physics to Your iOS Applications, from iOS to Mac OS X. While porting, I converted the example to a multi-document application with all the bells and whistles. Most of that sort of thing comes with no effort thanks to Xcode.

The InformIT article explains how the example works and how to integrate the Open Source Bullet Physics library with Cocoa/Cocoa Touch applications.


Note: The Mac OS X version of the example uses a custom PTEffect class instead of the GLKBaseEffect class that comes with GLKit. I was unable to get the GLKBaseEffect for Mac OS X to implement diffuse lighting or proper transformation matrix behavior. I'm still investigating, and if it isn't something I've done wrong, I'll submit bug reports to Apple. For right now, as far as I can tell, GLKBaseEffect for Mac OS X is broken or not fully implemented.

Reader Comments (9)

Did you ever figure out why GLKBaseEffect is not working? I tried some simple lighting with GLKBaseEffect in a separate project and it appeared to work correctly. When I tried replacing PTEffect with GLKBaseEffect in this project I just get a large white rectangle with green background surrounding it.
September 3, 2012 | Unregistered CommenterDavid
The short answer is that I haven't identified the specific problem, but I'm almost positive it is something in my code. I provided a slight update to the sample today, and I will continue to update the sample as I find problems with my implementation for OS X 10.8.
September 5, 2012 | Registered CommenterErik Buck
It appears you may have based this project on Apple sample code OSXGLEssentials which uses a CVDisplayLink to time rendering. In your project however you use an NSTimer instead. Was there an issue you ran into preventing you from using CVDisplayLink? Have you also considered hosting the project on Github?
September 5, 2012 | Unregistered CommenterDavid
The current version at this site no longer contains references to CVDisplayLink.

Apple clearly explains that CVDisplayLink is the best trigger for periodic display update in OS X.

For iOS, the equivalent technology, CADisplayLink, drives Core Animation and is used automatically by GLKit via GLKView and GLKViewController. It's the default in iOS.

So, why not use CVDisplayLink in this sample even though the iOS version implicitly uses CADisplayLink?

Answer: Because CVDisplayLink requires multi-threading and GLKit for OS X is not thread safe. It is theoretically possible to surround all OS X uses of GLKit and OpenGL with locks to avoid multi-thrading issues, but multi-threaded programming is never easy and needlessly complicates a sample intended to demonstrate GLKit. I may create an alternative sample intended to demonstrate correct uses of locks to protect critical sections of code.

Confession: I could not get the sample to work reliably when multi-threaded. If I fail to protect even one invocation of GLKit or OpenGL, the application will malfunction in unpredictable ways that are nearly impossible to debug. OpenGL is fundamentally designed to use "global" state via "contexts." The design is anathema to accepted best practices for multi-threaded programming. It's obviously not impossible to work around the issues, but it's damn hard.
September 6, 2012 | Registered CommenterErik Buck
Man, I've been trying to do this same thing, combining old GLEssentials code into GLKit and a cross-platform workspace. Mine isn't working yet though -- do you make your cross-platform code available?

October 29, 2012 | Unregistered CommenterBob
The iOS and OS X sample code for integrating Bullet Physics with GLKIt can be found at The accompanying article is at InformIT
October 29, 2012 | Registered CommenterErik Buck
OK, got it thanks! So it isn't a cross-platform project where the same code base compiles for OS X and iOS? That is my goal -- this gets me pretty close!

October 29, 2012 | Unregistered CommenterBob
Also -- the lighting is very different between the mac and iOS versions -- the mac has much blacker shadows. What is responsible for that difference, is it the PTEffect vs GLKBaseEffect, or something else?
October 29, 2012 | Unregistered CommenterBob
Very cool physics sample. Thank you Erik.

I think I got it to work with GLKBaseEffect. It seems that the OSX version wants to have a vertex array object bound (It seems an empty one works...) to draw anything, and it's also picky about setting the version of OpenGL to 3.2 and in the way the vertex buffer objects are bound. E-mail me if you want the code.
September 23, 2013 | Unregistered CommenterMarc

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.