Creating an engine with multiple renderer support?

Are you familiar with the "Visitor" design pattern? Well one way of achieving API independence is to use something similar to that. Suppose you have a scene graph representing your world. In your world you have different geometric types like Character, Room and so on.
Each of those types derive from a common subclass which declares a function something along these lines (assuming C++)

class Object
{
...
virtual void Render(Renderer& renderer) = 0;
...
}
  

Your renderer then has methods for rendering each kind of geometric types, it acts like the visitor.

class Renderer
{
...

virtual void RenderGeometry(House* house) = 0;
virtual void RenderGeometry(Room* room) = 0;
...
}


Then when you render through your tree you use an overload Render function in each geometry node to do this:

void House::Render(Renderer &renderer)
{
   renderer.RenderGeometry(this);
}
  

this makes sure that the correct render function in the renderer class is called. Then you simply inherit the renderers you want:

class OpenGLRenderer : public Renderer
{
void RenderGeometry(House* house);
...
}
  

The only place you decide which API to use is when you create your renderer which can be handled by a factory or something.

This is just one way to do it - but it is fairly simple and easy to use (once you get the grasp of it). It's more or less the method David Eberly uses in "3D Game Engine Design".

Codito, ergo sum - Graphics Programming

[edited by - thoooms on January 30, 2003 4:50:59 AM]