Revision as of 06:37, 24 September 2008

Kia ora.

Design Study

My honours project is a graphical application to display an animated figure and associated data, written in Python, and using OpenGL libraries. I wish to make this a nice slick OO application, but I'll be facing several challenges.

• Python is a loosely typed language. This makes things easier in some ways (no variable declarations, and no need to cast), but harder in others, particularly as I've never written OO in a loose language before.

• OpenGL is very procedurally based. To get around this I'll have to build some kind of nice wrapper(s) so that we can use OpenGL in an OO way.

• How to relate graphics code to object code. Should each object have a drawX() method, or will this wind up raping and pillaging the neatness of the program? We'll soon find out, so don't change that channel. I suspect this will be the core issue I face in this design study.

Initial State

Before we begin this design study we should look at the project in its present state. It's currently rather a mess. There are currently a small number of objects used, but most of it is a typical OpenGL app with procedural code.

Good

• Camera class. This class will probably make it largely unscathed into the final design.

Bad

• Still mostly procedural.

• Bvh Parser. Creates a BvhSet which has everything from the Bvh file. It would be nice to separate motion data from playback data (frame rate, etc)
• Joint class. This is crying out for subclassing, as root nodes, internal nodes and leaf nodes all behave slightly differently, and currently that functionality is roughly lumped together (eg channels/rootchannels variables).

Preliminary Design Thoughts

Probably I want an application object to work with at the very top level. That would mean a main method along the lines of:

def main():
   animation_application = AnimationApplication()
   application.start()

Wed Aug 20: I'm starting to code up my new enhanced version. I need to deal with OpenGL's event handlers, and my first thought was the Observer pattern, where objects which respond to (say) keyboard commands register with the key-handling object, and are thus notified on key-presses. One issue I have considered is that responses to keys vary depending on the mode of the application. However for the moment I'm just going to implement the the Observer pattern and see what happens (YAGNI and all that).

Update: I'm currently implementing the Observer-based keystrokes, and I've struck a design issue. I have a keyboard object, and I'm wondering where to put it. I have an Application object, and a Window object, and I'm not sure whether keyboard should belong to Application or Window. Application doesn't actually do anything besides create a Window, so I thought possibly this is a cue to merge the two classes. Then I figured this will create one massive class, and from that I figure I'm not breaking up the code (mostly glut calls at this stage) properly. I need to make a distinction between glut initialization (which is global to the application) and window creation (which could potentially happen multiple times, though probably not in the case of my project. So, refactor time.

First OO Iteration

The program is now totally converted to OO (with the exception of a few utility functions where being static makes sense). Here's the diagram.