Blender User Interface Tutorial

Wanting to add a little spice to a talk I have to give I decided I'd investigate Blender, the Python 3D rendering application. The idea was to see how easy it would be to create a modest 3D animation. Blender has a reputation for quirky interface so I was intrigued to see how quickly I could get started and expected something in the way of frustration.

I'll ignore download and installation as I'd done it some time ago, and I suspect it must have been easy because I don't remember any problems. I'd played with the program a couple of times and given up because its behaviour seemed so counter-intuitive, so this time I decided to work through Bart Veldhuien's Blender User Interface tutorial, two clicks away from the web page that came up from the Help menu ("can't be that counter-intuitive if I can find the tutorial," I thought).

I noticed that at the bottom of the page it said "This page does not have a maintainer. If you would like to help, please read 'Getting Involved'" and if you've already followed that link and it hasn't changed you will know that a charitable instinct is rewarded with the news that "We have received many offers for help lately and we need some time first to get everyone going." followed by an invitation to join up for the website editors list. Maybe later, I thought. For now I'm just going to critique each section of the tutorial as I work through it.

Introduction explains the motivation behind the creation of the document - apparently Bart was himself intimidated by Blender at first and took several weeks to to discover the basic princiles behind Blender's interface. Well, I'm certainly all in favour of saving several weeks, so I ploughed on.

What am I looking at? is a walk throught he empty blender scene, explaining that the stripe across the top of the window is called the info window. This has the 3D window underneath it with objects representing the standard plane (whatever that may be), the camera and the lamp with a 3D cursor. At the bottom is the buttons window, apparently used for changing scene characteristics. I read that each window has a header, and that the header of the 3D window is at the bottom. I'm not sure I need to know how to reposition these headers at this stage, but I learn that. I am told that the Icon slider button can be used to select a window type, and wonder why it isn't called the window type selector button. There's a lot of that kind of stuff going on.

Configuring the screen your way tells me how to change the size of the windows, and to split windows (thereby creating new ones) using the middle button (which, since I only have two buttons, I fortunately know how to emulate by chording the right and left buttons). I accidentally activate the "No Header" feature of one of my new windows, and in trying to put the header back I remove the header on the window next to it. This makes it difficult to use the information that the window having the focus is displayed with a lighter-coloured header. I manage to get the headers back, and use CTRL/up-arrow to "make the current window full screen" (which actually makes the current window occupy the whole of the Blender window - couldn't they have chosen another name for their "windows"?) and return the view to multi-window. So now I have four 3D windows described as "the traditional four-view window" (so are windows really views?), though unlike the illustration my 3D views are all showing pretty much the same thing.

The Toolbox - Adding a sphere explains that Blender functions can be accessed by either keyboard or mouse, and that the toolbox appears if I hit space or click on "the toolbar icon at the top right of the Blender screen" (so am I dealing with views inside windows or windows inside screens - I wish the terminology were more consistent here). Unfortunately there's no picture of the icon, and a three-minute hunt where I click on almost everything doesn't reveal it, so in the end I just hit the space key. I'll find that darned icon later. I discover that the space key only works when a 3D view or window has the focus. I am told to select Add, then Mesh from the menu that appears, then UVSphere from the final menu. I do this and then apparently move the mouse too far, because the resulting popup, which is supposed to allow me to select the number of segments in the sphere, disappears before I can use it. Now for some reason my toolbox "Add" item no longer shows "Mesh" as an option, the Mesh item appears in the toolbar but the shapes I can create are hanging off the "Add" item. Boldly ignoring this menu transmogrification I finally manage to insert a sphere into my 3D window, and it gratifyingly appears in all four views.

About Edit Mode explains that you can operate on an object as a whole, or on the individual vertices of an object. My newly-created shpere appears to have about four hundred closely-spaced vertices, and I wonder how to select just one or two of them. It mentions in passing that the G, R and S keys translate, rotate and scale respectively. I guess there must be some really important other operation that begins with T. Undaunted, I attempt to G, R and S my new sphere into something I can work with. I learn by experimentation that rotation is a two-phase operation where you first rotate in one plane and then in another. I realise that am wrong, and that rotation actually appears to be much more complicated than I had thought. My sphere is now at least large enough that there is space between the vertices. I fail to learn how to select individual vertices, but this may not be a bad thing.

Loading and saving your work optimistically begins "By now you have probablky created a Blender scene", which I suppose I have even though it only has a single sphere in it. It suggests I might like to save my work, or take a look at some of the files that come on the CD that comes with the book (which is annoying, because of course web pages don;t have attached CDs).

Loading a Blender File tells me how I can load up a new file. There isn't anything that I cna see to load, but it's obvious from the dialog that Blender's approach to opening files is just as quirky as everything else appears to be. I discover by accidentally selecting Quit that Blender isn't one of those applications that will warn you about unsaved work before quitting, and lose everything I've done so far. I restart Blender to see what I can remember. I see that Blender has forgotten about that nice four-pane view it took me so much trouble to create, and wonder whether that would have been saved with the file, had I realised that the next section is ...

Saving a Blender File which tells me, only a few minutes too late, that saving works pretty much like loading. I try to create the scene I had before, with rather limited success, but I do manage to create a scene and save it. Then I modify it and, in opening up the previous scene I learn that the cavalier attitude to current work is repeated when loading files. I curse Blender, and wonder when I will start to learn how to use it properly. I curse again because this is the end of the user interface tutorial.

Well, that was interesting. Fortunately there's a whole host of other material available, as indicated in the sidebar of the web tutorial I've just been working from, and some of it at least looks quite helpful. Having had to work with CAD programs in the past I'm well used to complex interfaces, and resigned to the fact that a certain complexity is inevitable. I have to question the wisdom of providing application-specific file load and save dialogs, however, when most GUI toolkits give the programmer ready access to the platform's standard dialogs.

It's definitely not helpful that there doesn't appear to be any standard terminology surrounding Blender (e.g. the tutorial describes the Info Window, but this is actually selected in the program's menus as User Preferences - how is this supposed to help?) and overall the beginner gets the impression of a professional-grade program with amateur documentation. The usual qualifications apply, of course. Since this is open source, nobody is forced to write manuals for the software, and anyone who's spent the time to find out how to use Blender would probably rather play with Blender than write documentation.

I am also surprised that Blender doesn't by default open up with a four-pane view of the scenes, since later experience shows that this makes manipulation of the objects in the scene much more precise and much less counter-intuitive. It's particularly galling that the four-pane (top/fron/side/camera) view of a scene isn't stored with the scene, so it had to be re-established each time.

Now of course it may be that these complaints are in fact invalid, and that it would be possible to make Blender behave in what I, at least, would find a more natural way. If this is the case, though, there is even more of a crying need for adequate documentation. So far I haven't even learned how to select objects in the scene, let alone use the many buttons in the buttons window. Overall I'd advise against picking up Blender if you're in a hurry to produce some impressive graphics for that important presentation. It will take time and patience to master this software, possibly more of each than I currently have.

Firedrop2 Revisited

My initial experiences with Firedrop2 were recorded as Open Source Frustrations. I'm happy to say that the initial problems in running the software were eventually traced to an error in the installation of the wax GUI package. At the time it looked like everything was copacetic, (making my remarks at the time about how trouble-free the installation was quite ironic) but alas needed sub-packages weren't installed by wax's distutils setup, so it was only after I did a manual install that Firedrop2 finally started to run.

As a result of all this Hans Nowak, to whom I reported the problem like a good open source citizen, has decided to stop using distutils. My own experiences with distutils have also been less than entirely happy, and I wonder whether in the long term we might not end up using something more like setuptools. While its developers acknowledge that it still isn't perfect I am sure they will be valuable enhancements to the distutils before their developers are finished.

The Firedrop2 tests are still completely broken, and they should be removed until they are worth running. Tests that fail when software is correctly installed and functioning are worse than useless, and give an incorrect impression about the software. In this case I suspect that they were vestigial when the software was handed from one developer to another, and that they haven't received any attention since.

It's also clear that the software hasn't yet been engineered for general use: simple problems like a missing configuration file result in a Python traceback window that would be excessively confusing to a non-Python user. After a few such errors, however, I realised that I needed to create a blog configuration before anything else would work. Once I'd done that, and edited the configuration to taste, things did start to work.

The function of some of the buttons remains far from clear, but the basic entry creation, editing and publication functions do seem to work.

President Spy

From the point of view of public morale, the US response to the 11 September airliner attacks was probably the worst choice of the many that President Bush could have made. Why not instead try to persuade the American people that the best response was to demonstrate that those atrocities would not change the American way of life?

It appears that it suited the foreign policy agenda, though, to undertake an unwinnable war on an abstract enemy without any definition of "success" that could be used as a decision point to cease hostilities. Broad powers were accepted in haste by a panicked Senate and Congress, and those powers can effectively be used against anyone who is perceived to be dangerous.

We now learn that under Bush's "control" the NSA has felt free to ride a coach and horses through what few protections were left to American citizens by the PATRIOT act. The Electronic Freedom Foundation asks the question: "what good is legislative reform if the Administration considers itself above the law?"

Of course the Guantanamo Bay imprisonments have already made it clear that Bush is prepared to redefine the parameters of acceptability to gain his own ends. Along with his repeatedly revealed contempt for domestic law, he feels that international law is insufficient to cope with terrorists. This reveals a disdain for the rule of law that casts doubt on Bush's suitability as the leader of the free world, should further doubt be necessary.

The tally of American dead "supporting operation Iraqi Freedom" continues to rise, and is now higher than the number killed by the 9/11 attacks. If America were invaded and occupied in the same way that Iraq has been the resistance to the invaders would be immense. Yet the power of the media and its collusion with the administration is such that the average American still believes that freedom is something that can be imposed by invasion and coercion. How much better it would be if America looked to its laurels and put its own house in order, thereby lucidly demonstrating the advantages of freedom and democracy in a practical way.

If democracy means that the security services can breach citizens' constitutional freedoms with impunity, how is it better than an arbitrary dictatorship?

Open Source Frustrations

This is a tale of how a simple attempt to use a piece of open source software descended into a frustrating and unpleasnt experience. Although specific sites are mentioned herein the lessons, if any, are intended to be generic. I have come across other sites pointing to the same absent download.

A recent search for Python blogging clients took me to the Voidspace web site and thence to the Voidspace Firedrop2 page. About two screens down the enthusiastic puffery I found what purported to be a link to Firedrop's home page, but was actually Hansje Novak's open source projects page.

This did contain some material on Firedrop including a number of links to pages showing a download link, which sadly contained not a trace of firedrop2. A search for "Firedrop2 download" revealed that the package was now maintained by the author of the first link, but the only download available was a link to the Subversion repository with the rather off-putting comment "There is a public repository of the bleeding edge version, which I try not to break. ... The version in SVN is slightly more up to date than the released version. New release to follow soon !" No links to the mythical "released version", though.

OK, I've now been poking around for this tool for five minutes and so I guess I should try Firedrop. So I fire up Tortoise (the easy way to interact with Subversion repositories) and find that there's a firedrop2 branch, but nothing I can spot in the trunk (which is where stable versions normally live).

So, I figure I've now invested ten minutes in locating this frigging software, why not take a look at it. I create an empty directory and download the firedrop2 branch contents into it. Oops, no README or anything else that purports to be documentation. So, back to the web page, where I find a section on "Installing" that begins with the useful warning "Currently Firedrop2 doesn't work out of the box. You must follow these instructions. I will address this issue soon." Better than no warning at all, I suppose, and it appears that all that's required is to drop the software into a directory on the Python path, but a little less than satisfactory.

Before I go any further I scan back up the web page I've been using and spot this tip: "Firedrop2 is written in Python and uses Wax for the GUI ...". So I follow the Wax link, end up on Sourceforge and download Wax. This, it appears, uses a standard Python distutils installation, which I can handle quite easily. So, fifteen minutes after I start, I think I'm in a position to install Firedrop2. At least I can import wax from Python.

So now I have to drop Firedrop2's installation into a suitable directory and ... erm ... yes, some documentation would be useful here. Just to make sure everything's kosher it would seem sensible to try and run the tests in Firedrop's test directory (at least there are tests). The first test fails due to the absence of some file. The second fails because I've mistakenly installed the software as Firedrop2 instead of firedrop2. Ho, hum. After renaming the directory the second test succeeds, but the third fails with ValueError: too many values to unpack. This looks like pretty fundamental stuff to go wrong, and I've now spent over twenty minutes poking around in this stuff for zero net gain.

A further ten minutes poking around and I've managed to create a data file that passes the tests. Still ten further minutes and I've got the whole test rig working. However, I have to ask myself: if the tests are so crappy, how good is the software itself, and how do I get it to work without documentation and a properly working test suite. So. let me remind myself how I got here: a recommendation from someone who said:

• Firedrop2 - The Python Blog Client.

  This is a nice blog tool that runs client side. This means you can maintain your blog offline and migrate your blog to a new server with the minimum of fuss. It has some useful plugins like an emailer and spell checker.

Really? Finally, just to confirm my suspicion that the whole deal is hopelessly broken I go into the main directory and run wxfiredrop.py, which results in the traceback

   C:\Python24\Lib\site-packages\firedrop2>wxfiredrop.py
  Traceback (most recent call last):
  File "C:\Python24\Lib\site-packages\firedrop2\wxfiredrop.py", line 32, in ?
    from firedrop2.mainframe import MainFrame
  File "C:\Python24\lib\site-packages\firedrop2\mainframe.py", line 22, in ?
    from wax.tools.errordialog import ErrorDialog
  ImportError: No module named tools.errordialog

I presume someone, somewhere, is using Firedrop2, but after this experience it isn't going to be me without a solid indication that its current problems have been solved. Unfortunately this kind of thing is all too common in the open source world. I can't estimate the number of times something like this has happened to me, and I can't believe it doesn't happen to other people as well. Sometimes I roll up my sleeves and start to fix the problems, but other times I just mentally shrug my shoulders and write the wasted time off to poor release engineering. In this one case I decided I'd invest a little more time in documenting my frustration, to see whether this is a common occurrence.

I can quite understand how this situation comes about, and as long as individuals are maintaining software on their own dime and in their own time we probably won't be able to do much to address the problems. If we could find some way of avoiding this situation, though, I'd be really happy. Even just regular link checking might help. Perhaps that can be one of my missions for the New Year. I'm going to try a few Python project installs and document my experiences. Hopefully this will do at least a little to improve overall quality control - or at least let some others avoid similar time-wasting experiences.

It goes without saying that if you have a working copy of Firedrop2 I'd be interested in hearing from you!

Sloppy Thinking

Seth Godin published a blog entry bemoaning his neighborhood's clean firetrucks. He attempts to make the point that organisations spend too much time on busy work, concluding with this thought:

What a great way to describe a stuck but busy organization. "They sure have clean firetrucks."

But he misses the point. Firemen clean the truck when there's nothing else to do. Quite apart from the beneficial effects on morale and esprit de corps that such cleanliness engenders, you really don't want a fire service that's busy all the time.

Such a fire service can't afford a single idle moment: queueing theory tells us that a 100% busy resource inevitably falls behind, as it can never recover any slack time that it experiences. Given the urgency with which a fire service is required when it is required, I'd much rather see clean fire trucks (which, by the way, in the UK are called appliances) than have to wait when I need a fire put out.

I've enough respect for Godin that I'm prepared to overlook his stretching an analogy to make a point, but I'm sure a lot of people have given him hell for "badmouthing the fire service".

Blogging by email

Apparently now I can illuminate the world with my iridescent thoughts from any email client in the connected universe. I somehow doubt this is going to help the sum total of human knowledge, but it will be deucedly convenient for making sure those odd little observations don't get
overlooked.

Turns out that the emails appear as drafts in the blog, giving me a chance to polish the thoughts before they appear before an amazed public. Which is how this second paragraph got added.

Having finally bothered to discover how to put sensible titles on blog posts, I now find that Thunderbird displays the updated posts with the date they were edited rather than the original publication date. Ooops...

Happy New Year!

I decided that it would be good to get in touch with the larger Python environment, away from my usual newsgroup sources. I'm happy to say that there seems to be a very active community, with many Pythonistas commenting on what's going on.

The best overall site for this kind of information appears to be Unofficial Planet Python, which has a great selection of feeds. Maybe one day they'll add one of mine.

Last year's runaway success in the web world appeared to be Ruby on Rails, and the Python community's initial reaction was something like "it's all over, Ruby has won the web battle". I always thought this was a bit feeble, so it's been good to see Ian Bicking coming back with a reasoned response triggered by Peter Hunt's How Python Wins on the Web and a reminder that Python has many web successes behind it as well as not a few still to come.

I'm not really one for language battles (despite having been labelled on the python.org Wiki as a "language bigot". Programming languages are tools, and one should choose an appropriate tool for each task. Python's chief virtue from my point of view is the way it seamlessly welds together great facilities for both procedural and object-oriented programming. If someone finds PHP or Ruby a better language for a particular purpose I don't really see that detracting from Python.

If the energy that goes into hand-wringing went instead into producing better and more usable Python applications, this alone would help to redress the balance (if indeed it needs redressing).