Posts Tagged openFrameworks
I’ve been a Cinder devotee for about two years (almost as long as Cinder has been publicly available). I officially switched from openFrameworks because a project I was working on as a student at ITP made heavy use of GLSL shaders, which at the time were much easier to work with in Cinder. openFrameworks GLSL support has since improved greatly, but I’ve maintained my loyalty to Cinder because of its clean architecture, extensive core feature set and impressive sample projects.
Every few weeks, though, I find myself porting an openFrameworks addon to Cinder. And now that there’s ofxAddons, a site that tracks every addon on GitHub, my porting has become even more frequent. Some of these are easy enough. Vec3f becomes ofVec3f, ColorA becomes ofColor, etc. But more complex addons like ofxOpenNi or ofxAssimpModelLoader are time-consuming or difficult to port. Of course, the Cinder community has its own “addons” (which are instead called “Blocks”). But there are fewer of them, they often take longer to reach the community and in some cases they are harder to wrangle. Cinder’s OpenNi block in particular is a nightmare to get setup.
I believe the greatest strength of each framework is also its greatest weakness. openFrameworks is extensively documented and supported by a large and active community. This means a constant stream of new features, but also that the tools themselves sometimes feel like a disorganized hodgepodge. Cinder is supported by a smaller community, which is rigorous about API standards and best practices. However, this often translates to month-long forum debates that do not result in any new features. So we beat on.
I’ve learned a great deal about programming by reading the Cinder source code and that nagging feeling of wanting to do things properly and efficiently keeps me a Cinder devotee. But this week, something happened that changed my attitude: I met Polycode.
I’d been aware of Polycode since it first surfaced, but only gave it proper attention for the first time this week. I was looking for inspiration while implementing the 3D environment and scenegraph components of my software project, Foil. I was impressed with Polycode’s Assimp-based 3D model loader, scenegraph structure, Bullet-based physics simulation and overall architecture. For a moment, I considered making the switch. But then, I began to find that Polycode was extremely slow in loading large skeletal animation files and started looking elsewhere for solutions.
This brought me back to openFrameworks, which unsurprisingly has a very nice Assimp loader addon. My first impulse was to port ofxAssimpModelLoader to Cinder. After a bit of frustration and wasted time, I decided to put Cinder aside temporarily and try working in openFrameworks instead.
Within a day, I had connected ofxAssimpModelLoader, ofxBullet and ofxTimeline with openFramework’s built-in ofLight, ofCamera, etc classes to reproduce the majority of Polycode’s 3D model/skeleton, physics and animation functionality. Over the course of the next few days, I will integrate addons including ofxTerminal, ofxAssimpOpenNISkeletonSync, ofxOpenSteer/ofxPathfinding/ofxFlock, ofxParticleSystem, ofxFaceTracker and ofxOpenNi to produce a scriptable 3D modeling/animation/gaming environment, potentially called “ofxGoneWild” or maybe “ofxKitchenSink.” ofxAddons galore! There is some work in connecting these pieces and without a fair amount of C++ as well as Xcode experience, it would be difficult. Yet, given the volume of features that comes with these addons, it’s a pretty quick process.
I still love Cinder and will continue to work in it. But the draw of openFrameworks’ vast collection of addons is immense. The ability to build a custom physics-simulating, keyframe-animated 3D environment in a week is earth-shattering. It’s not Maya, but it’s an extremely good start. With the support of Assimp and Bullet, openFrameworks provides access to the same model loader and physics engine that are available in Maya 2013. So, for this project at least, I’m with openFrameworks.
(A very early screenshot of ofxGoneWild.)
A preliminary test using FaceTracker to control a virtual camera within a 3D gaming or design environment. With some tuning, the effect could be made pretty convincing. The biggest obstacle is that FaceTracker looses non-front-facing faces. Perhaps the face detection training model could be extended. Failing this, it might be helpful to supplement the FaceTracker data with Kinect skeletal tracking to smooth or approximate the head position when necessary.
For this version, I ported ofxFaceTracker to Cinder and wrote a simple camera control system to interface with FaceTracker data. By shifting control of the camera position towards a motion vector rather than pure position-driven approach, it should be possible to diminish the apparentness of brief drops in face tracking. Some turbulence forces might also mask a freeze in face-controlled camera data.
Using Jason Saragih’s FaceTracker library:
Adapted for Cinder from Kyle McDonald’s ofxFaceTracker:
My Cinder port of ofxFaceTracker is now available at: