Having never seen the original working, I had a difficult decision to make. Do I update the existing code to work with the newer versions of the library? Or do I write a new demo from scratch? In theory the update should have been the easier route, but it was using code that had been rendered obsolete before I joined this project. Instead of learning an outdated version of the library to update one demo, I kept only the basis of the code (mostly the interaction with the Google Maps API), and wrote most of the rest. As the demo progressed we had several ideas about things to be improved or added. For example, each of those points of interest gets a little 3D model (a tetrahedron for now) to show where it is, but we realized it would be better if the user could click on that point of interest and find out what it is, what the address is etc., so now you get a pop-up with the name, address and phone-number of the point.

Without further ado, here’s a picture of (and link to) the demo:

I did have to limit the number of roads that are visible at one time, and only show points of interest that are close by, just to reduce the strain on the system (A trip from Toronto to Vancouver involves a lot of roads and an extraordinary number of coffee shops).

There are a few things that I’d like to improve on when the opportunity presents itself, or would be happy to see other people try.

• This uses an old version of Google’s API. It would be nice to bring it up to version 3.
• The overhead compass would look nicer if it was partially transparent (So you could see the letters indicating the directions, but not the rectangle they sit on). While this concept is supported by OpenGL and the png format, support for it isn’t in the library yet.
• The tetrahedron’s that indicate points of interest work, but a better model would make the demo look nicer.
• A road model that was more than just a flat rectangle could make the demo look nicer too.
• When you click on a point of interest, it causes a pop-up with information about that location, instead it would be nice to have that information appear as floating text in the canvas, so it doesn’t interrupt the demo.
• It would also be nice to get elevation data, but the Google Maps API doesn’t provide it, so it would have to come from somewhere else. Then we could make the roads go up and down with the elevation instead of assuming the world is perfectly flat. That would require a little extra code to accommodate the new data, but most of the hard calculations are already done.
• The overhead compass often misses getting drawn when the page first loads, but will show up on a refresh. This is peculiar as the code is supposed to wait until all models are loaded before it actually starts.

Now, as Andor said in his previous post, spheres are much more complicated than points when it comes to rendering, so my first version of the new demo was noticeably slower than the version using points. The counter to this was to reduce the complexity of the sphere, turning it into something sphere-ish but much easier to render. Instead of the 200-odd faces in each of the original spheres, I dropped it to 64.

I experimented with some simpler spheroids, getting all the way down to 4 triangles to try to find one that is simple to render and still looks good. No, I guess a tetrahedron isn’t really a spheroid, but I thought I should try it anyway.

Here are some of the almost-spheres I put together in Google Sketchup:

64 triangles		48 triangles
24 triangles		18 triangles
4 triangles

The one with 48 triangles seems to look the most sphere-like overall (it doesn’t have the flat top of the 64 triangle object), so I decided to go with that for now.

Now to finish off the tool that creates the templates used to determine which markers should have lines drawn between them. It as almost working, but it is losing track of which marker is which somewhere. For example, while it might think it is putting a line between the left forearm and left elbow (which it should be), it is actually connecting the C7 vertebrae to the right knee (which I imagine would be rather painful).

UPDATE: I borrowed some more of Andor’s code to add better lighting to the scene and now the semi-spheres look much better.

• The new release of the Canvas3D extension (0.4.2), and the corresponding release of our library(1.0).
• Andor’s work on points and lines.
• My continued work on converting c3d and trc files

As these new capabilities arrived, it became clear that the motion capture demo could be seriously improved.

The most visually apparent improvement is the inclusion of lines connecting some of the markers. This relied on Andor’s previously mentioned work, along with some extra functions in the conversion process to separate the markers by subject and try to match those subjects against pre-existing templates. It is also noticeable that some of the connections don’t make any sense (the actor’s foot being connected to the phone in the capture labeled ‘wrong number’, for example), this is because the data I used for the demo hasn’t been manually cleaned, and the motion capture system was under the mistaken impression that the marker in question actually did represent the actor’s ankle. This kind of problem is one of many things that is normally sorted out before a file is really ready to be used.