Marcus D. Hanwell's Blog

I just wanted to let anyone who has not spotted it already know that I am going to Camp KDE in January! I am really looking forward to it and hope to be able to talk with lots of developers and users. I will be giving half of the talk about KDE and Distros. Specifically Gentoo, but also adding my viewpoint as a downstream consumer of KDE.

I am not officially talking about Avogadro, Kalzium and all the work I have been doing there. Unfortunately there was not enough time in the schedule to fit that in too. I would be very happy to talk to people about it, and will have slides, videos and screenshots with me. So, if you are interested and we can find a corner of a room let me know!

I am registered, have flights and a room booked. So much to do - I did all that weeks ago but only just found time to announce it.

After our move to use Git and GitHub to host our repository I got thinking about ChangeLogs. Having a version controlled file, where you manually add details about what the version control system should be recording seems like it should not be necessary. I searched and couldn't find a solution that generates ChangeLogs in the style we prefer, which is a variant of the GNU ChangeLog.

So I wrote a quick Python script to try and accomplish this task. It may not be the prettiest Python code as I have never written more than five or six lines of Python before. ChangeLogs always seemed to be the biggest source of merge conflicts whenever we would work in branches, or just all be working at the same time. This is why I think it is necessary to automatically generate something like this that can be generated with source tarballs.

I called it gitlog2changelog.py and it has all of the basics down already. It may not be the most general script but works pretty well for us. I need to add some extra parsing for file creation/deletion so that we can add the + or - in front of the file names. Is there a general need for this? Are there better scripts out there that I dd not spot?

2008-12-29  Tim Vandermeersch <email@protected>

  ∗ libavogadro/src/pluginmanager.cpp: replace getenv(...) with
  QProcess::systemEnvironment()

  ∗ libavogadro/src/elementtranslate.h: Replace "A_DECL_EXPORT extern ..." with
  "A_EXPORT extern ..."

  ∗ CMakeLists.txt: use /MD compiler flag for MSVC

2008-12-28  Marcus D. Hanwell <email@protected>

  ∗ libavogadro/src/molecule.cpp, libavogadro/src/molecule.h,
  libavogadro/src/python/molecule.cpp: Lots of documentation updates,
  reorganised the functions and grouped in Doxygen tags. Some minor changes
  too, more are needed for const correctness.

  ∗ testfiles/multicubes.cube.gz: Removed from our source as it is the same
  size as all the other files put together. May be we should provide a more
  extensive sample of files in a separate distribution.

  ∗ libavogadro/src/engines/bsdyengine.cpp: Ported to use the new bond position
  functions.

  ∗ libavogadro/src/bond.cpp, libavogadro/src/bond.h: Added functions to
  retrieve bond positions, still need to implement the mid-point function.

  ∗ libavogadro/src/bond.h: Documentation updates.

  ∗ libavogadro/src/python/bond.cpp: Added missing Atom include.

  ∗ libavogadro/src/atom.cpp, libavogadro/src/atom.h: Documentation updates,
  added member function groupings and a destructor.

  ∗ libavogadro/src/atom.cpp, libavogadro/src/bond.cpp, libavogadro/src/bond.h:
  Added some atom accessor functions to the Bond class. This should make using
  bonds easier. Fixed assignment order in Atom constructor.

After some discussion on IRC the Avogadro Project has moved its version control over to GitHub. Our new repository can be found here. Most of us are old Subversion users, and a few of us started out with CVS. I think we are still getting our head around the workflow but feel it is worth the effort for all the advantages the move will bring.

There are some great visualisations from GitHub. I have always loved the speed of Git when compared to other version control I have used. It is also great for adding in bigger changes and not having to halt development in other areas for fear of merge issues. We shall see over the coming months how positive the move was, but I am confident it will be. I have been using Git locally through git svn for over a year now I think.

For those who might wonder, the conversion was not totally automatic. The branches and tags git-svn leaves you with are not Git branches and tags. It basically required me to manually create the branches and tags. So for our repository I ran the following,

mkdir avogadro-git
cd avogadro-git
git svn init https://avogadro.svn.sourceforge.net/svnroot/avogadro --stdlayout
git config svn.authorsfile ../avogadro/authors.txt
git svn fetch

At that point I went and grabbed a coffee, took care of the dog...

git remote add origin git@github.com:cryos/avogadro.git
git push origin master

This got us most of the way there but lacked all of our tags and branches. I found that none of the push options worked as the tags and branches needed to be made into full Git entities first.

git branch -a (show all the branches)
git branch 0.8 0.8
git branch 0.6 0.6
git branch primitive primitive
git tag -f 0.6.0 tags/0.6.0
git tag -f 0.6.1 tags/0.6.1
git push --all origin
git push --tags origin

After all that we have our tags as Git tags and our branches as Git branches. You can browse them and clone the repository. A few of us have been experimenting and everything looks good. Adding current developers as collaborators enables them to push directly to the repository. There are also some web interfaces that allow for pulling from forks.

So if all goes to plan now, there will be no more commits to our old Subversion repository. We have preserved all of our history and I made sure the author metadata was improved. Hopefully this will make our development process more streamlined. We appreciate any and all tips, this looks like a good guide to keeping a fork in sync, pushing and pulling where necessary.

Now back to coding - we want to get a new release out!

I have been using Git and Git SVN for quite some time now. It took me a little while to get into Git and see what all the fuss with DVCS was about. Now I find myself enjoying using Git more and more when it is the only version control in use in a project.

Git SVN is certainly a great compatibility layer, and it has allowed me to use Git as my version control system locally without requiring that the projects I contribute to switch. I had heard lots of good things about GitHub, but had not found the time to check it out until Geoff showed me Avogadro after he had pushed it to GitHub. There are some great stats and it looks like is has some great features. I was originally put off by the 100MB limit on storage as it seemed a little low.

When I got home yesterday evening I started playing with it and ultimately made three Avogadro repositories - the third one looks like it is the charm. I had not been worried about importing author metadata previously as I had just been using it locally, but after reading this short guide to migrating to Git I had all the tools I needed. A short trawl through our mailing lists, web pages and history to update author information and I had a shiny new Avogadro git repository.

I am still getting the hang of how all this works. I have added several other committers it matched up as collaborators, but did not spot what exactly that means yet. I was able to get CIA working in our IRC channel, pushed some changes and even synced up a commit from this morning. So I think all is well and I will likely keep this repo up to date with our development. It only has trunk in it, but shows photos of your friendly Avogadro developers and a really nice visualisation of development over time. I think it should open up with the latest stats first, but other that that am impressed. It complements some of the ohloh analysis quite nicely too.

Now can we all please move our source over to some kind of Git repository please!

My regular readers may remember I talked about the GLSL shaders I was adding to Avogadro. I got my head around GLSL, uniform variables and the loading process. I also raided Molekel for some nice shaders. Ever since I first saw the X-ray screenshot I have loved it. I am very pleased to announce I now have this working in Avogadro!

I will give you a moment to bask in the beauty. It is a really nice visual that helps you to really see what is happening with many surfaces. The image on the left is the classic, as Mario Valle introduced it, along with other great work he has done in the area of molecular visualisation. I was lucky enough to meet him earlier this year at a conference and discuss a few ideas with him.

There are still a few rough edges with the new GLSL code. I hope you agree that the results are quite stunning, I really liked this final image too.

I seem to have made quite a few breakthroughs in the last week or so, and have hardly had the time to talk about them. May be it is due to a bout of insomnia and feeling inspired. I was talking to Geoff about some of the ray tracing work I have been doing. After revisiting a few of the early decisions I made and reading some of the POV-Ray documentation I have managed to make several improvements to the POV-Ray output. The rendering of the highest occupied molecular orbital for benzene looks a lot better (left). I have also been looking at the actual POV-Ray scene descriptions Avogadro outputs and making them as easy to modify as possible.

Geoff recently added a new atom colouring method, colour by atom index, which can give some really nice rainbow like effects. To the left is a large bucky ball rendered by Geoff on a Mac using MegaPOV, and to the right is a nanotube I rendered using the latest beta of POV-Ray which actually split the rendering across all four cores here. Hopefully we will be able to make a new release containing some of these new features in the near future, along with integrating some of this new functionality into the Kalzium molecular editor.

Hope you are not too bored of all the visuals, I am working on plenty of other stuff in the backend and quantum sides, along with some really good work Tim is doing on wrapping our functionality for Python scripting. I even added our first unit tests over the weekend and hope to get at least our core classes covered over the coming weeks.

Last night I finally found a little time to look at GLSL shaders and how best to integrate some into Avogadro. I had been meaning to do this for quite some time but there is always so much to do and so little time! First problem I had was actually accessing the functions to use GLSL shaders. In the end I found a great little library called GLEW that lets me test for OpenGL 2.0 and then ensures all the functions are available.

Both of the images were rendered using medium quality. The one on the left is not using any GLSL shaders and the one on the right is using a phong style GLSL shader. I am not sure it is very optimised, and right now the code needs cleaning up a little before I can commit it. I think it is another great option to use on higher end systems while maintaining compatibility with older systems.

Hopefully I will have more time to play with shaders soon. I wrote a flattening shader that looks pretty cool too. I think that shaders introduce a level of flexibility to our rendering pipeline but I have so much to learn. Being able to effectively ray trace on the GPU is great!