I often tell people that I spend 10% of my time designing + coding, and the rest of my time number tweaking. The actual ratio may not be totally accurate, but I do spend an awful lot of time playing with sliders. Usually getting the exact behaviour that I want is simply a balancing act between lots (and lots (and lots (and lots))) of parameters. Getting that detail right is absolutely crucial to me, the smallest change in a few numbers can really make or break the look, feel and experience. If you don't believe me, try 'Just Six Numbers' by Sir Martin Rees, Astronomer Royal.
So as an example I thought I'd post the GUI shots for one of my recent projects - interactive building projections for Google Chrome, a collaboration between my company (MSA Visuals), Flourish, Seeper and Bluman Assoicates. MSA Visuals provided the interactive content, software and hardware.
In this particular case, the projections were run by a dual-head Mac Pro (and a second for backup). One DVI output went to the video processors/projectors, the other DVI output to a monitor where I could preview the final output content, input camera feeds, see individual content layers and tweak a few thousand parameters - through 41 pages of GUI!. To quickly summarize some of the duties carried out by the modules seen in the GUI:
configure layout for mapping onto building architecture and background anim parameters
setup lighting animation parameters
BW camera input options, warping, tracking, optical flow, contours etc.
color camera input options
contour processing, tip finding, tip tracking etc.
screen saver / timeout options
fluid sim settings
physics and collision settings
post processing effects settings (per layer)
tons of other display, animation and behaviour settings
(This installation uses a BW IR camera and Color Camera. When taking these screenshots the color camera wasn't connected, hence a lot of black screens on some pages.)
Check out the GUI screen grabs below, or click here to see them fullscreen (where you can read all the text)
Two new addons for openFrameworks. Actually one is an update, and major refactor, so much so that I've changed its name: ofxCocoa (was ofxMacOSX) is a glut-replacement addon for openframeworks to allow native integration with opengl and cocoa windowing system, removing dependency on glut. Has a bunch of features to control window and opengl view creation, either programatically or via InterfaceBuilder. http://github.com/memo/msalibs/tree/master/ofxCocoa/
loading multiple QTZ files inside an openframeworks application.
rendering to screen (use FBO to render offscreen)
passing input parameters (float, int, string, bool etc) to the QTZ input ports
reading ports (input and output) from the QTZ (float, int, string, bool etc)
passing Images as ofTextures to and from the composition (you currently can pass images as QC Images, but you would have to manually convert that to ofTexture to interface with openFrameworks)
How is this different to Vades ofxQCPlugin (http://code.google.com/p/ofxqcplugin/) ?
ofxQuartzComposition is the opposite of ofxQCPlugin. ofxQCPlugin allows you to build your openframeworks application as a QCPlugin to run inside QC. ofxQuartzComposition allows you to run and control your Quartz Composition (.qtz) inside an openframeworks application.
Here there are two quartzcompositions being loaded and mixed with openframeworks graphics, in an openframeworks app. The slider on the bottom adjusts the width of the rectangle drawn by openframeworks (ofRect), the 6 sliders on the floating panel send their values directly to the composition while it's running in openframeworks.
This is a set of C++ classes for solving and displaying real-time fluid dynamics simulations based on Navier-Stokes equations and Jos Stam's paper on Real-Time Fluid Dynamics for Games. The solver class has no dependencies on openFrameworks and can be used in any C++ project. The drawer class extends ofBaseDraws and contains an ofTexture for seamless integration with openFrameworks drawing routines. Also included in the addon is a ofxMSAParticleUpdater class which allows the fluid solver to be easily plugged into ofxMSAPhysics as a force field.
This is a library for solving real-time fluid dynamics simulations based on Navier-Stokes equations and Jos Stam's paper on Real-Time Fluid Dynamics for Games. While I wrote the library primarily for processing it has no dependency on processing libraries and the source can be used with any Java application.
Note: Everytime I mention iPhone, I am in fact referring to iPhone & iPod Touch running OS 2+.
Just posted a simple example application source code and walk-through which can be found here.
openFrameworks 006 is now officially released! You can download a fat package for your system from www.openframeworks.cc, mac/linux/windows and now iPhone. I do recommend you keep an eye on the ofxiPhone SVN for updates and fixes.
What is this and what does it do?
ofxiPhone (along with ofxMultitouch & ofxAccelerometer) are addons for openFrameworks 006+ that allow you to develop for iPhone in plain old C/C++ just as you would on a normal desktop (mac, linux, windows). This means using the normal testApp.h, testApp.cpp, main.cpp; setup(), update(), draw(), mousePressed(), ofImage, ofTexture etc. and any other C++ classes you may have created. It also means that you can reuse your exact same code running on your desktop (mac osx, windows, linux) unchanged on the iPhone by just copying across your testApp.h, testApp.cpp, main.cpp and other source or resource files you may be using.
ofxMSAPhysics is a C++ 3D particle/constraint based physics library for openFrameworks. It uses a very similar api to the traer.physics library for processing to make getting into it as easy as possible.
Version 2.0a is now available for testing.
Main features include
attractions (+ve or -ve)
replay saving and load from disk (temporarily disabled in current alpha release)
custom particles (extend ofxMSAParticle and add to the system)
custom constraints (extend ofxMSAConstraint and add to the system)
custom force fields (extend ofxMSAParticleUpdater and add to the system)
custom drawing (extend ofxMSAParticleDrawer and add to the system)
Over the years OpenGL has developed lots of different ways of sending vertex data to the graphics card: Immediate mode (glBegin / glVertex / glEnd etc.), Display Lists, Vertex Arrays, Vertex Buffer Objects etc. The first of these (Immediate Mode) is quite inefficient, so it's been dropped in OpenGL ES and depreciated in OpenGL 3.0. Instead we are to use Vertex Arrays or VBO's (Vertex Buffer Objects). They are way more efficient, but generally not as straightforward to setup and use.
For this reason I wrote a C++ class that wraps up the functionality of Vertex Arrays (and soon VBO's) in an immediate mode style syntax. I.e. you can carry on calling glBegin / glNormal / setColor / glTexCoord / glVertex / glEnd etc. but instead of sending the data on every function call, it just caches them all in client-side arrays, and sends it all in one go when you call glEnd(). Later you can call draw() to redraw the information you've put in. Thus improving performance on desktop systems, and allowing immediate mode style syntax on embedded systems such as the iPhone. (The previous post about the Meshulator uses this class).
A set of C++ template classes for doing various types of interpolations on data with any number of dimensions. You can feed the system an arbitrary number of data (data can be simple types like float, int or complex types like structs, classes), then resample at any resolution, or ask for the value at any percentage along the data - or just draw it - including splines in 3D.
This is useful for creating and drawing splines (in any dimensions), or creating smooth animation paths from keyframes (again, in any dimensions).