Some time ago we had a demo that would give a 3D representation of routes obtained from the Google maps api, along with some points of interest the user could search for (like coffee shops). While the library keeps getting updated, this demo did not, and no longer worked on systems running recent versions of the library. This was unfortunate as the demo showed some neat applications for C3DL, so we decided to resurrect it.

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:

mapsInAction

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.

As we are moving away from using points for now, it was time to make a demo using spheres again. Instead of just re-posting an old demo, it seemed like a good time to add in some of the features people have suggested, such as being able to move the camera (Andor had already put that in the library, I just had not taken advantage of it). Then, since the point-markers looked so nice in different colours, I thought I should keep that idea and make the sphere-markers coloured too (again, the code was already there, but I hadn’t used it), but rather than being random I decided it would be useful to group the markers into right side, left side and core (or other), much like Vicon does. It was also a good opportunity to take advantage of some of the new functionality Andor has been working on (like the gradient colours on lines).



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.


From a distance they looked pretty good,

but if you caught them from the wrong angle or got too close, they didn’t look quite so nice.

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.

A number of things have occurred that necessitate a new version of the motion capture demo. These include:

  • 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.

Here, I’ve made a simple demo, using the collision detection.
The edge of the canvas serves as the boundary, and the balls are only moving side to side. Whenever any objects have a collision, it will move in the opposite direction.
See Here.
This one is a similar demo but with more balls and moving in multi-directions, bouncing off each other.
See Here. Play Here

Side note, update with current status of collision detection here.