Less than a week

With less than a week the firm "pencils down" date, I'm feeling a little disappointed in where my project is. I'm at the point where mesh morphs are operational (albeit buggy), with what I consider is a solid and simple API.

 mesh = soy.models.Mesh()
 mesh.size = 6
 mesh[0] = face //a soy.atoms.Face object
 // repeat for mesh[1] through mesh[5]
 clone = mesh.clone()
 //clone is a Mesh object that can be rendered in its own right, if it is bound to a body
 //change the face and vertex data for clone[0] through clone[5]
 target = soy.models.Target(mesh)
 morph = mesh.morph(clone,0.5) //mesh.morph(variantMesh,delta) spins off a soy.atoms.Morph object
 target.morphs.add(morph)
 //now you bind target to a soy.bodies.Body, and when its render() method is called, it will apply all its morphs at their given deltas

Rendering has not been done yet for Mesh, and this process will be complicated on the back-end once we perform optimization. Basically we have to maintain the public vertex ordering while shifting vertices around on the backend so that OpenGL can render faces that have the same material consecutively (having to switch between materials needlessly is costly). This is already done for getters and setters for Mesh, but not honored by clone(), soy.atoms.Morph, or by the Target constructor.

Odds are this process won't even be kind of complete by pencils down, but I would expect something more fully functional by PyCon.

One week to "pencils down"

We have a little less than a week until the soft "pencils down" deadline. In theory, we are supposed to spend the remaining time after that point doing cleanup, documentation, etc. In practice, that will hardly be the case. The firm "pencils down" deadline is two weeks away. I'm on track to have the basic morph completed by Thursday. Then I will spend the weekend figuring out a basic keyframe pattern using atomics. Then the final week will be spent working on Mesh itself -- e.g. on rendering and optimization, which still has not been done.
At first our thinking was that a morph target is a type of model. One would render the target instead of rendering the original mesh. That idea is incorrect because it makes it difficult to apply multiple morphs to the same mesh.
The direction I've been going is this: you create a morph atom, which is calculated as the difference between two meshes. Mesh has to honor a public array of vertices as it is (even though it will be performing optimizations behind the scenes), so we assume the public ordering is valid for both methods. This means for any given vertex, mesh A contains that vertex's position, normal, etc. when the morph is at 0.0, and mesh B contains that information when the morph is at 1.0.
Then you can specify a delta, between 0.0 and 1.0, and the atom computes the vertex interpolation. Then you bind the morph atom (which is basically a matrix of values to be added) to the original mesh. This means that rendering is done on the original mesh, rather than a target model, and multiple morph atoms can be added to a single mesh.p
Animation is a little more difficult problem, but expressing morph as an atomic makes it more tractable. I'm thinking the morph atom will have an optional property (some sort of soy.atoms.Keyframe), which basically expresses what the transformation matrix will look like at some point in the future. Then as we step through the thread, we compute the matrix by multiplying the delta by the ratio between the current time and the keyframe. This could get costly if we are generating new objects every time, but it should work, especially if we have an OpenGL VBO doing the actual work of applying the matrices for us.

eglib

Not much interesting in the way of updates this week. PySoy is facing a bit of a transitional period. We're wanting to move away from GTK 2.x, because gtkglext does not support nVidia cards, among other reasons. But the question has been -- moving where? We toyed with GTK 3 but we need something with better bluetooth support, etc. Clutter was an option but seems to be no good because it does not support OpenGL features like cubemapping, which will become very important to us.

So now it looks like we are going to be writing our own library to work with EGL. It's called eglib. It sounds like an interesting proposition, but I worry that it may be increasing the scope of our project beyond our ability to quickly roll out. We'll see what happens.

The best way isn't always the sexiest

This week I had to abandon my attempts to develop on Ubuntu. It seems NVidia's Ubuntu drivers lack support for some of the OpenGL calls libsoy's windowing system is making. So I am now developing solely on Mac OS X. My OS X install has X11 support, so after my initial struggle trying to compile libsoy at the beginning of the summer, I've been able to run libsoy almost without a hitch.

One thing missing, though, is cwiid support. That's fine, since cwiid is an optional dependency for the Wiimote controller. It's easy to set a dependency as optional in wscript: you just add the "Mandatory=false" flag to your conf.check_cfg(). So the configuration doesn't error out. However, the one deceptively difficult issue was in telling waf to avoid compiling the Wiimote.gs controller if cwiid is not installed. So the build breaks.

I'm the only one really affected by this issue, so I set out to learn a little about Waf (by reading the Waf Book). And I found myself trying all afternoon to make a change that on its surface seems quite simple. There are too many source files to add them to Waf's task generator one by one, and bld.add_subdirs() does not make it easy to add constraints. So I toiled around with extending Waf's TaskGenerator class for a while. Nothing doing. So, failing that, I just used ant_glob to generate a list, and wrote an if statement that removes the file Wiimote.gs from the result, if cwiid cannot be found in the configuration.

I spent hours trying to build a sexy solution, only to settle for a kludge. It's a lesson I have a hard time learning -- I should have rolled out that little bit of hackery to begin with. Sometimes the best way makes you feel a little dirty, but it's still the best way. Problem solved; onto the next one.

I have diabetes

I have been diagnosed with Type I diabetes. I am the first in my family to have it. It's been a rough ride but on the plus side I now know why I have been so tired and practically non-sentient over the past month. And suddenly having insulin in me makes me feel once again as though I can take on the world.

The past few months of gradual emaciation has affected a lot more in my life than just GSOC. My odds of failure are tremendously high at this point, for GSOC and other areas of my life. But I'm not so far gone as to believe my actions cannot effect the outcome. There's still ~6 weeks to go, and I plan to do some damage with them.

Learning to use Genie

Doing some reading on Genie. I'm finding there is a bit of a learning curve to Vala. Once I recover from being so deathly ill this week, I intend to put some focus in learning the only way I know how: by doing.

More Mac trouble

One of the reasons I was accepted into GSOC was because I was able to successfully build and run PySoy on Mac OS X. On a whim, I decided to jump into OS X and run tests on some of the newer iterations of libsoy (e.g. Simple.gs).

Nothing doing. Libsoy and pysoy still build, but there is a nasty memory leak. The test crashes with a bus error (EXC_BAD_ACCESS). This happens with hboxTest and vboxTest as well. I am thinking there is some quirk in Apple's OpenGL implementation that is causing this. I have to focus on development, so I'll continue working on ubuntu. But I really want to look into this.