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();
}