OGRE is a multiplatform 3D engine with a focus on strong design, cleanimplementation, extensibility, and maintainability. It adheres toobject-oriented principles and clean coding standards, whileproviding a blisteringly fast 3D renderer with support for all thelatest hardware features of DirectX 9 and OpenGL, including support for all low- and high-level shader languages, multiple shadow techniques (including custom shader-based techniques), and HDR.
Description of project:
An efficient, object-oriented hardware accelerated 3D engine. It abstracts the differences between APIs and platforms and allows scene-oriented coding through an easy to use object model. Adaptable to multiple scene types (indoor, outdoor, whatever)
- Development Status: 5 – Production/Stable
- Intended Audience: Developers
- License: GNU Library or Lesser General Public License (LGPL)
- Operating System: All 32-bit MS Windows (95/98/NT/2000/XP), OS Portable (Source code to work with many OS platforms), Linux, OS X
- Programming Language: C++, Python
- Topic: 3D Rendering
- Translations: English
- User Interface: Cocoa (MacOS X), Win32 (MS Windows), X Window System (X11), Project is a 3D engine
Why and how did you get started?
Steve: I started OGRE in 2001 because I was unhappy with the software that was available; I felt that other engines were too inflexible, were more often than not tied to a single scene type, a single rendering API, one type of game, one content pipeline, etc. I wanted an engine that was more adaptable. I was confident it could be designed and written cleanly so that it could evolve over time, rather than having to undergo major rewrites when new technology came along. I wanted to be able to render scenes that were structured differently just by adding a plug-in — I hated being tied to a single format by an engine.
I also wanted to write a graphics engine component that was friendly toexternal integration. I didn’t like that most graphics engines tied youinto a suite of other functions too — a kind of ‘all or nothing’ option. I wanted to be able, for a given project, to pick the best renderer, the best physics engine, the best sound library, etc., for that project. By combining the most appropriate elements for a given project you have far more control and spend less time working around or pulling out things that aren’t appropriate for your project. These goals required a focus on a clean, well-documented API that was integration-friendly.
Thomas: I’ve long had the itch to actually implement some of my game designs, so this naturally led to a search for a usable game engine. I hit upon many of the open source engines, such as nel and crystal space, but always ran into problems with the design. I was using C++ more andmore for work and was learning a lot about what a usable API and designwould actually do. I finally came across OGRE and it seemed to fillmost of what I was looking for, but it was still young on the Linux (myplatform of choice at the time) and OpenGL front. So I hopped aboardand got Linux and OpenGL working as a fully supported platform andrenderer.
James: The project had already been going a couple of years before I gotinvolved. I discovered it when I was searching for a 3D graphics enginefor a game I was writing. I started out by helping people on the forums, sending bug fixes for issues I found and patches for new features that I was interested implementing. After a few months I was invited to become a core team member (probably due to continuallysending Steve and Thomas patches for them to apply to CVS). I stillhaven’t finished that game, more than two years later.
What is the software’s intended audience?
Developers needing a top-class 3D rendering engine for whatever projectthey have in mind. Many people use it for games, but that’s only one ofits uses.
How many people do you believe are using your software?
We now have more than 3,000 registered users on the forums and it seems to keep growing. It’s only a week after the release of 1.0.0 and we’ve already had more than 5,000 downloads of the source release or SDK, and there are plenty of people who get it directly from CVS too.
What are a couple of notable examples of how people are using yoursoftware?
Supremacy: Four Paths to Power, a finalist in this years Independent Games Festival, used OGRE (from quite a few versions ago now, which shows it has actually been stable for a while). Scootarama, a light-hearted racing game, took theBest Indie Game Award at the Australian Game Developers Conference acouple of months back. There are lots of other examples on our Web siteand in the forums, both commercial and open source, and there are someI’m not allowed to talk about yet.
What gave you an indication that your project was becoming successful?
Steve: When I had to start checking the forums three times a day just to keep up with all the messages. When several commercial companies started banking on OGRE for important projects that they’re pouring serious money into. When people started to approach me about articles or contract work using OGRE instead of me having to bang on people’s doors.
Thomas: Once people started getting full-time jobs and contracts just doing contract work, it was definitely something special. Once I got full-time contract work with OGRE, it was very real.
What has been your biggest surprise?
The amazing community. I’ve been in many open source communities, and there always seems to be a fair amount of drama or bickering. The OGRE community is by-and-large free of that. It’s very refreshing.
What has been your biggest challenge?
Thomas: The constant flux of the 3D card industry. New cards never stop coming out, and they aren’t cheap! Plus every new driver release is a mix of problems and solutions to old problems.
James: Trying to balance part-time work on OGRE with my family life.
Why do you think your project has been so well-received?
Steve: OGRE gives developers a lot of power and a lot of flexibility in an easy-to-use, solid package. People have commented many times that they felt that when they came to look for a feature, it ended up being exactly where they expected and ‘felt right.’ We tried hard to make the design as intuitive as possible. We’re also sticklers for detail; everything is documented and we always try to consider new features properly rather than perform quick hacks to get the fastest result. We control our versions carefully, always maintaining a stable version (with bug fixes and no interface-breaking changes) as well as a development branch. I think developers with experience appreciate thisprofessionalism, and the solidity of the engine gives people confidenceto build upon it.
Thomas: From the beginning it was acknowledged that we want to allow commercial usage. Coupling this with a focus on just graphics rather than a complete game engine has allowed OGRE to be a perfect fit into many people solutions.
James: I believe the project has been well-received due to the clean design of our API and the high quality of the community that has grown up around us.
Where do you see your project going?
We already have a roadmap planned for OGRE 1.1. Since 1.0 was amajor milestone and we packed a lot into it, 1.1 won’t be as feature-packed. OGRE will continue evolving.
What’s on your project wish list?
I really want to see more tools and complete tool chains worked out.I’d also like to see some more advanced demos. And I want areal Cocoa platform that can easily be used as an NSView in Cocoa apps.
What are you most proud of?
Steve: Our consistency and persistence. We stay true to the original vision and continually deliver quality updates, something that’s not as easy as it sounds but does make a difference in terms of perceived stability of a project. That and the fact that we demoed parallax mapping before the Unreal3 demo.
Thomas: Mac OS X support. It’s my most recent achievement and just continues to show how diverse OGRE can be.
James: I am most proud of the AMD64 port, as porting to a different platform was something that I’d never done before. I feel I handled it particularly well.
If you could change something about the project, what would it be?
Sometimes I feel there could be more structure to how we handlebugs and the community, but it would probably just stifle the freedomthat we have right now.
How do you coordinate the project?
We coordinate through IRC, forums, and email, normally in that order. We use the bug tracker and patch tracker a fair deal. Generally each of the core developers has their own section of the project that they are responsible for. Features that fall outside of this are assigned by the project lead, unless a particular developer wants to handle a specific feature.
Do you work on the project full-time, or do you have another job?
Steve: I have a separate day job, designing large object-oriented systems, unsurprisingly.
Thomas: I do contract programming, primarily on a project that uses OGRE.
James: I have a full-time job as a Perl developer for a company in Houston.
If you work on the project part-time, how much time would you say you spend, per week, on it?
Steve: I typically spend between 15 and 20 hours a week, more in crunch periods.
Thomas: I try to put in at least 10 hours through the work week and 5 hours over the weekend.
James: It varies from week to week depending on our project goals. On average I’d say I spend approximately 20 hours a week.
What is your development environment like?
Steve: I personally mainly use MSVC7 because I love the debugger, although I also use Gentoo. We have core developers on all three platforms we support.
Thomas: I run all three of our target platforms. First, my desktop machine running Fedora Core 2 and Windows XP, but it usually stays in Windows XP for my contract work. In Linux I use the normal auto* and gcc tool setup. In Windows XP I use Visual Studio 2003. Most of my time is spent on my PowerBook G4 Titanium running Xcode.
James: My primary development machine is an AMD64 3200+ running Debian. All of my development is done using vim as my editor, g++ as my compiler, and Enlightenment as my window manager.
How can others contribute?
We actively encourage patches from the community. Use our ‘Submit aPatch’ link on the main Web site. Because of the importance of designconsistency and code quality, joining the core team requires a developerto have submitted several high-quality, significant patches, andto have worked well with others in IRC and the forums. Joining the coreteam is by invitation only.