The tool for creating templates (the files that we use to determine which markers are supposed to be connected) is working. Now, instead of having to write the files by hand and run a conversion to test them, then try to interpret what was wrong based on the output, users can use simple controls to create and edit templates and see the changes as they are made. It still helps if the user is fairly knowledgeable about the marker layout in question, or else they might end up with a mess like this , but they’ll be able to see that mess developing as they make it. In short, this should take most of the manual drudgery out of the process, while improving the quality of the output. This is all geared towards creating a file that, once created, you’ll never think about again because it will work for any number of files, with any number of subjects (using the same template, or different ones) in the scene, with any number of different actors, so long as you keep doing captures using the same number of markers with the same names.



With this added, the development phase of the converter is now complete, but it still has to be tested in a production environment and there is always the possibility of adding more file types as options for conversion. Adding csm (the simplicity of which I’m still fond of) as an input choice would make a useful demo to show others how to add to the converter, as would adding trc (or csm) as output formats. More likely I’ll be kept busy updating the old demos for the new releases of the library, or just writing new ones.

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.

I filed a bug a while ago concerning rendering points while playing a DVD on OS X. On some systems everything slows down, on others the OS crashes. See Point Rendering Bug under Points and Lines Update. I compiled a list of things which can be done to address this issue.

My first option is to debug the code in the extension. In a way, this is the best route to take since I would be focusing on the real issue; finding why it’s crashing and fix it. On the other hand, debugging code I’m not familiar with would be time consuming and success isn’t guaranteed. It’s tempting to tackle the heart of the matter: find the bug, create a patch and submit. But tempting as it is, it don’t think it’s worth the risk and the best use of time.

The next few options involve workarounds. The first is rendering sphere meshes instead of points. The main drawback with rendering spheres is there are many more vertices to send down the pipeline compared to a single vertex. This means there will be a slowdown on render. Sphere meshes will require a separate shader, but with some additional lines, they can be lit with some diffuse light making them appear 3D. In ways, this can enhance the scene’s visual quality. Additionally, the function to test ray/bounding sphere has already been written, so it will easy to use it to test ray/’point’ intersections for picking.

Another workaround includes rendering points as billboards. This would only require three extra vertices to send down the pipeline, so speed wouldn’t be a concern. The code for billboarding is already been used in the particle system class, so I’ll be able to use that. The main problem relates to texture quality. Since a texture will be mapped to the polygon, as the size increases, so will the texture. If the point size is allowed to increase to a very large size, the visual quality of the texture will drop.

Since the mocap data we’re using has roughly 40 markers per actor, 40 spheres may be asking for too much. 40 billboards on the other hand may be a viable substitute. Diffuse light can be faked with a texture. In the shader, the color of the billboard can be added to the texels, similar to how the particles are rendered. Since applying textures does not slow down rendering, it’s not a problem. The texture quality issue may be dealt with limiting point size or creating a custom sort of mipmapping.