Motion Capture Test Data
peter | 23 April, 2009 | 9:48Having been given access to a SUN Sparc server (at just about the same time I found some c3d files in MIPS format) I proved that the code we use to read numbers stored in binary on that architecture works just fine. I can now proudly state that the converter can handle any c3d file that follows the standard. Unfortunately, there are quite a few files freely available for testing purposes that don’t follow the specification, or just have a very creative way of interpreting it. If a specific byte is supposed to say where the 3d marker data starts, and someone uses it for something else, can that file still claim to be a c3d file? There’s plenty of room in the spec to allow for adding custom data in the parameters section, so why make your file lie to potential users? In several of these situations the converter can make an educated guess (if the file is this long, and this much of it is taken up by the header and parameters, it’s not that hard to figure out where the marker data should start), but there’s just no way to account for all the things people can do by not following the spec.
In other news, we can also divide markers into labeled and unlabeled, currently by using the Vicon default names for unlabeled markers, but if anyone can get me info on the default labels in any other system’s c3d files (everything I’ve seen so far uses *n or MRKn, where n is a number starting with 1 and counting up), I’d be happy to add them in.
Also, now that the markers are divided into labeled and unlabeled it has become much easier to recognize a specific subject and determine what markers should be connected to which other markers. Actually being able to display that will rely on Andor’s code for the line and point primitives, but I’m told that will be ready soon.
In the meantime, I have plenty of work to do in making the detection and matching of subjects smarter.
