...Hostile, Agile

TL;DR: Once again, Carmack was right. Go Mobile, Young Man, Go Mobile.

    Holy Jeebus, that’s right! I have a design and prototyping blog too, no, no, just kidding, I didn’t forget about it, in fact, I have so much stub content written that’s just waiting to be finished and published that you’d think...whatever one thinks about the aforementioned situation? More book reviews in the works, some mindset stuff as well, just need to get out from under May (Mai? insert joke about hot asian women and reverse cowgirl?) and content will start flowing again.

Mmm...Mai. More great work at http://pop-lee.deviantart.com/

    To that, I’ve been in Android development land for the last couple weeks, working on...oh, of course it’s something I can’t talk about yet, you should all know that by now, but if I pull it off, it’ll be pretty cool. I can say that it may end up being a stage demo for Google I/O, and while my specific part of it won’t be that cool in and of itself, the total package I think’ll be pretty sweet and I actually hope it’s something that people pick up on. Like most of the tech I'm working with, I don't know how consumer friendly it is, but I think in the right hands it'll be inspirational, and could definitely pave the way for consumer uptake. Hopefully I haven't just violated my work NDA...

    Anyway, after two or three weeks of learning Android basics, Android Studio, and OpenGL ES, I’ve finally got a build running on a device, my trusty Tango tablet, well, actually more like my poor, neglected Tango tablet that I haven’t done anything with yet, but I digress...Yeah, it was a bit of a long process, but that’s how I learn new languages and platforms, more on that later. It’s a little thing, but I'm actually really excited by the simple prospect of having an OpenGL ES app fully deployed to a platform, Android, well, "mobile" development has certainly become more of an interest in the last few weeks. If you’ve been thinking about developing for Android and ESPECIALLY developing OpenGL ES based stuff...DO IT!! The world needs more resources and more folks actively banging on this stuff for things other than games, so Join Me In My Quest!!

The Fellowship of the...AVD?

    Seriously, it's a bit of a wild west, there aren't a ton of resources available for learning OpenGL ES on Android, and god help you if you're trying to learn the Android build chain AND OpenGL ES at the same time. The currently existing resources, well, they're a bit spotty on effectiveness, at least in my opinion, but again, once Mai is done with me, I'll try and put together my findings, hopefully they'll be useful to someone, and I encourage more folks to do the same. I'm sorta tempted to do an ES 3 tutorial series similar to what I did with my Cinder::gl Tutorials, but ES 3.0 is close enough to stock OpenGL that you could just learn OGL 3.2/3 and then brush up on the Android (or whatever your platform of choice's) buildchain. Hmm...maybe a "Learning OpenGL ES with Android Studio"? ...and I haven't even touched on Tango/Tegra stuff, which is a whole kraken unto itself...

    Why my sudden love, or at least technolust, for mobile development? Well, I know some folks are certainly given to agree with the below image and are probably thinking “Android, but that’s just for silly little apps, and none of the hardware platforms have the power/perf metrics to do anything REALLY cool,” well...I disagree with this, or at least, I disagree based on what I see when I look three to five years down the road, what with the likes of the Tegra X1 and beyond, ES 3, Vulkan, and whatever the Tango evolves into, all these things add up to a platform just ready to be taken forward into the future. If you have a modern android device with a decent mobile GPU, you should check out the Yebis 2 OpenGL ES 3.0 Demo on Google Play, which is from whence the shiny part of the below image cometh (cameth?). Sure, the kicker is having an OpenGL ES 3.0 capable mGPU, and I know, I know, a demo is not a full app and doesn't have the same power/perf profile (don't you be tellin' my nu'n 'bout demos, BOY!), etc, etc, but if we should all know anything about hardware, it's that it doesn't stagnate, and I don't see that trend slowing down.

True Story, Bro.

    So I’m excited now, mobile has come to mean something completely different to me in the last couple of weeks, mobile isn’t just phones and tablets, it’s Oculus, it’s Vive, it’s HoloLens, it’s most certainly things like GearVR and Wearality, but it’s also the intersection of all those things and current mobile devices and paradigms. Gotta say, at first I thought Carmack was a little crazy, but no, I think I get where he’s coming from and I’m on board for it. My big issue with VR and HMDs up till now has been the idea of people just sitting alone in dark rooms with displays wrapped around their heads, and I think that's definitely an acceptable use scenario, but I didn't want it to be the only one. Given the new perspective that I think we can all take on "mobile", I don't think it will be.

    Alright, back to it. Nothing earth-shattering or groundbreaking here for sure, just some thoughts. I just got back from //build, and I'm definitely excited about Windows 10 and Universal Windows Platform too, so I'm not just a late-to-the-party Android sycophant, well, based on what I've said, I may actually be early to some party, so I think I'm alright. The mobile future is certainly shaping up to be...interesting times. Here's to it, and hopefully my next post will have some actual useful stuff (curse you, Mai! But keep doing what you're doing...). I'll leave with a bit of shiny just so this post isn't totally useless, a short vid of my aforementioned first build, gotta love that early 90s demoscene aesthetic! Cheers!

A video posted by Seth Gibson (@djtomservo) on May 3, 2015 at 10:39am PDT

Book Review: Learning C++ by Creating Games with UE4

Buy from Publisher | Buy from Amazon

    The past week I’ve pretty much jumped into UE4 programming feet first with my boots on, and I gotta say it’s been pretty fun. As I mentioned on twitter, good on Epic for providing a great UX for developers, so often people tend to think UX only applies to non-code content creators and end users, but as a someone who spends most of his time writing code, having a smooth flow from IDE to Build is awesome, especially given the fact that with something like UE4, it’s not just as simple as hitting the build button and clicking “Start Debugging” (although, with UE4 it actually is, which is a monumental feat). Props to Celia Hodent and the rest of the Epic UX crew, next time you guys are in the bay area, drinks on me.

    I have to say it hasn’t been lack of wanting that’s kept me out of UE4 up ‘till now, I was excited as anyone to get started last year, it’s been more due to a lack of available resources coupled with lack of available learning time. Seems the universe is doing that thing where it gently nudges me in a direction again though, and as I’ve had some projects come up at work recently that are less research and more production (and also require a high degree of shiny), combined with the aforementioned availability of resources, it seems like the perfect time to dive in. Sadly, I can’t give any specifics on what I’m working on just yet, but let’s just say...Good Hunting.

...and UE4 is definitely good at shiny. (Atlantis by Allegorithmic)

    To set some context for my review - In my search for learning resources, there were some specific “filter settings” I applied:

1. Having prior C++ knowledge, I didn’t want something that focused too much on the basics of C++. Ideally, I’d like a “UE4 Programming for C++ Programmers” type of thing.
2. I didn’t want something that focused too much on Blueprints other than how to implement custom Blueprints. I’ve seen quite a few tutorials that promise to teach UE4 programming but only touch on C++ just enough to get you into Blueprints, then all the actual heavy lifting is done in Blueprints, even thought it could be done in C++. I need to be “close to the metal,” as the kids say.
3. I also didn’t want something that only focused on implementing gameplay features. I know that’s a tall order since it’s a game engine (and hey, I was a tech artist for 10 years, I know tools development and the like isn’t sexy), but ideally I’d also like to learn how to implement lower order functionality, say Blueprints for utility functions or how to wrap external libraries for use in UE4.

    Of course, since I’ve only been able to find this one book on UE4 C++ Programming, this criteria may be moot, although I just got wind of another text coming out end of next month, and though I’m not totally sanguine on paying college textbook prices anymore, I'll definitely be giving it the once over as well. Getting back on topic though, how does Learning C++ by Creating Games with UE4 stack up to my scrutiny?

    Given my first criterion, I can’t comment on the first seven chapters, but even if I could, I probably wouldn’t. One of my personal beliefs (validated through experience, mind you), is that using a tool like UE4 to teach a programming language isn’t the best approach, there are just too many other topics to contend with. Definitely not a knock on UE4, I mean, if I were going to teach someone C#, I wouldn’t use something like Unity either (for reasons I may detail in another blog post).

...pretty, but all that shiny can be distractive and not quite conducive to learning to code

    So how about actually teaching UE4 programming? Well, I have to say it does a pretty good job of that, but until the next revision comes out, I definitely recommend having google and the Official Unreal Engine docs on hand. Already much of the code in the book relies on deprecated functions and paradigms, which can cause a bit of confusion on initial read and also results in build errors. No knock on the book or UE4, it should certainly be expected that the APIs are going to change, and I would advise any other author and publisher to consider any UE4 text a living document and make sure to stay on top of errata and keep the code updated. That aside, the programming projects start from a good place and progress very well. Additionally, the author provides short learning projects for the reader to implement on their own which build on the currently presented topic. Personally, I spent about 4 hours going through some of those learning projects and exploring other features, so you can definitely use these as jumping off points for other exploration. And yes, there is some Blueprint work, but only so much as necessary to get the code accessible from the editor and to teach basic workflow, so you’ll definitely be self-sufficient after working through this text.

    Sadly, the book does focus purely on implementing gameplay features, but as I stated earlier, I can’t knock the author or publisher too much for that. I have to imagine that the majority of readers who come to this text will be more interested in creating gameplay features as opposed to plug-ins or other tools, but as the APIs tend to follow common patterns and conventions, branching out into other sorts of UE4 programming tasks shouldn’t be too hard from this foundation (hopefully once the plug-in framework crystallizes a bit!).

...and there's plenty of plugin source available, so you're in good...err, hands.

    Hopefully you can gather that my overall impression of this text is positive, but there are a few things I found a bit off, though none of them are showstoppers, at least not for an experienced C++ developer. The in-line code snippets tend to gloss over a few points, things like declaring things public vs private, including headers where necessary, and other little things that, again, for an experienced C++ developer won’t provide any roadblocks, but if you're just learning C++ and have some of the first time jitters (which is to be expected!), these oversights may cause some frustrations. I think there was also a bit of a missed opportunity with Chapter 9: Templates and Commonly Used Containers. This chapter touches on array types and gives a comparison to STL types, which is valuable, but reads a bit out of place. In my opinion, this discussion would’ve been better in the first section on basic C++, which would have allowed for this chapter to provide some more UE4 specific projects and code samples showing how to work with the T* container types. Just a small thought, again, not a total showstopper.

    I guess what I’ll say is that if you’re an experienced C++ developer and you want something light that you can just work through in a weekend or so and feel comfortable in UE4, this is a great choice. Between this and the official documentation, you’ll find yourself in a good position to strike out into your own projects, whatever they be. Based on the review criteria and my own perspective as outlined earlier, I don’t know if I would recommend this to someone who was wanting to learn C++ and UE4, but like I said, I wouldn’t recommend someone learn C++ through a large content creation framework anyway. My impression based on skimming through the first seven chapters is that it teaches you enough to be comfortable working in UE4, but I don’t know that it’s going to make you a competent C++ programmer, granted that's something that only really comes from practice, but having a good solid foundation is also key. To its credit, this book will definitely give you a good foundation in modern programming basics, but C++ is a vast topic that requires some specific discussions. I would recommend instead something along the lines of the tutorials found at Cprogramming.com, LearnCPP.com, and/or CPlusPlus.com. I don’t say these things out of elitism or snobbery, it's just that since UE4 now gives you access to the FULL engine source, I think it’s really worth learning C++ properly so you can take advantage of that fact. Who knows, you too may find yourself with an opportunity to push the engine outside of its original sandbox, why not be ready to rise to the occasion?

Overall, 7 out of 10

Getting Started With Kinect.v2 and Cinder, pt. 1: Cinder-Kinect2

...Gentlefolks, start your frameworks.

    So, I'm somewhat ashamed to admit this, but I've actually had my Kinect v2 devkit for about a month-and-a-half now and haven't really done much with it other than run some of the demos, browse the sample code, and in general be amazed at the technology.  Thank god for eyeo festival and time off for a week to just create and be inspired, as it allowed me to really get hands on with the hardware and some of the solutions available for Cinder.  Let's take a look, then, shall we?  In this first installment, we'll go over Cinder-Kinect2, which is a wrapper around the core SDK, developed by Stephen Schieberl of Wieden-Kennedy and of course, Cinder, fame.

---

DISCLAIMER: This is preliminary software and/or hardware and APIs are preliminary and subject to change

---

    Let me preface this by saying I'm not presenting anything show-stopping here, this isn't even Cinder Kinect 101 (it's more like 90), chances are most users probably know this stuff already, but at least it's here for some amount of posterity, and I will be updating this as the APIs mature (which I guess should be any week now?).

    Ok, that all said, here we go, for real.  Cinder-Kinect2 is the simpler of the two solutions, granted, they're both simple, Cinder-Kinect2 just requires less to get started.  How simple?  Well, assuming you have the K4W DPP SDK installed...

-> Clone or fork Ian Smith-Heisters' fork of Cinder-Kinect2, as it includes some fixes to account for changes in the 1404 Developer Preview SDK.

-> "Install" it as you would any ordinary Cinder block, i.e. clone your chosen repo into your <cinder_root>\blocks folder.

-> Pop open a sample, make whatever changes you need, if any, to the Project Properties.

-> Build and Run. ??? Profit!

    As of this writing, the main fork of Cinder-Kinect2 doesn't take the 1404 changes into account.  If you're interested in fixing it yourself, really you just need to make some minor changes involving the commenting out or removal to references to KinectStatus, as it's been deprecated, replacement pending, but the good Mr. Heisters has also added a few other features that make his branch worth taking a look at.

    The interface itself is as simple, if not simpler, than the installation process.  Here's a sample image and a snippet of the code that produced it, cribbed from the BasicApp and BodyApp sample:

void K2TutorialApp::update()
{
  if(mKinect->getFrame().getTimeStamp()>mFrame.getTimeStamp())
  {
    mFrame = mKinect->getFrame();
    if(mFrame.getColor())
    {
      mRgbTexture = gl::Texture(mFrame.getColor());
      auto cBodies = mFrame.getBodies();
      if(cBodies.size()>0)
        mJoints = cBodies.at(0).getJointMap();
    }
  }
}

void K2TutorialApp::draw()
{
  gl::clear(Color(0, 0, 0));
  if(mFrame.getColor())
  {
    mRgbTex = gl::Texture::create(mFrame.getColor());
    gl::draw(mRgbTex,
          Rectf(Vec2f::zero(), getWindowSize()));

    auto cJoints = mBody.getJointMap();
    if(cJoints.size()>0)
    {
      gl::pushMatrices();
      gl::scale(Vec2f(getWindowSize()) / Vec2f(mRgbTex->getSize()));
      for(auto cCjoint : cJoints)
      {
        Vec2f cp = Kinect2::mapBodyCoordToColor(
                cCjoint.second.getPosition(),
                mKinect->getCoordinateMapper());
        gl::drawSolidCircle(cp,10);
      }
      gl::popMatrices();
    }
  }
}

Resources

• Cinder Home - http://libcinder.org
• Cinder on github - https://github.com/cinder/Cinder
• Ian Smith-Heister's Cinder-Kinect2 fork - https://github.com/heisters/Cinder-Kinect2
• Stephen Schieberl's Cinder-Kinect2 fork - https://github.com/wieden-kennedy/Cinder-Kinect2
• K2TutorialApp Source - https://github.com/SethGibson/K2Tutorial

A video is worth 30,000 words per second?

Point Clouds and FBOs from Seth Gibson on Vimeo.

    Just popping in to say that if you haven't checked out my Vimeo channel recently...err...there's not much new stuff there, but there's more fun stuff coming (along with new blog posts that I've promised people and myself).  I'm considering doing some Cinder video tutorials if I ever find some free time, not sure about what, maybe covering Kinect, the Intel depth cameras, that sort of thing...not sure really, we'll see.  But anyway, yeah, bookmark my channel, show your friends, loved ones, your inner circle, all that.  If nothing else, it's good for a tiny bit of inspiration...maybe.

>>> Me on Vimeo <<<

Cinder-Assimp, VS2012, and Cinder 0.8.5

If you're in a hurry, absolutely need to get Cinder-Assimp functional, and don't have time to read my drivel...TOO BAD!  I kid, I kid, here's all you need to know:

• Download the pre-built Assimp 3.0 libs from Eric Renaud-Houde's Cinder-Skinning block and stick them in Cinder-Assimp's lib/msw folder
• Pop open AssimpLoader.cpp and change line 460-ish from cam.setFovHorizontal to cam.setFov
• Shake your head sadly at the fact that I'm so desperate for attention that I took a two step process and turned it into the yarn below, which you may optionally read.  Yep, I'm definitely management material.(Optional)

    More often than not, when we need to deal with 3d content here in Lab land, we tend to use Unity as our framework of choice, though with dropping of the thermonuclear bomb that is UE4 on reality this week, that may be changing.  The problem, as you can imagine, is that sometimes we don't really need something as extensive as Unity, but we end up using it anyway because we don't have options, which leads to some really interesting design decisions sometimes.  Recently, we had a project that really only required a minimal amount of 3d content management, so little so that it would've been nice to be able to keep the whole project in Cinder, but since our content was skinned and animated, Cinder's built in OBJLoader obviously wouldn't suffice.  So we were stuck in a situation where really we needed the absolute most minimal subset of Unity's functionality, but because it was our only option, it required quite a bit of one-off development to turn Unity into something like a useable component.  Well, gee Seth, why didn't you just use Cinder-Assimp?  Great question...

...check out the big brain on the Cinder forums.

    Cinder 0.8.5 is an interesting beast, there seem to be quite a few interface changes from previous versions, that, if the dev docs are to be believed, may be re-appearing in 0.8.6.  This was probably the thing that kept us from designing with Cinder-Assimp in mind originally, the fact that we couldn't really get it to work.  Thankfully, we had some time to revisit the project and wrap it up, so I made it a priority to figure out Cinder-Assimp.  If you're a Cinder user, you're probably familiar with Gabor Papp's work, if not, well, it's good, and if he says it worked, then at some point it did, so I figured it was more an error on my part than the block's part.  Turns out I was right.

    First, all credit where it's due, it was actually Eric Renaud-Houde's excellent Cinder-Skinning block that solved the major problem, that of getting compatible libraries.  Sure, I could've just built Assimp myself against VS 2012, which also would have solved that problem, but hey, I'm lazy and am more than happy to let other people do work for me, although I'll probably be running a build of it myself going forward just to make sure I have it.  As much as I'm excited about UE4, I'm definitely not abandoning Cinder...ever.  I like to think of UE4 (or whatever game engine I use) as the infantry and Cinder as Spetsnaz.    Anyway, if you grab the pre-built Assimp libraries linked on Eric's repo for Cinder-Skinning, you can link the Cinder-Assimp samples against that.  But wait, there's probably one more error you might run up against...

...i know, i know, it's always one more thing.

    This..."fix", as I alluded to earlier, gives me a bit of pause, but hey, if you need to get work done, you need to get work done.  But first, consider this:

• Camera.h master
• Camera.h dev

    As you can see, the missing setFovHorizontal() will be (is) returning (here-ish), so my actual advice is to man up and work out of the dev branch and build your own version of Assimp, which you'll probably want to do anyway since Cinder is also moving to boost 155, so why not just build everything against the same boost?  But again, if that's not an option, you can just patch AssimpLoader.cpp to use the setFov() method vs setFovHorizontal() for now.  So to recap (stop me if you've heard this one before):

• Download the pre-built Assimp 3.0 libs from Eric Renaud-Houde's Cinder-Skinning block and stick them in Cinder-Assimp's lib/msw folder
• Pop open AssimpLoader.cpp and change line 460-ish from cam.setFovHorizontal to cam.setFov

    Now to finish up some prototypes so I can go to a Systema seminar this weekend and not sleep at the office.  Hopefully I'll carve out some time to play with UE4 as well, although, I had an interesting conversation with Stephen Schieberl, also of Cinder fame, at eyeo festival last year where he alluded to the idea that Team Cinder's been looking at game engines and thinking about how to bring some of those ideas, especially on the content creation side, into Cinder land, so...maybe UE4 is just a passing fancy too.  The future is exciting, my friends, go make something.

...in the future, all UIs will be MADE OF CASCADE PARTICLES!!!

The Human Triangulation Experiment, Stage 1

    Recently, us lucky saps in the Perceptual Computing Lab have been fortunate enough to be doing some prototypes for different external groups, and I've actually been lucky enough to work with one of my favorite groups, [REDACTED]!  Needless to say, I'm super excited, and one of the first projects I'm working on involves using depth data and object/user segmentation data to interact with virtual/digital content, much like the ever popular kinect/box2d experiments you've probably seen floating around...

Check out more of Stephen's stuff on github or on his website.

    Depth buffer, OpenCV, cinder::Triangulator, and Box2D, seemed pretty straightforward, I mean let's be honest, that's creative coding 101, right?  That's what I thought, but as usual, the devil's in the details, and after some (not terribly extensive) searching and a little bit more coding I had...eh, well...nothing.  My code looked correct, but no meshes were drawn that day, and even in a cursory inspection of my TriMesh2ds, there was nary a vertex to be seen.  Here's what I tried originally (this is sketch code, so yeah, the pattern is a little sloppy):

//cv contours are in mContours, mMeshes is vector<TriMesh2d>
for(auto vit=mContours.begin();vit!=mCountours.end();++vit)
{
  Shape2d cShape;
  vector<cv::Point> contour = *vit;
  auto pit=contour.begin();
  cShape.moveTo(pit->x,pit->y); ++pit;
  for(/* nothing to see here */;pit!=contour.end();++pit)
  {
    cShape.lineTo(pit->x, pit->y);
    cShape.moveTo(pit->x, pit->y);
  }
  cShape.close;
  Triangulator tris(cShape);
  mMeshes.push_back(tris.calcMesh());
}

    Right, so at this point, it should be a simple exercise in gl::draw()ing the contents of mMeshes, yeah?  Sadly, this method yields no trimesh for you!, and as I mentioned above, even a quick call to getNumVertices() revealed that there were, in fact, no vertices for you!, either.  The docs on Triangulator lead me to believe that you can just call the constructor with a Shape2d and you should be good to go, and a quick test reveals that constructing a Triangulator with other objects does in fact yield all the verts you could ever want, so methinks maybe it's an issue with the Shape2d implementation, or perhaps I'm building my Shape2d wrong.  I rule the latter out, though (well, not decisively), since Triangulator has the concept of invalid inputs, e.g. if you don't close() your Shape2d, the constructor throws, so...what to do, what to do?  To the SampleCave!

TRIANGULATE AGAIN, ONE YEAR! NEXT!

    Mike Bostock, he of d3.js fame gave a great talk at eyeo festival last year on the importance of good examples (Watch it on Vimeo), and you know, it's so true.  It's sorta like documentation, we employ technical writers for that sorta thing, I feel like we should at least give some folks a solid contract to put together good sample code for whatever we're foisting onto the world, rather than relegating samples to free time and interns (no offense to either free time or interns).  Now Cinder has amazing sample code, so a quick google search for TriMesh2d popped up the PolygonBoolean sample, which was basically doing what I wanted, i.e. constructing and drawing a TriMesh2d from a Shape2d...kinda.  I trust the good folks at Team Cinder to not ship sample code that doesn't work, so a quick build 'n' run later and I had a solution.  I was sooooo close...

//cv contours are in mContours, mMeshes is vector<TriMesh2d>
for(auto vit=mContours.begin();vit!=mCountours.end();++vit)
{
  PolyLine2f cShape;
  vector<cv::Point> contour = *vit;
  for(auto pit=contour.begin();pit!=contour.end();++pit)
  {
    cShape.push_back(fromOcv(*pit));
  }
  Triangulator tris(cShape);
  mMeshes.push_back(tris.calcMesh());
}

    The results?  Well, see for yourself:

My tribute to Harold Ramis, may you never end up in one of your own traps, sir.

    Next steps are to maybe run some reduction/smoothing on the contours, although I suppose it doesn't matter terribly for this prototype, and get it into Box2D, all of which I'll cover in Stage 2, including a quick 'n' dirty Cinder-based Box2D debug draw class.  This is awesome, it's total Tron stuff, bringing the real into the digital and all that sort of sorcery.  Once I get the Box2D stuff implemented, I'll stick a project up on github, until then, if you have specific questions, Tag The Inbox or leave a comment below, you are always welcome to try my Shogun Style...for reference, here's the complete update() and draw():

//Using Cinder-OpenCV and Intel Perceptual Computing SDK 2013
void segcvtestApp::update()
{
  mContours.clear();
  mMeshes.clear();
  if(mPXC.AcquireFrame(true))
  {
    PXCImage *rgbImg = mPXC.QueryImage(PXCImage::IMAGE_TYPE_COLOR);
    PXCImage *segImg = mPXC.QuerySegmentationImage();
    PXCImage::ImageData rgbData, segData;
    if(rgbImg->AcquireAccess(PXCImage::ACCESS_READ, &rgbData)>=PXC_STATUS_NO_ERROR)
    {
      mRGB=gl::Texture(rgbData.planes[0],GL_BGR,640,480);
      rgbImg->ReleaseAccess(&rgbData);
    }
    if(segImg->AcquireAccess(PXCImage::ACCESS_READ, &segData)>=PXC_STATUS_NO_ERROR)
    {
      mSeg=gl::Texture(segData.planes[0],GL_LUMINANCE,320,240);
      segImg->ReleaseAccess(&segData);
    }

    mSrcSurf = Surface(mSeg);
    ip::resize(mSrcSurf, &mDstSurf);
    mPXC.ReleaseFrame();
  }

  cv::Mat surfMat(toOcv(mDstSurf.getChannelRed()));
  cv::findContours(surfMat, mContours, CV_RETR_LIST, CV_CHAIN_APPROX_SIMPLE);

  for(auto vit=mContours.begin();vit!=mContours.end();++vit)
  {
    PolyLine2f cLine;
    vector<cv::Point> contour = *vit;

    for(auto pit=contour.begin();pit!=contour.end();++pit)
    {
      cLine.push_back(fromOcv(*pit));
    }

    Triangulator tris(cLine);
    mMeshes.push_back(tris.calcMesh());
  }
}

void segcvtestApp::draw()
{
  // draw camera feed
  gl::clear(Color( 0, 0, 0 ) );
  gl::color(Color::white());
  gl::draw(mRGB, Vec2f::zero());

  //draw meshes
  gl::enableWireframe();
  gl::color(Color(0,1,0));
  for(auto mit=mMeshes.begin();mit!=mMeshes.end();++mit)
  {
    gl::draw(*mit);
  }
  gl::disableWireframe();
}

EyeO Recap[0]

    My brain is COMPLETELY full.  I mean, honestly I don't even know where to begin, there were so many great presentations, and so many awesome conversations about random cool things, and so many good ideas tossed around, and...I took a bunch of notes on individual sessions, which I'll toss up on the google drive at some point, maybe in about an hour when I go sit down for lunch (aside, MSP is one of the most connected airports I've ever been in.  Seriously SFO and SJC, step up), and once some of the noise dies down I'll put up my actual thoughts.  I'd started some posts about each day, but eventually it just got to the point where I couldn't digest things fast enough to come up with coherent thoughts on a nightly basis.  Granted, there were open bars involved too, but i didn't really stay out that late, something I plan to remedy next year.

This guy is a genius, listening to him talk, you can totally see how he would build something like Hypercard. Photo by Charlie Cramer

    If I had to pull out one takeaway right now, Bill Atkinson (of Hypercard fame) said it best.  Learning to code is cool, but take a different approach.  There's the approach that says "I want to learn how to code", and there's the approach that says "I want to do something cool, and I'll need to learn how to code to make it happen", or alternately expressed, forget about how you want to do something and focus more on what you want to do and why you want to do it.  That's not to say that tools, frameworks, languages, etc don't matter, but I've always held that application is the best way to learn something, learning through doing, learning through projects, that sort of thing.  So often, I hear people say, well, why would I need to learn to code or, ok, I know some basics, but what do I do next?  Answer that problem first, and learning to code becomes easy.  Learn the things you need to learn for this project, then build off of them for the next project (or shoot off in a different direction and learn new things, either way is a great approach).  But don't get so caught up in learning how to code or learning every particular of a language, framework, paradigm, or process that you forget to make something beautiful.  As I ranted to a co-worker a little while back "There is no perfect tool or SDK/API.  Unity, UDK, Max, Maya, Cinder, ofx, processing, Windows, Mac OS, they ALL suck."  But I'm going to append that with they all make beautiful things.  So quit whining and make cool shit.

    My other takeaway is that Memo Akten is in fact a machine, but his talk was probably the most personally inspiring.  More on that later, but suffice it to say, I used to think I was crazy until I heard his talk.

    EyeO this year definitely struck me as more about experience than technology.  I think this is both good and bad.  Good because experience is really what matters at the end of the day, bad because so many people now are talking about experience, moreso than the people building experience.  It would be really sad to see EyeO become a glorified UX/HCI conference, and I really hope they keep to the trend of only recruiting speakers who have actually MADE stuff.  I don't see that trend changing, and I really hope EyeO continues to feel the way it did this year.  Sometimes it takes a long journey fraught with setbacks, delays, time spent wandering the wilderness, time spent off the trail for a bit, or time looking at the map trying to remember where it was you were going in the first place, before you reach home.  I'm not there yet, but after EyeO this year, I feel like I'm passing the last few mile markers.  GDC had been home of sorts for too many years, really looking forward to this new place.  It feels real.