If you are here, then you probably shouldn’t be. As you can see, it has been quite a while since I last updated this blog. If you want to keep tabs on my work and processes, best to head over to my portfolio which I try to keep updated with any new work I create. Thank you.
I have been home from the fantastic Eyeo Festival for a full day and thought I should write up a few notes that I neglected to mention during my talk. I had intended to say this stuff out loud but as I ran out of time and since I had switched over to showing iPad content, I never went back to my presentation where I had a few extra notes and takeaways ready to go. So here they are.
Your first attempt at anything is likely going to suck. Let’s face it, most of us are not phenoms. In fact, I cannot think of a single person I have met in my 38+ years who was able to excel at something shortly after trying it for the first time. We all need practice, and lots of it, for everything we try. From learning to talk and walk, to learning to play an instrument, to learning to drive, to learning how to be a social creature… it all takes practice.
Want to know how to get better at something? Do it over and over. And over and over and over.
However, it cannot just be mindless repetition. There are two additional factors that need to come into play. You need to also do the following.
1) Correct. You should work on fixing the things that didn’t go right with the previous iteration. Make a list of the things you want to address. Tackle the big items when you have a clear head and a nice block of time. Otherwise, pick off the smaller ones. However, don’t get overzealous with your corrections. If you happen to mutate your project into something interesting but unintended, save this mutation so you don’t overwrite it. I have lost some nice bug-made oddities because I was too concerned with fixing errors.
2) Improve. You should research the field to try and learn things to add to future iterations. This means looking at what people have already done and also what people are trying to do. Staying on top of advancements in your field of interest is definitely worth the effort. Unfortunately, this may mean you find yourself looking over SIGGRAPH white papers or University theses that are over your head. This is fine. Don’t get too caught up with not understanding what is written. Just look at the pictures if that is all you can manage. The important thing is to continually expose yourself to information about your interests.
I don’t know how many of you played D&D as a kid (or as an adult… no judgement here) but I will speak now as if all of you have. When you roll up a new character, unless you cheat it is highly unlikely you will create a demigod. You might have a 18 here or a 16 there, but you will never ever roll up a character with an 18 for every attribute. Ideally you will have one high attribute, perhaps an 18 strength. With an 18 strength, you would make a fantastic fighter. So off into battle you go.
But life, fantasy or not, is never easy. Your first run-in with a couple filthy thieves results in a gash across your chest and you drop half your hit points and suddenly you start to suffer the reality of the situation. You need healing abilities. So what do you do? Well, you don’t go running to the library to start a multi-year process to learn how to cast a healing spell. Instead, you find a cleric who has an 18 wisdom but happens to suck at fighting and you join forces. Now, you are much more powerful than the sum of your respective skills.
And the beauty of this setup is that nobody feels like they are being taken for granted. The fighter has an intense appreciation for the healing abilities of his new cleric friend, and the cleric is thrilled to have found someone that can fight off the horrible monsters that lurk out in the wilds. So if you are a fighter, find yourself a cleric friend. If you are a cleric, track down some muscle for hire. Because if you don’t, you will live a limited life and never get to see what is on the other side of the dark forests at the base of Mount Craggyspire. Or whatever.
I have spent much of my coding career learning how to manipulate particles and figuring out how to make OpenGL make things pretty. But I suck at many other aspects of coding. Which is why the projects involving collaboration ended up being the most successful. The visualizers I have made with Andrew Bell, and the Planetary iPad app which I am currently developing with Bloom… those projects have meant the most to me and I am damn certain I would not have been able to make them on my own.
I went through a talk I gave in 2004 and saw a slide that, though a bit harsh, still represents the best advice I can give to young idealistic coders. It said, in bright red on white, TAKE TINY STEPS OR FAIL!!! and the FAIL!!! bit was flashing on and off for emphasis.
A problem I suffer (and hopefully it isn’t just me) is that I see something awesome someone else made and it gets my mind churning and I start thinking “I can totally do a 3D terrain simulation with physics, CLoD implementation, and realtime weather effects” so I dive right into XCode and start making my Globe class and the Weather class and on and on and before you know it, I feel extremely overwhelmed which usually has me running for the remote so I can watch science documentaries in an attempt to distract my bruised ego. Knowing exactly what you want to make can often be the largest barrier in your creative journey.
My advice in this situation is to take some time to break the problem up into bite size pieces. Work on little prototypes. Explore each tiny concept and eventually, start to put them together. If you are too focused on the gap between what you envision and what you currently have, you will likely lose faith.
Plus, if you have a bunch of well-understood bite size pieces, it will make it much easier to combine them into bigger projects. But if you start in with building a big project, it is much more difficult to pull out the pieces you want to repurpose later.
Take a walk or a shower
This may not work for everyone but it has been very useful to me. If I am stuck, either creatively or programmatically, I go for a walk. Or if it is late in the evening, I will take a hot shower. Something about those two activities really helps me clear away the mental fog and helps me to focus on the issues at hand. I have cleared many a hurdle just by putting on my headphones, slipping on some shoes, and going for a walk through the neighborhoods of San Francisco. This doesn’t mean walking over to the neighborhood bar for a drink. Walk while mulling over the problem at hand and head home when you have an idea of what to try next.
I realize what I am writing here is nothing new. We have all heard these points made by many. They have reached rockstar cliché status. But this doesn’t mean it isn’t worthwhile to be reminded every now and again.
Ira Glass on creativity: http://www.youtube.com/watch?v=BI23U7U2aUY
Frequently asked Questions
Should I learn Processing, OpenFrameworks, or Cinder?
Depends. On many things. Your skill level, your dedication, and your interests. It is important to say that it is not a matter of which framework you choose. It is much more about how much effort you are willing to put into it. Learning something new can be hard and I sometimes worry that when I am asked this question, what I am really being asked is “Which is easiest?” Unfortunately, coding is difficult. And as I mentioned above, there is no substitute for practice.
That being said, I usually answer Processing. Not because Processing is easy, though it is definitely easier than trying to learn C++. I answer Processing because Ben and Casey have made it part of their mission to create a framework that would make it as easy as possible for those with a less technical background to enter the world of creative coding. The first thing you learn in C++ is usually something like how to write text into the console. The first thing you learn in Processing is how to draw a circle. Coming from a visual arts background, I was far more interested in drawing circles. I still am.
This doesn’t mean learning Processing over a C++ framework will limit your work. This is especially true if you plan on doing a lot of graphics work with OpenGL. Generally speaking, OpenGL is OpenGL regardless of whether you are getting there through Java or C++. And with all the advancements that are happening to Processing (look for Processing 2.0 soon) it is definitely a fantastic tool to become familiar with. So when I started to look for an alternative to using Flash for my code experimentation, the answer was a resounding Processing. But if you are a bit more computer-minded are are willing to put in the long hours reading C++ books and searching Stack Overflow for obscure Xcode error messages and trying to wrap your head around the difference between pointers and references and the reasons to use one over the other, something like OpenFrameworks or Cinder might be right for you.
What is the difference between OF and Cinder?
Honestly, that is not something I can speak to as I have only used OF a couple times. It was shortly after the Mac version came out and it was alpha and unstable. It has come a very long way since those early days. However, I am definitely a Cinder person and would be happy to talk about all the ways in which Cinder is awesome. I just can’t fairly speak to how it compares.
How should I get started?
The first half of the Hello, Cinder tutorial covers the creation of a simple particle engine and shows how to use it to do algorithmic stippling. The second half turns the particle engine into a flocking simulation. It does so using a three-rule system first described by Craig Reynolds here. During my Eyeo talk, I forgot to mention Craig Reynolds seminal contribution to the field of flocking simulation and only referenced Ian Couzin’s work (discussed here at a Radiolab webcast).
Also, take a peek at a post I wrote last year. Much of what is mentioned there is still relevant.
Hope this helps!
I updated my profile. I tweeted. I informed friends. But I never quite got around to posting something on this oft-neglected blog. So, here it goes…
A couple months ago, I joined Bloom as the creative director. I am incredibly excited by this development. For most of 2010, I had been working from home on projects generally of my own design. Most of these projects are just explorations though a couple of them turned into interesting client work. But it was all just self-directed meandering and I really wasn’t learning much more as an artist. I was just exploring semi-familiar terrain.
Bloom approached me in February to contract me on an iPad project. I quickly became enamored with the project but more importantly I became enamored with the team. I had forgotten how rewarding it can be to work with like minds with differing skill sets. I preach collaboration at my speaking engagements but for most of 2010 I had pretty much been working solo (save a few Cinder-related projects with Andrew Bell and Hai Nguyen). Working with Ben, Tom, and Jesper (the Bloom team) really helped me get off my plateau and get to climbing again.
We are going through the final stages of dev for our first iPad app. We hope to have it in the App store late April. I will definitely post a longer process entry once this project is released.
If you have a Kinect and a Mac, you can download the Body Dysmorphia Kinect toy application. This is the first of many Kinect-based applications I plan to release over the next couple months.
Download here: http://flight404.s3.amazonaws.com/BodyDysmorphia.zip
Hello and welcome to my first Kinect toy: Body Dysmorphia.
• This application is currently only available for Mac.
• Plug your Kinect into a power outlet, then plug the USB cable into your computer. Wait a few seconds before launching the app. Once the green light on the front of the Kinect is visible (either blinking or solid), launch the app.
• Body Dysmorphia was created on a MacBook Pro 2.66 GHz Intel Core i7 with 8GB of memory. This is the only computer it has been tested on, but should work fine for any reasonably recent Mac.
• Body Dysmorphia was developed using Cinder C++ framework (http://libcinder.org).
• This app is presented as-is. I have not done any extensive testing.
TIPS FOR A BETTER EXPERIENCE
• Try to stand between 5′ and 10′ from the Kinect. I find this to be an optimal distance.
• Cover or remove reflective objects that might be behind you. Reflective or shiny objects will distort the depth data the Kinect receives.
• If you are in low light conditions, you can either adjust the app’s brightness using the ‘c’ key or switch to infrared mode with the ‘i’ key.
• Because the Kinect’s RGB camera and depth camera are offset from each other, their corresponding images do not align exactly. I have not figured out a great solution for it yet so I have added a parameter called ‘Texture X Offset’. It is probably not worth messing with this variable, but if you find the RGB camera image doesn’t quite match up with the 3D puffiness geometry, you can try adjusting this ‘Texture X Offset’ variable using the ‘x’ key.
• To toggle in and out of presentation mode, just hit the ESC key.
KINECT QUIRKS TO BE AWARE OF
• The Kinect doesn’t like pointing at shiny surfaces. When the Kinect tries to read the distance to a shiny surface, it gets confused and sends back horribly inaccurate data. This usually isn’t a problem but it can be the cause of some less than desirable visual oddities. If you see weird 3D data messing up the visuals, try situating the Kinect so that it isn’t pointing at any windows, monitors, metal, etc.
• The Kinect has a useful range between about 2′ and 20′ (don’t quote me on that, these are merely estimates based on how I use the Kinect). If any part of you is closer than 2′, it will disappear. If you move beyond 20′ or so, the depth data starts to blend together and the visual effect will be lessened.
Many thanks to wonderful minds behind Cinder, libfreenect, and OpenKinect.
I am pleased to announce that Cinder can now support all of your Kinect hacking needs. With the new Kinect CinderBlock, you can very easily obtain depth map and rgb image, and additionally control the Kinect motor. You can even change the LED color if you’d like. There is more information in the Cinder Forum including a link to download the CinderBlock from github.
I have been playing with the Kinect for a day now. It was incredibly easy to get started. You simply ask for a depthImage or colorImage from the Kinect object and it is returned as a texture. There are two samples with the Kinect CinderBlock. KinectBasic just retrieves these two images and draws them to the screen. You can also click in the app window to change the angle of the Kinect (via a motor hidden in the base of the hardware).
The second sample, KinectPointCloud, is a traditional 3D point cloud using a VBOMesh and GLSL shaders. It looks like this:
Since you are getting accurate and reasonably high res depth information for every pixel, it isn’t too difficult to generate a normal map. Since this is done in a shader, it is very quick. I did not make a blur pass because I wanted to keep the frame rates spiffy. This means the normal map isn’t excellent and it has some artifacting, but it’s good enough to get the job done.
Now that you have a normal map, you pass it to the final vert shader. You have each vert check its corresponding normal map value and you simply add this normal value to the position of the vertex. If your normals are correct, you should see something like the image below. I am using a ‘fatness’ uniform float so I can adjust it during runtime.
All thats left is to add back in the original color values and voila, instant fatsuit and extremely creepy late-night distraction. In order to push the creepy vibe, I am only drawing the frags that are within a certain distance to the camera. If they are background frags, I discard them entirely. This ends up being extra useful because the depth image from the Kinect has a bit of parallax shadowing on the side where the depth data goes to black. Eliminating the drawing of these unwanted artifacts will clean up the final image quite a bit.
Since you have remapped the normals back onto a webcam image, it is a trivial matter to create a lightsource and dynamically change the lighting of your realtime webcam input. For the following video, I have created a virtual swinging light source above my head.
Oh, and this library also supports two Kinects at the same time. I haven’t figured out how to use/abuse this knowledge, but I am certainly going to try. Realtime morphing between two people seems like an interesting first go. Maybe I will try morphing myself into my cat. Hmmm….
I have just released a new tutorial for Cinder. It is a 5 chapter addition to Hello, Cinder. It covers the creation of a flocking (or shoaling) system. I used the source code from this tutorial to make the following video.
The tutorial is based on the teachings of Craig Reynolds whose landmark 1987 paper on flocking behavior is still the foundation for most flocking simulations. It has also been influenced by the work of Iain Couzin of the Princeton Collective Animal Behavior lab. I particularly enjoy this short lecture he gave at the inaugural webcast of Awe-maggedon by RadioLab.
The flocking tutorial picks up where Hello, Cinder tour left off. In the first 5 chapters (section 1) of the tour, we create a 2D particle engine. The next 5 chapters (section 2) turn the particle engine into a 4 rule flocking system complete with predators.
Chapter 1 discusses the Cinder Camera class and explain how to create a 3D perspective camera. I also add a graphical interface that can be used to control parameters in real-time.
Chapter 2 introduces the first rule for our flocking simulation: Separation (repulsion). We show how to use a repulsive force to keep particles from getting too close to each other.
Chapter 3 explains the second rule: Cohesion (attraction). Now we show how to keep the particles from drifting too far away from each other.
Chapter 4 adds the third rule to the simulation: Alignment (orientation). The particles are now able to change their flight direction based on the flight direction of neighbors. The flocking behavior finally emerges.
Chapter 5, the final chapter, personalizes the rules and introduces a fourth rule: Evasion. Predators are added to the simulation. They chase after the particles by focusing on areas of high concentration. At the same time, Particles (prey) make every effort to flee from any nearby predators.
There is a source code Cinder project for each chapter so you can follow along with the tutorial. If you wish to dive right in and start playing with the flocking source, go straight to the Section 2: Chapter 5 source. It contains the same logic I used to make the Bait Ball video below:
The tutorial received much loving feedback and editing from Andrew Bell, Mike Creighton, and Noah King. Many thanks to them all. If you have any feedback, advice, or improvements, please contribute to the Cinder forum post, Flocking Tutorial.
You can download the source for the whole 10 chapters here or just grab it off the git repo.
The awesomely talented UCLA duo of Casey Reas (1/2 of Processing and come on, he has a 4 letter .com url. This guy is on the ball!), Chandler McWilliams (of The Barbarian Group and general art/philosophy brilliance), and the design/interactive shop LUST have teamed up to create a beautiful and expansive compendium of computational aesthetics. The book, entitled ‘Form + Code’, published by the Princeton Architectural Press, features an impressive collection of work. It is a must have for anyone finding themselves at the crossroads of art and technology. Not only is the book beautifully designed, but it is equally beautifully curated.
The book begins with a brief history of code and then showcases specific examples through the categories of repetition, transformation, parameterization, visualization and stimulation. You will likely see many examples that you recognize and hopefully, just as many which are new to you. I was happy to see ‘The Visual Thesaurus’ because it was the first website which made me see the artistic potential of code despite it being more of a reference site than an art site.
The Form + Code website is a good place to start. You can see some spreads from the book, list of contributors, and a bunch of code examples (written in Processing)… pretty much everything you need to get inspired. Also, check out the more thorough review by Rhizome.org.
The book is available from Amazon.com.
It has been a while since I have done a proper 50+ minute talk. Aside from the TEDx (18 minutes) gig up in the beautiful Canadian Rockies last month, I have been conference-free for what seems like ages. The second half of this year has me speaking at two conferences. First up is FITC being held August 17th-19th at the UCSF Mission Bay Conference Center.
My talk is entitled “Practice makes perfect, so what are you practicing” and you can read the description here. I have a pretty good idea of how the talk will unfold but I will continue to work on it up until the day of the event. I will talk about my creative process a bit but on the whole, the focus will be more on showing how beneficial it can be to take an aesthetic approach to learning topics that are more traditionally left-brained.
I am looking forward to seeing my speaker friends again. I haven’t seen many of them in years. Strange to have friends you only see during times when you (and they) are distracted about an upcoming public speaking engagement.
When I was younger, elementary school through high school, I was petrified by public speaking. Even just answering a question out loud when called on by the teacher caused distress. Worse was when I had to stand in the front of the class to recite something or answer some math equations on the chalkboard. Hated being the focus and it was paralyzing.
It still gives me butterflies and more traditional stress responses like shakiness and dry mouth, but like with everything, the more I do it the more it feels natural. Also helps to have a pre-talk ritual. A cellist friend told me that she eats a banana before a public performance and that helps with the nerves. Of course, now I am known as the ‘banana guy’ to some people I met at TEDx because I carried an absurdly healthy banana in my front chest pocket on my hoodie in anticipation of my talk.
Anyhow, if you find yourself in San Francisco in August to attend FITC, I look forward to meeting you. And if you are speaking at FITC, lets get coffee/wine/lunch/dinner.
A few weeks ago, I sat down with Alexander Tarrant and Colin Sebestyen at GAFFTA. We talked about art, scandal, nudity, succulents, magnets, clouds and Snoop Dogg. We finished up our conversation a few days later, joined by Justin Metros, over a bottle of Napa red and some beers at Hotel Bîron in Hayes Valley.
And somehow, through the alcohol haze, they managed to put together a really nice interview for Juxtapoz Magazine that spans 12 glossy pages. So to them, I say Thank You.
Check it out at your local purveyor of the magazine arts. Issue 114, the July issue, featuring a cover by Os Gêmeos.
With some help from Mike Creighton and Andrew Bell, I wrote a welcome to Cinder tutorial. It is a five chapter guide for getting started with Cinder. It highlights some of Cinder’s features and walks the reader through how to create the stippling project I posted a couple months back.
Included with the Cinder download are a bunch of sample projects to get you started. I haven’t been that good about releasing source code so hopefully I can make up for it now. The source for the following three projects are included in the samples folder.
Flint Ball (In the samples folder, it is called HodginParticlesRedux)
Reaction Diffusion (using GLSL shaders) inspired by Toxi’s amazing work with RD
Also, Andrew just finished porting Memo Akten’s MSAFluid library which is a rather lovely 2D fluid simulator. I used it to create a couple videos which use MSAFluid and a particle engine. Particles are deposited into the fluid and cause the fluid to move. The moving fluid then influences the movement of the particles creating a feedback loop. It ended up creating some nice examples of self-sustaining turbulence.
So there you have it. I am really excited to see Cinder out in the world. Check out the features and browse the projects in the gallery. If you have any questions or issues or compliments or suggestions, you can voice them in the forum. Happy coding!