For the next part in Gamasutra’s ‘Tooling Around’ feature, which profiles and interviews middleware and tools developers about their products, today’s interview is with Steve Streeting, project lead for the OGRE 3D graphics engine. The object-oriented graphics rendering engine is released under the GNU Lesser General Public License - it’s a free release, but under the condition that users will release the source code for any modifications they make to the engine and will either pass on the engine source code or link back to a source distributor. Version 1.0.0 of the engine was released in February 2005, with the most recent version, 1.4.2, seeing a release last month. OGRE is a “scene-oriented, flexible 3D engine” written in C++ designed for the production of programs using hardware accelerated 3D graphics. The product’s website notes that this does not make the engine ideal for games production without the addition of other toolset libraries, though it adds that it “can be (and indeed has been) used to make games”. The team also make note of the fact that OGRE is “design-led rather than feature-led”, suggesting that this provides the overall product with “quality, flexibility and clear documentation”. We spoke to Streeting recently, and asked about OGRE, its initial and continuing development and the legal issues surrounding its use on consoles. When and why was the OGRE project started? OGRE was started in early 2001 as a spin-off from a personal project I was working on at the time which was a Direct3D (version 5 or 6 I think) wrapper which let me bury the D3D API under a layer of sugar so that my code wouldn't have to be infected by how ugly it was back then - and arguably still is to some degree. I open-sourced really because I'd released a fair amount of my code in the past and open source seemed like a good way to formalize that. It was only over time that my appreciation for the open source model grew, as opposed to developing alone and 'dumping' code publicly as I'd done before. What were your aims and goals at this time? There were several core principles, and they still hold true today. First and foremost was a desire to make a real-time rendering component that combined power and intuitiveness, whilst assuming nothing about the application using it. At the time there were a lot of engines that were designed entirely around a technical feature, or a level format, or a game type etc, and I hated that. I wanted a drop-in component that could have plug-in specializations or simply usage patterns for handling particular structures or approaches. Besides the fact that the rendering would be real-time, which guides particular choices, I didn't want to assume anything else, to ensure it had the widest possible audience. Another major principle was design and coding standards. I'd seen so many freely released engines whose code was, frankly, a sight for sore eyes and it really didn't have to be that way. I knew from the start that this was going to be a long project and so maintainability and extensibility were of major importance if it wasn't going to degenerate into a mess and need a ground-up rewrite every couple of years. So we've tried to keep our code clean, adhere to established design patterns, and make everything as self-explanatory as possible from class names and methods names to the code itself. Why do you think there is a need for an open source graphics engine? Real-time 3D is huge. It has so many applications - games are the most obvious but there are educational applications, scientific projects, industrial applications, architectural visualizations, interactive art, and simulations of all kinds - from military to underwater robots, to first aid training. The mainstream game engines target a particular segment of the market but they're not appropriate for everyone, even within the game industry but even more so outside it. An open source graphics engine that hits all the right buttons has the potential to cut across a huge range of sectors and provide a solution for a vast range of application types, for very little cost. How did you begin development? It started with just me porting my D3D wrapper classes to a more generic base - I realized that I was hiding D3D so much it really didn't have to be D3D anymore, or even Windows or a PC. So I began by abstracting everything which eventually formed the base of what you see now, a rendering component that runs across D3D and OpenGL, runs on Windows, OSX and Linux and has been ported to PocketPC and a couple of consoles, albeit unofficially so far. How difficult was it to coordinate development, and has it become easier? It's been a learning process. When I started I didn't know anything about running an open source project, and I've just kind of felt my way through it. Luckily we grew fairly organically so we've adjusted as the audience has grown. We still run things on a sort of 'shell' basis - there is a certain highly trusted core of developers who can do anything anywhere in the source, and around that we have particularly good members of the community who look after particular ports, particular tools or plug-ins, or who moderate the forum. All our code is public immediately it's committed so we get lots of feedback in the forums and we route important outstanding items through a public bug tracker, and encourage people to submit patches for review if they change something, fix a bug etc. Most things are organized and discussed in the forum, which we like - some projects use IRC more, but personally I find forums more useful, since the discussions are permanent, categorized, moderated and searchable - long term I think that works better as an organization mechanism. Having said that, we are on IRC on occasion and also coordinate releases that way. We also make heavy use of branches in our code repository, both for separating stable bug fixing branches from the main development trunk, and also to separate potentially disruptive work such as core API changes. It's my job to keep all that organized and perform merging across the branches as appropriate. What was the development time on the product, and what challenges did you run into in preparing the product for industry use? On a calendar basis we've been running for 6 years now, but much of that has been in spare time, and many people have come and gone from the team, and from the pool of people who contribute code. Ohloh.net estimates 69 people years of effort in total, although I'm not quite sure how it arrives at that! Challenges-wise, one was becoming organized enough to handle production projects - that meant making a real commitment to not just developing code, but on stability: keeping stable branches available and doing bug-fix releases regularly and such. Another was responding to those who have pressing needs in a timely fashion - the community does a fantastic job in providing support but occasionally people making real investments need more specific or extensive help than can really be done pro-bono. It was for this reason that we set up Torus Knot Software to handle commercial spin-off work like consultancy when people needed it. I think that's helped give some people more confidence in investing in using OGRE. It's a comfort knowing that if the community can't solve your problem - and the vast majority of the time it can - you have a safety net where you can grab a chunk of the project lead's time if you really need it. Console use is also a challenge, from both a technical and legal perspective. We're not console developers ourselves and our open source license (LGPL) tends to be incompatible with console devkit agreements. OGRE has been ported unofficially a couple of times to previous-gen consoles but we're getting increasing interest from people wanting to use it officially on consoles, particularly with the recent developments in online distribution. You can do this under the LGPL up until the point where you have to give the end result to someone outside the company - at this point the LGPL conditions kick in and it starts to become legally difficult. For this reason we've made an alternative commercial license available from the latest stable release for people that want to pursue it. We can't, at this stage, support console ports ourselves - and unless any of the console manufacturers fancy sponsoring us with a devkit or two, we can't afford it - but are happy to assist third parties doing this. As it stands most people are using OGRE on PCs and Macs presently, although I'm aware of a couple of companies who are experimenting with next-gen console porting. How has the product developed, and who has been most instrumental in these changes? OGRE has really lived up to its original intention of being a long-term project that evolves and stays current with technology whilst still staying intuitive and without needing a rewrite. I'm very pleased that as of now we're often considered to be one of most advanced open-source rendering engines available, whilst still sticking to our original mandate of usability and design quality. We've been through the fixed-function to shader-driven models without the major restructuring some engines have needed, for example. As for who was most instrumental, really it's been a group effort. I've been the one constant throughout, doing a fair portion of the development and 'steering the ship' so to speak, but there have been a huge number of people contributing good code, providing test cases, providing advice and support and so on - it would be unfair to identify a single person as the most instrumental. Probably most other people you ask would say it's me, but I think it's the community as an entity, of which I'm a part, that has made OGRE what it is. How have you acted on feedback to improve the product? In far too many ways to count! Being such an open project, suggestions, fixes, enhancements come through on a literally daily basis and we always try to respond to that. Our roadmap is clearly indicated so everyone can see where we're going. How does the product work on a technical level? It sits above the low-level rendering APIs like Direct3D and OpenGL and provides a scene-level interface. Plug-ins can provide implementations of many things such as render APIs, scene management structures, custom object types, and resource archives. Everything is implemented in C++ with a little assembler here and there, although there are wrappers for scripting languages like Python and Ruby, and also for .Net. Do you feel your product works best when combined with other middleware? Absolutely, it's designed that way. There are example integrations with several physics engines, sound systems, GUI systems and plenty more. We leave it up to the user to decide what libraries to pick for other features, which means they can more accurately reflect their own individual needs rather than us picking a single arrangement for them, something which more game-focused engine do but can lead to significant rework for those who have differing needs to those originally envisaged. We believe in a component-based approach from the beginning – other people have built arrangements of components that are useful for jump-starting particular types of project but we stick to being independent of that and hence more flexible. What are some of the more notable examples of the product's use and who is currently using the product? The Featured Projects section of our gallery is a good guide here, but uses include commercial games such as Pacific Storm from Lesta Studio and Ankh from Deck13, educational software like HCA: The Ugly Prince Duckling and 'serious games' like FirstAid Sim by Guppyworks, technical demos of new rendering technology like WindLight and Nimble from Windward Mark Interactive (now owned by Linden Labs), interactive TV show games like Agent Hugo, design tools like Live Interior 3D... lots of things, basically! What do you see as the next evolution of the product? The next two major versions are already fairly well planned out, we have new projects going on as part of the Google Summer of Code this year, which include things like memory model enhancements and new material and animation tools/helpers. We also plan to improve our support for threading, and introduce a DirectX10 plug-ins for those that wish to target the new features it provides. And generally, just to continue the steady growth we've enjoyed for the past six years!