Some more changes

1. I changed the sampling rate of the frame-by-frame view so that the intervals now depend on how long the motion is.

Here's a walk motion that has 500+ frames:

And here's a walk motion that has 200-300 frames:

2. I changed elements of the interface so now it explicitly says how many frames are contained within a motion, and I also commented out the "Additional Views" link for now.

3. Here's the final presentation video + voiceover (as it sounded during the actual presentation, but this time the graphics will NOT be blown out by the projector).



4. And here's the final report (contains details), if you want to read it: Final Report

Joint color changes

I implemented a new visualization where the joint colors change based on acceleration. Red means the joint is speeding up, and blue means the joint is slowing down.  There are 3 versions below:

This one displays the bones changing color:

This one displays the joints changing color:

And this one displays the joints changing color and the bones changing color based on the average color of the joint + its parent:

(keep in mind that the skeletons are displayed every 25 frames right now...)

For the final demo

For the final demo, I generated a page of results in the same Processing sketch. Granted, they don't have the results page UI around it, so what I just did for now (while waiting for Processing JS to implement 3D) was inserting .gifs of the skeletons + bird's eye view manually into the pages.

Walk Results Page
Jump Results Page
Random Results Page

Each page has 8 results displayed. The skeletons look quite small now (they unfortunately got so blown out by the projector for the final demo that you couldn't see any of them), but hopefully I'll finish the implementation where the joints change color based on changes in acceleration. Also, it would be nice to have some indication of how long the motion is, because I'm sure information would be useful.

For the bird's eye view, there are two small indicators (one green and one red) to indicate where the motion starts and finishes. For some of the motions where the subject stays mostly in the same place, you can't really see the green/red lines nor the yellow dot because the information gets drawn on top of each other and the space the subject occupies within the capture space is small. For the case where the subject stays in one place, I thought about enlarging the "dot" that results, but then you wouldn't be able to distinguish that from a subject performing a motion where it occupies a circle of space.

In order to deploy my code, ideally I'd like to wait for Processing JS to finish its implementation of 3D. That way, there can be multiple HTML5 canvases on the same page that load pretty quickly, instead of embedding Java plugins, which is what you have to do with current Processing sketches. Processing JS just makes executing Processing code in the browser a lot easier/faster, because it runs on HTML5 and webGL.

He's walking, kind of sort of?

The elbow joints look a bit off, so I'll try to see what's up with that. However, I think the rest of his body looks about right? I'm using this animation (frame 1) as the source.

Basically, rotations are confusing. With much help from a certain someone, I revised the draw method so that it applies the rotation based on the axis in the ASF file, then applies the rotation specified in the AMC file, and then undos the axis rotation. The result is the above screenshot, and it looks a lot closer to the final product than anything I've gotten so far, so I'm keeping it for now.

Sup, skeleton?

Jon McCaffrey is the best. No, seriously. He helped me walk through and make sense of what I was doing wrong and what I was not sure of. I gave him a huge hug and then tried to pick him up, but that was quite difficult as I'm not strong enough and he is like 3x my size. So that failed.

But here, I think this looks ok? Needs stylizing and whatnot, but at least things look like they're in the right place!

And because I know you all like "oops" shots, this was a screenshot taken a few minutes before we sorted out mr. skeleton:

Oopsies

More debugging to do, but I think these look kind of cool. This one reminds me of an alien:

And this one reminds me of this graphic by the NYT, mostly because all the lines are straight and pointing along the same axis:

Not quite a skeleton

But something displays. It has something to do with the order with which Processing processes the translations/rotations, and whatnot. The AMC parser works fine at the moment, but I think I just need to debug the recursive display() function I wrote. The challenge is trying to make sure all the functions related to drawing/translating/rotating execute in the proper order and in the correct coordinate system relative to each other, which is getting messed up somewhere currently.

Current train of thought:

The idea is that you want to keep drawing a chain of joints within the same coordinate system as the stem of the chain. Therefore, you need to push/pop matrices so that once you run out of joints in that lineage, you go back to the common ancestor and pop matrix so you start drawing again from that coordinate system. So if you start with the root, you want the left arm to get drawn in succession, but then you can't exactly start drawing the right arm without reverting back to the coordinate system of the root. Thus you need to push matrix right after you draw the root and then pop it when you're about to start drawing the right arm. There's a code sample on page 112 of the book Getting Started With Processing (Casey Reas & Ben Fry) that makes a lot of sense in terms of how the transformation hierarchy works. I think I'm just hitting a block in articulating my thoughts but it makes sense to me.


Will debug today.

Also, I wrote a Frame class that holds a skeleton and a frame ID. I'm trying to make it so that the parseAMC() function creates a new Frame object for ever frame it reads, but right now, it seems as though the program overwrites the same Frame, even though I used a similar code structure for creating new Bones in the parseASF() function and that works fine. This would be where a better IDE (allowing for better debugging functionality) is helpful. That being said, debugging has been extremely slow with the Processing IDE so far. I didn't think it would be as slow as it has been.

I've also been sick for the past week and a half. It's been such that I've had a recurring headache this entire time. Not the worst, but certainly annoying when you have to stare at a computer screen all day. :(