I am pretty sure I know what a renderer is and how to use it, you pass a list to objects to it and it handles all the directx rendering code, can sort based upon shader/texture/alpha ect... But how do you set one up? I thought to send in a vector or list of objects like:

struct 
{
   position
   vertex buffer
   index buffer
   shader file
   texture
   color
   ...
};

But then, say if the vertex data is diffrent, such as the terrain may use indexed, a mesh may use tri-strip and the gui may be tri-list so adding a enum of what type would have to be added. Then with more and more of there problems arising, the structure to pass top render would be unweildy. Plus on top of that, I have yet to delve into mesh and mesh hierarchies, so I doubt this would be a optimized/fast/good way for those. What is a good way to approch making one? So far I have avoided it, but now to complete another piece of the puzzle, I need a unified renderer and cannot render in thier own functions. [Edited by - Valor Knight on April 28, 2006 5:20:36 PM]

@Knight:

You named it right : a puzzle, some call it programming ;)
I believe there are a thousand ways to build a good render
engine. Furthermore the question is: what do you want to render ?
Every contruct has its more or less optimal render mechanism,
for that the try to build a unified render method for all
events seems impossible, if you dont wanna exceed performance...
For example, if you look at instancing shaders, they work quite
different than standard shaders and are far away from e.g.
fixed function pipeline.
Cause of that its a good way to (may be programmatically) decide
prior the way of the needed (best) render mechanism, before you impose
the full load to one render method at the end.
In my engine i have about 5 specialized render methods:
1. for instancing shader.
2. for no instancing shaders.
3. for animated items.
4. for GUI
5. fixed function (for some things, i havent switched to shader yet)

Cause of the (in some ways) different kind of parameters the different
render methods needs, you have to decide sometimes prior or later in the render pipeline, what the best way is.
E.g. if you want to display a monster, you have to measure if it is the
best way to use the shader for instancing or not.
You don´t know the result in prior, cause of the complexity of the
mesh, of the amount of monsters, the hardware support for your engine
and so on.

You called it right: a puzzle.

Greetings *Los Brutalos*
(Sorry for my brutal english)

A good start would be to organize your data and functions using Object Oriented Programming (OOP). You are correct that you will need to be able to maintain and render different types of 3D geometry, like sprites, meshes, particles, lines, etc. Having a separate class for each type would enable you to avoid a ton of exception code (with enums all over the place) to determine what needs to be done to store the data, change it, and render it.

This is the kind of programming task that requires you to do a lot of designing before you even start coding. That way you can avoid the pitfalls that have plagued programmers before OOP.

I use a different approach. I have an abstract class IDrawable that has a pure virtual function draw(). Every drawable object implements the IDrawable interface, so basically every object knows how to draw itself. Then, I have a scene graph that contains a bunch of IDrawable objects, so the renderer just walks through the scene graph and polymorphically calls draw() on each one.

It works for me, because I can add new features to my graphics engine without breaking the design. If you don't like scene graphs, you can insert IDrawable objects into a vector and achieve the same effect. I recommend taking a look at the Boost library <http://www.boost.org> which has Pointer Container that I found incredibly useful.