The Meteor Engine is a graphics engine that started out from my first attempts at deferred rending. This gradually became the focus of the blog, along with any games that I might or may not use with the engine. It is a lightweight engine that focuses on making rendering steps and processes modular. The idea is to make it easier to break down complex rendering methods into discrete steps. Every rendering pass and post-process effects are treated as separate modules (in different classes), and these passes can be re-arranged for flexibility. I’m also building on pre-existing content pipelines to support import of content suitable for use in the engine.
Some of the features present in the Meteor Engine are support for instancing, blended cascaded shadow mapping, basic skinned animation, and some post-process effects like depth-of-field and FXAA. It also features a flat structure for organizing objects in a scene (no scene graphs here), manual depth sorting, and basic (brute-force) culling. Quad tree culling will be added soon.
The goal is to make the engine usable as a standalone library, or allow developers to extend the existing rendering modules to enhance them, or just write their own. All scenes and meshes are rendered uniformly with these passes, but eventually I hope to add a custom material system that can be configured individually for each object. Another priority is to keep garbage creation to a minimum. I have been profiling the code closely to make sure I find and stop garbage-related bugs before they get out of hand.
You can find periodic builds of the engine on the CodePlex site. I do not upload every single commit, but just the ones that I consider to be a milestone or otherwise a noteworthy change to a feature. To support skinned animation, it requires a library created with the Skinned Animation sample to compile properly, unless you choose to omit this feature in the source code.
I plan to keep the engine’s purpose exclusively for rendering and organizing graphical assets for now. This way I can minimize feature creep and avoid making it overly general purpose and bloated. The only other big features I might attempt to do are a more robust graphical debugger and a straightforward, immediate-mode GUI that could be suitable for some types of games. Any future tools that would aid in my game development, such as a level editor, would not be considered part of the engine proper, but more as standalone projects that uses the engine for rendering.
I also realized that I should make a game with the engine to properly “battle test” it, instead of being just a showpiece for graphics. I’ve seen and followed the development of other hobby engines, displaying scenes to show it off and sometimes sharing the code with others. But most of these engines do not show any actual games that use it in their websites. The game, currently an untitled off-road racing game, will be developed alongside the engine and there are still many problems for me to solve as I work on it.
As my progress unfolds, the engine’s codebase will undoubtedly see many changes, so I do not have a release candidate as of now. The source code is available to use at your own risk, because what may work now might not work later.