C++ Software Renderer

Introduction

My demo starts by running a scripted demonstration of the various features supported, culminating in a Martian disco! After the script runs, buttons are revealed to allow the demo to be used as a sandbox. 2d and 3d effects can be turned on/off by the user. The user can also choose to run the script again.

The demo features an animated Marvin the Martian, loaded from MD2 format. In addition to rendering the demo features both 3D effects (such as spike, pulse, dissolve and character animation) and 2D image post-processing filter effects (such as gamma correction, brightness, bloom and blur). The effects are implemented as loosely coupled objects which decorate either a game object or a rasterizer.

Update (12 March 2009) – I have now fixed a few problems with the renderer. Specifically:

• It now interpolates properly between animation keyframes.
• The orbit camera now works.

Download

Executable – CPPSoftwareRenderer.zip (1.37MB)
Readme – Readme.pdf (87KB)

Features of the Software Renderer
• Vector and Matrix classes – implemented as fully functional data types with overloaded operators, copy constructors and accessors. Support add, subtract, scalar divide and multiply, cross and dot products, transpose etc. Also provide static matrix generation methods e.g. identity matrix, rotations, translations, scaling.

• Camera – The camera is able to change position.

• Rendering pipeline – The rendering pipeline is comprised in MyApp::Render(). In order for effects to be applied in the correct sequence (some need to be applied post-transform, pre-render) the pipeline has three stages. Render() is called after movement effects have been applied (DoMovement()). It distinguishes between the various render modes in use (e.g. there is no need to light the model if we are only drawing wireframe or outputting a texture for debugging). The pipeline then splits into TransformObject() and DrawObject(). The former deals with normal and lighting calculations, transforms to camera space, culling and sorting polys (if appropriate). The 3D effects manager is then called before DrawObject(), which handles perspective and screen transforms and renders the model. After this the pipeline deals with 2D post-processing effects and filters, before flushing the pixel buffer to the GDI+ bitmap, drawing text and framerate, and drawing the bitmap to the window.

• Rasterizer – As mentioned above, my rasterizer makes use of a pixel buffer for drawing. It supports rendering in the following modes:
o Wireframe
o Flat shaded (GDI+)
o Flat shaded (manual)
o Gouraud shaded
o Textured
o Textured and lit
o Textured, lit and gouraud shaded
o Texture debug

In addition it supports a number of 2D filters, namely:
o Inverse (negative)
o Grayscale
o Colorisation
o Brightness adjustment
o Gamma adjustment
o Blur
o Line scan
o Bloom
o Jitter

I have combined a number of these filters in my demo to create effects (e.g. a ‘retro’ filter comprising greyscale, color (sepia tone) and jitter).

• Z–Buffering – The rasterizer supports Z buffering through the ZBuffer class, allowing per-pixel sorting.

• Polygon culling and sorting – Depending on draw mode, various methods are used, such as: polygon sorting with std::sort and a predicate function; backface culling; whole polygon culling outside view port; line culling in wireframe mode. Clipping is not supported.

• Lighting Support – Lights are implemented as a base class (Light) and three derived classes (LightAmbient, LightDirectional and LightPoint). These are tested and functional and the scene contains one, two and one of each, respectively. MyApp contains arrays of each type of light, making it simple to add and remove lights as required, although it might be nicer to have a light manager to handle this.

• 3D Effects – My renderer includes an extensible effects framework using the decorator pattern. It was initially meant to handle 3D effects on objects, but I found it very handy for creating effects to apply to the rasterizer and the camera.

The abstract base class, Effect, provides an interface for effects, which decorate an Object. Derived effects simply implement the Update() and Undo() methods in addition to any code of their own.

In practice I found it very easy to create new effects using this framework, even filter effects, for which I simply used a dummy object and passed in a rasterizer. With hindsight it might have been better to further abstract the base class and build on three derived classes – EffectObject, EffectRasterizer and EffectCamera, rather than having a redundant object pointer.

o Effect Manager – The effect manager comprises a linked list of Effect*. With polymorphism, effects of any type can be passed in, and the manager then Update()s these every frame, deleting them when they have finished. In this way, effects can be created and then forgotten about.

o Spin – Applies a rotation about a specified axis for a duration.

o Spike – Smoothly transforms verts outwards into spikes and back again over a time period using Object::Spike. Customizable offset and magnitude.

o Pulse – Smoothly transforms verts outwards and inwards in a sinusoidal pattern. Customizable frequency and amplitude.

o Rainbow – Modifies the reflectance co-efficients of an object over time in a randomly fluctuating pattern to give a rainbow effect.

o Dissolve – Uses a predicate std::sort to order polygons by average Y value, then over a duration culls them from top to bottom, giving a disintegration effect.

o Animation – Applies an animation to a model over a period. When object is loaded the key animation frames are stored in an array of the KeyFrame class. Object::LoadFrame() simply adjusts the Object::_vertices pointer to point to the relevant KeyFrame::_vertices array.

• 2D post processing effects
o Color filter
o Grayscale
o Gamma
o Brightness
o Bloom
o Blur
o Lines
o Jitter
o Inverse

The Scene

• Direct camera manipulation
• Several objects being transformed in different ways
• Light sources
• User options

Optimization and performance
I kept track of the optimisations I performed on a spreadsheet.

• Pixel buffer – The primary optimisation made, which resulted in a framerate increase of 56fps in textured mode, was doing all drawing to a pixel buffer and then flushing this to the GDI+ bitmap once per frame, intead of using Image::SetPixel(). A side effect of this was that it made post-processing much easier and faster, as this was done directly on the buffer.

• Float to int conversion – Profiling revealed the biggest bottleneck was float to int conversions using __ftol(). I replaced this with some third party code (referenced in my code – float_cast.h) which resulted in an improvement of about 5fps in some cases. Time was also saved in some of the image filters.