Re: ObjC 3D engine
Re: ObjC 3D engine
- Subject: Re: ObjC 3D engine
- From: Erik Buck <email@hidden>
- Date: Mon, 25 Jun 2007 15:19:49 -0700 (PDT)
Cocoa mixed with OpenGL is an excellent approach for 3D graphics. Of course you don't use Objective-C objects to represent 3D vectors and matrices and other low level data structures. There are at least two reasons:
1) The overhead of the Objective-C isa pointer is significant when you are dealing with millions or tens of millions of tiny objects like vectors.
2) The OpenGL APIs require data in particular formats, and converting back and forth between Objective-C objects and those formats would be a pointless use of processor time.
Keep in mind that all the same issues apply to C++ as well. You wouldn't make a C++ class for vectors using virtual member functions because the resulting vTable pointer overhead would be significant. IMHO, if you have no virtual member functions, you C++ class is effectively the same C structure I would use with Objective-C.
So, what does Cocoa provide that makes it a well suited companion for OpenGL ?
First and foremost, nobody in their right mind uses OpenGL immediate mode. Effectively all interaction with OpenGL uses large buffers of raw data: e.g. vertex buffers, texture buffers, etc. Large buffers of raw data are easily encapsulated in Objective-C objects like Cocoas NSData. By using NSData and similar classes, the programmer gets easy load and store, reference counted memory management, and other free low level features. More to the point, NSData is easily stored in NSDictionary or NSSet or even in NSManagedObjects. With all of that interoperable infrastructure comes no-code undo/redo support, etc.
The higher level data structures used to manage 3D scenes are actually well suited to Objective-C implementations. There arent very many instances and they benefit immensely from Cocoas dynamism. For example, a scene graph implemented as a quad-tree or oct-tree is nicely implemented with Objective-C objects. When new scene nodes are created, they can easily be dynamically loaded (plug-ins) and added to the existing scene graph. I have seen several mature 3D engines jump through outrageous hoops in order to support dynamic loading of scene graph nodes, and it comes for free with cocoa.
Lots of common objects like cameras, frustums, etc. are nicely implemented with Objective-C. Just like with scene graph nodes, new camera classes can be dynamically loaded and used for free.
Then there are lots of Mac OS X features that arent strictly Cocoa but integrate nicely. For example, use NSOpenGLPixelBuffer in combination with Core Graphics and Quartz Composer and Quicktime to implement dynamic textures.
It has been my experience that Objective-C is fast enough for use in the 80% of your code that isnt on the critical render path. You get all of the dynamic goodness of Objective-C for no cost. The 20% of critical performance (low level) code needs to be written in C or a very restricted subset of C++ not so much because Objective-C methods arent fast enough but because OpenGL APIs require it that way and you dont want to be doing data conversions.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden