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. :(

OMG I HAVE SPHERES

Well, kind of sort of. Last night, I realized that ProcessingJS actually doesn't support 3D yet, which is a major pain in the ass. I'm going to code everything in Processing for now, and when ProcessingJS does support everything 3D (which should be soon...), it's a simple task to port over the code to ProcessingJS. Like, copy-and-paste simple.

The smaller sphere is supposed to be the root (I just set radius = 10 for now) with a translation on it, but I'm going to do some debugging now and fleshing out the AMC code. At least I have something.

Beta Review

So on Tuesday, I had my beta review with Norm, Joe, and David. Essentially, for the past week, I had been working on parsing the asf/amc files using Processing. However, as I described in the meeting, ProcessingJS unfortunately does not have a BufferedReader implemented, meaning that I had to treat the entire file as an array where each line in the file comprises an entry in the array. Barf.

So I think I'm pretty much fine with regards to the asf/bone/skeleton structure, but the amc file was a little confusing because I wasn't sure what the best way to interpret that was. Thankfully Joe cleared it up, and I shall get to working on that, including displaying just one joint/root and hardcoding translations/rotations to make sure the system works.

After that, I can replicate the skeleton. Whee.

Got a rough UI up...

So I got a rough UI for the search results page up. It pretty much adheres to my sketch a few posts back, but now it's actually marked up and stuff in an adaptable way, I hope! The page is here (currently has dummy content and doesn't do anything, but for the purposes of the simple user study, it'll do), and a screenshot of it is below:

After playing around some more with webGL, Lu alerted me to the existence of ProcessingJS, which enables you to use Processing to make visualizations for the web without using any plug-ins. Hooray! With ProcessingJS, I can either code in Java or Javascript, and it'll work on a webpage. After testing out a few examples, I've determined that this more what I want to work with, so I got the OK from Joe to switch over to Processing.

Before the beta review, I'm going to try to get a skeleton up and running.