As some of you may already know I’ve been continuing the development of Glue Editor. Things are coming along nicely as the end of the first iteration approaches. I would like to share with everyone what I have planned for Glue Editor in the coming months and find out if I’m heading in the right direction. Your honest opinion is appreciated :)


Building a game with Ogre or Mogre has never been an easy task. The Ogre graphics engine provides incredible rendering capabilities and great flexibility to build whatever type of game you can dream of. However, putting together a complete and finished game takes a considerable amount of programming effort “gluing” the graphics engine to physics, sound, GUI, networking and so on. Once all that’s done the various art resources are created such as meshes, textures, sounds and collision shapes.

Many of these resources can be created with your favorite modelling program, paint program or sound generator. Yet, there’s still something missing. Placing all of these resources together into a game could be hacked together in code and exported from modelling programs with a little blood and sweat but it never feels nearly as productive as it could be.


Glue Editor’s primary purpose is to fill the missing gap. To provide a productive tool to piece together the various resources into levels for your Ogre game projects. Then to be able to save the levels into a file format easily loaded into your game containing the data to let the graphics, physics and sound engines to do what they do best. To help you provide the best interactive experience for your players in the shortest development cycle possible.

I’m developing Glue Editor using an “Agile” approach in my spare time in monthly iterations. At the start of each month I set some goals to achieve during the iteration focusing on what I can do to provide the most value towards the ultimate goal. The main goals of an iteration are called stories and are from the perspective of the user, for example: “As a user I want to be able to rotate objects so that I can make more natural looking scenes”. Then these high level goals are broken down into smaller tasks, prioritised and picked off one by one. At the end of an iteration any half finished features are polished, removed or disabled to get the program ready for a release and/or the remaining work is rolled over into the next iteration.


I’ve made some great progress this month, using the Agile approach and defining some clear goals have really helped focus on the important features and not get distracted by the less important stuff. The project has already come a long way from where I left it a few years ago. I had to pull it apart and put it back together to lay the foundation for new features so many things are still broken. The one question remains, what should I really put my blood and sweat into next iteration?

About two weeks ago, shortly after finishing part 3 I got in contact with Cygon from the Mogre forums. As far as I could tell he is the only person who has sucessfully wrapped the Terrain and Paging component into Mogre. With his help, I’ve managed to integrate his changes into the MogreBuilder to finally bring Mogre up to date with the latest stable version of Ogre (v1.7.4). This is great news for the Mogre community who have been longing for Terrain and Paging in the official build for many months.

Terrain and Paging

My first attempt at getting Terrain and Paging into Mogre was to try and figure out how Cygon had done it from the scattered bits of information floating around the forums. This worked up to a point but I ran into a wall when the AutoWrap tool failed to pickup the files. A little more digging around and I got a little closer followed by one failure after another. Cygon kindly offered to give me a copy of his entire codebase from when he manually wrapped Terrain and Paging with Ogre 1.7.3.

I was very excited when the email arrived with a link to download his code. Eager  and try it out I quickly dumped the code into the MogreBuilder and ran it. After a little tweaking it spat out some binaries. I threw together a really quick test using the Mogre Terrain and Paging sample on the wiki combined with the samples code found in the last installer. It worked like a charm and I went to bed with a grin :)

Mogre TerrainAndPaging Sample using binaries built with MogreBuilder

The following weekend I sat down to clean up the code and get it loaded into the bitbucket repository. This turned into a bit of a chore because the code that I had was a few months old and I had to merge the changes with more recent changes in the repository. Added to that was updating the patching tool in MogreBuilder because Cygon’s patch wasn’t compatible with hg. I also added an extra patch to improve the size and the resulting DLL’s and remove some code not used in C#. Thanks again to Cygon for providing these changes.

I’m pleased to say that in the end it all went well and the Terrain and Paging components are now included in the official MogreBuilder. This should make it easier to maintain future builds of Mogre and might lead the way to getting other plugins wrapped.

Automatic version updating

Another small but important change I made during this iteration is automatic versioning of the Mogre DLL. Thanks to Ümit YILDIZ for pointing out that the previous lot of binaries indicated a version of 1.7.1 even though it was built against Ogre 1.7.4. To correct this issue I added a task into the MogreBuilder to automatically detect the version of Ogre and update Mogre’s assembly information to match.

Here’s a snippet from Ogre’s OgrePrerequisites.h

// Define ogre version
#define OGRE_VERSION_NAME "Cthugha"

And the resulting code in Mogre’s AssemblyInfo.cpp


Using this approach we could also add the Ogre version name or add an additional digit into Mogre’s version using the MogreBuilder config. I’ve left this task for another time.

Mogre Samples

I’ve also added a new Terrain and Paging sample to the Mogre samples found in the installer. Unfortunately, there is still nowhere to load my changes on bitbucket so instead you can download them directly including the binaries, source code and media.

Download Mogre Samples including Terrain and Paging

The end result

I really couldn’t have asked for a better couple of weeks on this project. All of the important chips fell into place at the right time and delivered some great improvements for the Mogre community. I’ve learned a lot about the Mogre build process and I feel more confident that I can help maintain it in the future. Thanks to everyone who provided feedback, it makes all the difference.

Download Mogre 1.7.4 binaries with Terrain and Paging

And of course, the source code is available in the bitbucket repositories.

Shortly after posting the first part of this series on improving the MogreBuilder I was contacted by another user (McDonte). He had been working on a GUI frontend for the automated build tool a few months back and I had offered to host the source code and binaries on my web-host. He sent me a copy of the code and I tested it out. I was hoping to make this part of the series about integrating the GUI but unfortunately, there are still few outstanding bugs to sort out. I was a little conflicted about how to proceed with the GUI side of things, so instead I did what I could with the command line version.

McDonte’s GUI

McDonte did an awesome job creating an option rich GUI to cover just about everything you could think of in the build tool. He also added the missing tasks to automatically download the Ogre source code as part of the build process. I was hoping to be able to build Mogre easily with the GUI, but I ran into a number of issues including:

  • The calls to hg had a syntax error because the -u option was missing from the command line.
  • Cmake reported an error but did not provide a reason.
  • I had to set the paths to TortioseHg and Cmake each time I ran the tool.

Once these issues are fixed I’m sure the GUI version of the tool will be released in one form or another.

The bitbucket repositories

A couple of days later I asked Beauty if I could have access to the MogreBuilder and Mogre repositories on bitbucket. This was no trouble and I uploaded the changes I made to the MogreBuilder command line version.

User Tubulii downloaded the binaries that I compiled last week and tested them out with the Mogre samples. He also had to build MOIS for the input system. Ideally, my goal is to make it easy to grab a copy of the repository and build Mogre out of the box with minimal effort. So it stands to reason that MOIS and the samples should also be included in the build process.

The Mogre samples

Surprisingly the source code for the samples is not on the bitbucket repository. For some reason, the only place the source code could be located was the Mogre installer for version 1.7.1. This is not really acceptable, so I plan to upload the sample source code to bitbucket shortly. I only just managed to get them to compile and run on my machine tonight after some messing around with the project settings.

Every time a new version of Mogre is built it is handy to be able to run through the samples as a smoke test to make sure everything went well.


I’m pretty happy with the progress this week, even though there is not a lot to show for it. The feedback has been great so keep it coming :)