Crystal Space or Ogre 3D
Which Engine Should I Choose For My New Game Development Project?
While many people who talk about Crystal Space (CS) and Ogre 3D (Ogre) have a firm opinion on this question, it's sometimes difficult to find relevant and objective facts. When you are looking to make the right choice for your game, you've got to sort through lies, semi-truths, and lots of irrelevancies before you find a solid basis to evaluate the engine.
What I've done is I've investigated the capabilities and suitability of these two engines for a starting development team, from the perspective of a relative novice project lead (i.e. me) with a small team (just myself at the time of this writing in March 2007) and a small budget ($0.00 if possible!). Also, I don't want to spend months/years in the learning of an engine's capabilities only to decide that it wasn't really suitable in the first place. What's needed is an apples-to-apples comparison.
In my comparison, however, I take a somewhat unique approach. While most comparisons take the position of comparing the pixel/polygon drawing speeds, advanced rendering techniques, etc., I figure that either one of these engines is going to be plenty good enough for my basic-to-intermediate level project. So instead, I have focused on the included features, and the "learning curve" aspects of each engine. In other words, my assessments purposely emphasize support and documentation (which I feel are of paramount importance to the budding development team), along with overall engine features, while I'll gloss over the technical details.
Please note that in this document I did not do any extensive evaluation of any of the other possible engines out there, including Irrlicht, Open Scene Graph (OSG), Torque, and many others which may be suitable for your project. This is by no means a complete comparison of 3D graphics engines. You have been warned. :)
Some Facts
Over the last few months (as of March 2007), I've frequented the respective online communities for both CS and Ogre. I've compiled a short list of facts which have been gleaned from my manual readings, source code perusals, tutorials, example application builds, IRC discussions, forum postings, engine reviews, and more. The most glaringly obvious Truth is that these two engines are vastly different in the features that they offer. However, my comparison did not stop there.
I submit the following Truths about CS and Ogre (please correct me if I'm wrong about any of this!):
- Both CS and Ogre are C++ programming libraries. Wrappers exist which allow access to their functions from selected other languages.
- Both CS and Ogre are free to use in developing commercial applications, under the LGPL license.
- Both CS and Ogre have active development teams working to improve the engine's functionality, and have each released significant version updates in the last few months (as of March 2007), and are already at work on future revisions.
- Both CS and Ogre support OpenGL rendering. Ogre also supports Direct3D, while CS does not. CS instead allows for native software rendering if your runtime environment does not support the OpenGL standards.
- Both CS and Ogre run under Windows, Linux, and Mac OSX.
- Ogre is a 3D Rendering Engine, meaning it will draw your scene for you. It also provides a basic application framework (very limited) into which you will need to manually integrate other libraries for needed functionality such as keyboard/mouse input, sound, GUI, physics, artificial intelligence, networking, etc. Since most people will need many or all of these things in their game programs, there are some tutorials and examples of how to include external packages into your application. But it's all done outside of Ogre, explicitly.
- Crystal Space is more properly categorized as a 3D Application Engine. It includes a 3D Rendering Engine, but it also includes additional functionality in the form of Plugins and External Libraries (collectively known as Modules), such as input, sound, and much more. These Modules can make it easier to implement concepts quickly (see discussion below for caveats). Modules can be used or not used, as needed. CS hopes to provide everything you need (except your specific application code of course) under the single umbrella of the CS Engine.
- CS also provides a module called the Crystal Entity Layer (CEL), which adds a framework of game design objects to the base CS engine. With the addition of CEL, CS becomes a complete 3D Game Engine.
Evaluation Criteria
I've put in my assessments and a subjective score from 1 to 10 for each criterion that may (or may not) be important to your team. If a particular criterion is not important, please adjust your rating accordingly, or even remove it from consideration altogether. Bear in mind, this is totally subjective and only my own opinions. Also, please note (as mentioned above) that my evaluation focuses more on support issues and high-level features, and less on heavily technical features and performance. It's intended as a guide to help new development teams get started making a game.
| Criteria | Ogre | Crystal Space |
| Quality and Quantity of other development projects based on each engine | 9/10 - Ogre's Featured Projects page is very impressive, showing dozens of active projects that look quite professional and "serious". | 5/10 - Unfortunately, the CS Featured Projects page leaves something to be desired. Many of the (relatively few) titles listed are incomplete, abandoned, and/or not very relevant. While there are a few bright spots, it's clear that there aren't nearly as many notable projects going on under CS. This is despite the fact that CS has been around for 5 years longer than Ogre. |
| online Forums (Message Boards), and Mailing Lists | 9/10 - Forum is very active (hundreds of messages per day), very helpful, even with novices. This is the preferred method of support for Ogre. | 5/10 - Forum has relatively little participation, and they tend to ignore questions that are not "well-defined". A few Mailing Lists are also available, but there's still not much going on there which will help a starting development team, since there are only a few messages each day on average. Instead, the devs tend to hang out in the IRC channel. |
| IRC (chat room) helpfulness | 6/10 - (irc.freenode.net #ogre3d) - Questions are sometimes answered by the community residing in the Ogre IRC channel, but unfortunately, the Ogre devs don't usually hang out there any more, preferring to spend their support time answering questions posted to their Forum. | 9/10 - (irc.freenode.net #crystalspace) - Great community, great answers most of the time, main CS developers active daily. A primary strength of the CS team's support efforts. |
| Documentation: engine manual, API, online wiki and website content | 8/10 - Thorough, searchable and generally helpful, but also includes lots of out of date stuff that needs correcting or removal. | 4/10 - Documentation is good in some parts, but missing several important sections, and needs lots of updating work overall. Also, it is not searchable currently (March 2007) - this is a huge problem for those of us getting started! Also, there's relatively little developer content on the website/wiki. |
| tutorials & examples | 7/10 - Many useful beginner and intermediate tutorials, including snippets and explanations, although many are out of date and do not correspond to the current documentation. | 5/10 - A few good ones, but not many of them, and they tend to be larger and more complex (i.e. more difficult for the novice to understand). There may be more tutorials which I haven't yet found. |
| ease of use / "Learning Curve" | 8/10 - Relatively simple engine, due to the team's focus on 3D rendering instead of non-graphics-related functionality. There's also lots of help from the documentation and forum to get you going. | 5/10 - Can be very difficult to find your way at first, due to incomplete or out-of-date (or just plain confusing) documentation. A bright spot is the IRC channel, which can help quite a bit when you really get stuck. Still, it's a huge engine, with a lot to know, and a lot can go wrong. Hopefully this gets easier as you go? |
| engine development team | 8/10 - A mid-sized, heirarchical dev team working on multiple future revisions, remarkably organized and determined for an open source project. They are a bit more methodical in their release and testing approach, but not in a bad way. | 7/10 - A small (3 main programmers) grass roots type dev team that is extremely active and responsive, and also very talented, but not always sure of direction or goals. They behave very much like a typical small open source project, focusing on innovation, but with some tendency for "feature bloat" and the lack of a real formalized or automated testing scheme (that I'm aware of). |
| engine stability and release schedule | 9/10 - Engine seems very stable, releases planned well in advance and well tested. | 7/10 - The engine seems mostly stable, due to very fast fixes by the team whenever there are problems, but release planning and testing are somewhat less formalized and more casual. CS could really benefit if they had a larger user base, but as it stands there are some parts of the engine code that go unused and untested. |
| 3D graphics rendering performance | ??/10 - It seems pretty fast to me, but I'm not testing it very hard (evaluating basic performance only). | ??/10 - It seems pretty fast to me, but I'm not testing it very hard (evaluating basic performance only). |
| additional "built-in" engine functionality (i.e. not just rendering) | 2/10 - Very little is provided besides the 3D rendering engine (this is done by design). You must use third-party libraries for other functionality such as sound, input, scripting, etc. This may be preferable for development teams who prefer to keep more control of their implementation. | 8/10 - CS has many things built right into the engine, including a virtual file system, sound, keyboard / mouse / joystick input, console, scripting, map loader, a game objects library (CEL), etc., however some of these extra items may be broken, or poorly implemented, and will need to be replaced in your application code. **Please review below for caveats regarding this "extra" functionality. |
Additional Discussion Regarding CS's "Extra" Functionality
CS has a significant amount of "extra" functionality from various plugins and modules (i.e. the stuff that's not related directly to graphics rendering) already integrated with the main rendering engine. This functionality - which includes things like sound, user input, the CEL game entity layer, Python or XML scripting, physics, and much more - can be a huge time savings over the life of a long-term development project. However, even if CS does implement a relevant solution to a particular programming challenge, the built-in implementation may not be done the way you'd normally do it in your application.
A great example is client/server networking (if you need this in your game). CS's solution is based on HawkNL's network library, and the CS development team agrees that their implementation is lacking. Knowing this, you may prefer to use something like RakNet, or any of a number of other 3rd party solutions instead of the built-in solution provided by the CS engine. Just be aware of spending a lot of time integrating the CS built-in solution with your code.
Under Ogre, of course, this is not an issue, since you always implement solutions yourself. Thus you'll always know what's implemented, how it was done, and why.
The Bottom Line
Both Ogre and CS can be very useful in developing a 3D game, but they are quite different from one another, and each approach has its advantages and pitfalls.
- Crystal Space - CS is a much larger scope engine, requiring your game's development team to be a bit more "advanced" in their understanding of game implementation concepts in order to best use the engine's many built-in features. It will take much longer to command the use of the CS engine, and longer still if you're going to include CEL. It won't be easy, but if your team can outlast the learning curve, you may reap the benefits of all that the CS/CEL team has written, which is quite a lot. Then again, not everything in the CS engine will be appropriate for your application, so you'll need to weigh those items accordingly.
- Ogre 3D - Preferable if you prefer Total Control over how your game engine features are implemented. The Ogre engine is relatively simple (as compared with the hulking CS), and has a large and very helpful development community, and a plethora of searchable documentation. There are many third-party solutions available which can be integrated with Ogre. Here's a link to some of the third-party libraries that can be used with Ogre (some of them even have pre-built implementations you can use).
- Other solutions - Please keep in mind that this document does not compare anything except for Crystal Space and Ogre3D. At the time this document was written I felt that these were two of the best Open Source engines available (and perhaps they still are!). If you're willing to spend a bit of cash you have many many more options of course. Without doing exhaustive analysis and explanation I might recommend a dev team with a small bit of funding (you can get the engine for under $150) to take a look at Torque, which provides a lot more than just 3D rendering functionality.
Further Reading
For those of you who are interested in reading more about some of the trials and tribulations of a budding game development project trying to work through these complicated choices, and deal with the things that come up at each new turn, please review the history blog for my own project, Arcanoria. It can be found on this very website, on our History Page. It may prove to be an entertaining read. ;)
Comment From A Reader
The following comments are from one of our readers:
I've read your article "Crystal Space or Ogre 3D", and I do think that although Ogre is only a rendering engine, it has a few stuff that goes beyond rendering that might be useful info for readers who are also deciding on which engine to use.
Ogre supports loading of files from zip archives out-of-the-box. Crystal Space also has this feature. However, Crystal Space has filesystem abstraction, while (I think) Ogre doesn't.
Like Crystal Space, Ogre also has a means for skeletal animation. Ogre implements its own skeletal animation system, while Crystal Space uses Cal3d as a plug-in.
Both engines use 3rd party plug-ins for physics support. Both of them have plug-ins for ODE and Bullet.
Moreover, regarding rendering:
Both engines support shaders. Ogre supports HLSL, GLSL, and Cg, while Crystal Space supports Cg only.
Both engines have their own mesh file format. Ogre meshes can be exported from Milkshape3D, 3D Studio Max, Maya, Blender and Wings3D, while Crystal Space meshes can be exported from Blender and 3d Studio Max.
Both engines can render heightmap based terrains.
As of yet, portalized scenegraphs (ability to render indoor and outdoor scenes concurrently) is an experimental plug-in in Ogre ( http://www.ogre3d.org/wiki/index.php/Portal_Connected_Zone_Scene_Manager), while Crystal Space already has this (http://www.crystalspace3d.org/docs/online/manual-1.0/cs_4.9.4.php#4.9.4 ).
Thanks for Reading!
I hope this web page has been useful in your search to find the right graphics library for your development team. Please let me know how this page could be improved, or just to say hello. Thanks for reading!