Postmortem: Diploma Thesis, 1

October 12th, 2009

As I’m in the finishing stages (writing ;) ) of my diploma thesis, it’s time for a post-mortem analysis of the source code. This week, I’ll investigate the things that went right and which I’ll try to use in the future again.

  • CMake and the subsequent port to Linux: Making the application portable allowed me to clean up the source code a bit, and get eventually better performance. In retrospective, I should have used CMake earlier in the process to save time porting later. For the next project, I’ll definitely start using CMake as early as possible in the process.
  • OpenGL for all viewers and GUI applications: Even though I’m strongly biased towards DirectX due to the superior debugging capabilities and the cleaner API, OpenGL proved to be reasonably easy to use and made the porting very easy. Using GLSL was not too painful, but I was running on nVidia hardware only …
  • Libraries: SQLite turned out to be very easy to integrate as an intermediate format, and allowed me to store processing data without having to deal with file I/O issues. Definitely a good choice. For reports, I used CTemplate, which was also very easy to use and allowed me to generate nice HTML reports – much better than purely textual output, as I could easily integrate images into them.
  • Text formats: All input/output data would eventually end up in text files. I didn’t use any binary formats, and I could easily debug all data. This turned out to be a major time-saver, as I could parse the text files using scripts as well. Notice that the text files contained data like meshes while SQLite was used for storing intermediate data like per-mesh information.
  • Modular design/Python: The whole processing was designed as a pipeline of several libraries and executables which would transform the data. Some of these modules were written in Python, while most where in C++. Especially towards the end, I could still easily add new algorithms without breaking stuff. This became important as I had to extend one processing module: I could simply write a new module, call the old module were necessary – thus reusing a lot of code – while still allowing me to quickly add the new functionality. All I had to do was to replace the calls to the old module, which were very easy to identify due to the separation.
    Python turned out to be a very good choice for quickly cleaning up data, and together with SQLite I could easily exchange data with the other C++ tools in the pipeline. Much easier than doing that in C++.
  • UI: The applications usually had something like 20 parameters, which became a problem towards the end when I had to run them very often and tweak just a few parameters. The solution here was to write small UIs to wrap the parameters; with PyQt4 + QtDesigner I could get GUI front-ends running in half a day, while saving me lots of time later on. In future projects, I’ll try to write such small GUI runners; one nice point of having a GUI runner is also that you can give a demo more quickly ;)
  • All in all, the programming went ok, and I’ll try to do some things just the same in future projects. Next week (hopefully), I’ll take a look at the stuff that didn’t work out quite as expected.

Anteru Programming

Leaving the Côte d’Azur

September 28th, 2009

It’s time to leave, this week, my time at INRIA has come to an end, and I’m leaving the south of France to exchange it with the cold winter in Germany. I’ve been here now for six months to finish my studies, and I’ll be hopefully able to write about the results soon – at the moment, we’re working on the paper.

The next three-four weeks are going to be quite busy for me, as I also have to write up the results for my diploma thesis which is unfortunately expected to be longer than a standard paper ;) Moreover, I have to tidy up a few loose ends regarding my studies, so I can properly graduate. The net result of all this stuff is that I might not be able to blog as regularly as I did the last few weeks, as my backlog is currently completely empty, and even though I have quite some stuff in the pipeline, none of it is ready for publishing. One thing which is definitely ready will be out by December this year … stay tuned for more details on this.

Anteru General

Linux developer tools

September 21st, 2009

After switching to Linux recently at work, it’s time for the follow-up post with the tools I currently use for development.

Core tools

For compiling, I use the standard GCC – currently 4.3, which has support for OpenMP and is more or less on par with Visual Studio 2005/2008; C++ support is quite good, and I had minimal problems while porting. It’s also faster during compiling than VS 2005, which has some weird problems with some generated code I have thrown at it (took 30 minutes to compile a 500 KiB file containing straightforward C code.)

For building, I use CMake, and by now it should be clear that I like it :) I’m really happy so far, especially because it allows me to generate standard makefiles on Linux as well as KDevelop/Eclipse projects. In particular, it is also supported by Qt Creator which can open CMake projects directly. I tried both KDevelop and Eclipse, but Qt Creator really wins hands down at the moment, even though it lacks a bit of polish. Just make sure you use the latest released versions, my Ubuntu came with 1.0 (while 1.2.1 was current), and it’s really under rapid development. Supposedly, Eclipse CDT 6.0 also brings a lot of improvements, so I have to give that a try.

Side note on building: I replaced a bunch of batch files with Makefiles, which are really handy for various tasks. Especially as you can build any crap with them, including UIs and documentation without any problem ;)

For profiling and memory checking, you can use the excellent valgrind tool (together with callgrind and kcachegrind). Especially for memory checking, valgrind is probably the best tool you can find, and if there is a good reason to port, then valgrind. It runs the code in a virtual machine, and logs all memory accesses, so you can easily find every memory leak, off-by-one-error and access to uninitialized memory, without having to modify the application.

For UI development I use PyQt. My tools were written using Python anyway, and adding an UI with PyQt was straightforward. You can leverage the Qt Designer to create UIs for it (it comes with a custom compiler), and it’s straightforward to integrate. Nokia also provides a LGPL alternative – PySide – which might be interesting if you develop commercial applications. For me, the more mature PyQt turned out to be a good choice, didn’t have any problems so far.

Other tools

There’s of course a bunch of other tools you need as a developer, and some of these are not exclusive to Linux, but I add them here as well – some of them might be a good choice to use on Windows, as you can continue to use them on Windows.

For editing, I use Kate and VIM – VIM is very nice when it comes to large files, as it is very fast even on 500+ MiB sized files. Kate is a simple text editor, nothing fancy, I guess the closest Windows equivalent is Notepad++.

For mail, I use the stock KMail, after trying Thunderbird (which is my primary mail client on Windows). KMail is an integrated part of the KDE desktop, and feature-wise I’d argue that it’s on par with Thunderbird, I’ve yet to find a missing feature.

All my documentation is now written with asciidoc – a very nice documentation generator written in Python. It requires only minimal markup so the files are still readable as plain text, which is a killer feature compared to docbook and friends.

Well, doing graphics, I also need a 3D app, and in my case I run Maya 8.5. It works nearly without problems (sometimes, the UI shows some weird transparency in the outliner, which might be related to compositing …), and I’m simply used to it. Installing on Ubuntu is a bit tricky (you should follow this excellent guide) , but it’s possible, including license management from network and mental ray rendering. I gave Blender a shot, but until they start to follow some basic UI guidelines (left-click selects, for instance), I see no point in learning Blender. Don’t get me wrong on this, I do believe that Blender is a great tool, but you have to invest a lot of time to learn it, especially if you used other tools (in my case, Maya and MAX) previously. For image editing, I use GIMP.

Summary

That’s probably the tools which account for 99% of my work time. I hope you find this list useful if you come also try to get started with Linux development, at least I would have saved some time if I knew it beforehand :) What’s very nice about nearly all of this tools is that installing them is very easy, as they are free and directly available from the package manager – something which I miss on Windows.

Anteru Programming

Yachtseeing in Antibes

September 20th, 2009

In case you’re in the area, and you want to see a few nice yachts, head to Antibes today. Right now, there’s a bunch of yachts in he harbour, among others:

… and a few more of nearly the same size which I missed ;) . Specifically, the “Quai des Milliardaires” at Antibes is crammed up to the last place, and the rest is at anchor around the harbour.

Anteru General