Past and present of the rendering engine

As I mentioned before, I have been working on a rendering engine for XNA called the Meteor Rendering Engine. I’ve only been working on it for a little over a month but already it’s come a long way. Even though it started out as simply a tutorial project from Catalin Zima-Zegreanu, I made enough modifications to it to call it my own.

Learning Deferred Rendering

When I started using XNA back in June, I just finished the 2D Shooter tutorial from the official XNA site, and wanted to do try something more exciting. Having experience with Direct3D before, I quickly moved on to doing 3D and begun work on a long-ignored idea for a marble rolling game. That was fun but it did get tiring just working on one project at a time, so I thought about how to make the graphics in my game better. I quickly plunged into the XNA blogging community and got to see who are the well known “VIPs” of the community.

To get right to the point, I found Catalin Zima’s blog and decided to tackle the deferred rendering tutorial. It was a nice challenge, as I had to grasp the then-advanced concept of deferred rendering together with updating the code so that it’s compatible with XNA 4.0. Previously I downloaded some Light Pre-Pass samples and they went way in over my head. But when I completed the tutorial, I understood it a lot better. Once you get deferred rendering, light Pre-Pass comes second nature easily.

A More Modular Rendering System

Then I decided, what else can I do that makes this really stand out? I worked on streamlining the code and cut out some parts I didn’t consider too useful. I realized that, having learned deferred rendering, you can break down the rendering process in discrete steps that just link from one to another without having to affect each other directly. The Meteor Engine was born. Each rendering step was confined to its own class. If, for instance, I wanted to use a GBuffer pass or lighting pass, I would just need to instantiate that class for it and each pass would take in the resulting product from the previous pass. In short, it let me break up the rendering process so that I’m not left with a super-huge DeferredRenderer class that does to much but provides little in terms of flexibility.

Current Status and Future

As of the time of this post, I have done more tweaks and refinements to the engine and have added several more features, so it’s not going to be easy to write about them all in one post. As far as ideas for improving current features and adding new ones, they include anti-aliasing support (more important for deferred rendering), a way to support more than just one rendering mode, optimized lighting effects, and any other usual features to have in a graphics engine like shadows and ambient occlusion. Next, I will probably talk about its features and its performance…


One thought on “Past and present of the rendering engine

  1. I usually do not comment, but I browsed a few of the comments on Past
    and present of the rendering engine | Electronic Meteor. I do
    have a few questions for you if it’s allright. Could it be only me or does it look like a few of the remarks come across like they are left by brain dead individuals? 😛 And, if you are posting on additional social sites, I’d like to keep up with anything new you have to post.
    Would you make a list of all of your public sites like your linkedin profile,
    Facebook page or twitter feed?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s