Designing a Renderer

Ok, a quick explanation would be, a fixed function pipeline has a bunch of fixed functions (wow really?! :-p) that you can configure and then the vert data is pushed through those functions. With a programmable pipeline instead of just pushing it through the fixed hardware functions, you can set programs (shaders) that the verts will be pushed through (i.e.: the program will run on each vert) this is for vertex shaders. Further down the pipeline the pixel/fragment shader will run on all the fragments that were generated for the given frame, again instead of just going through the standard texturing hardware functions, a program is run on each fragment (a pixel/fragment shader).

If you looking to learn Shader programming I'd recommend "The Cg Tutorial", tho this doesn't explain how to architect a renderer or engine to encapsulate the programmable pipeline. Infact it doesn't even deal with the Cg run-time thats left as an exercise for the reader.

With regard to your post about designing a renderer, the way you say is basically how most renderers work, i.e.: they have a list of stuff to draw and they run through it and draw it. You have to supply a renderer with everything its going to need to draw the given primitive, i.e.: vert data, textures, shaders, whatever. Of course there are ways to make the renderer more efficient, for instance, grouping those primitives that make use of the same shader program or materials, so your not constantly binding and unbinding the same shaders to the video card, same goes for material properties, although i wouldn't worry about material sorting until you've got something up and running.

NeHe stuff is all fixed function yes, unless he explicitly mentions using Shader programs which I believe he does around lesson 45 IIRC? As for books, check out:

(the afore mentioned) The Cg Tutorial - Randima Fernando & Mark J. Kilgard
ShaderX - Wolfgang Engel
3D Engine Architecture - David H. Elberly

The first 2 will give you a decent grounding in shader programming, and the last gives you an idea of what it takes to architect a well structured and extendible multi-API renderer.

Once you get a renderer up and running, your probrably going to want to look into some scene management to cut down what your actually sending to the renderer for drawing (no point attempting to draw things you can't see right?) so you'll want to check out scenegraphs, frustum culling, occlusion culling, oct-trees, BSP (althought typically not used much for rendering more for collisions these days), all that stuff.

Hope this helps ;-)

Ill try to add my knowlege.

As this is the renderer, it should only render, right?
So all transformations and stuff are already calculated?
If not, you need a parent object to transform the matrix before you draw the child objct (if you got any)...

The next thing is sorting. Objects with the same texture / shader should be drawed in order to reduce texture / shader switching... (might not be an issue if not to heavy graphics).

Who is responsible for deciding if an object is visible? If its behind the camera, the renderer could do this, but if its for example inside a box, or to far away, you should not try to render it (and rely on that the distance cap removes them).

What i heard people do it that the renderer infact is only a smart queue!
When your logic decides that an object should be rendered, it passes the object to a rendering queue, witch you can flush at the end of the frame.

This is great because then your renderer is independant of your scenegraph structure, and objects can be sorted when they are added to the queue.
If you need z sorting (witch is good when doing pixel shaders (draw closest first) or if you want transparency) you can easely modify the order of your rendering whitout affecting any other part of the system. You could also have flags like: IS_SHADOW(draw me last) or IS_EFFECT(draw me even later)

The drawback is that you cant use matrix push and pop directly with this approach (that is if you have "child" objects), so you need to calculate the transformation of the object, and then add the saved transformation matrix with the object to the renderqueue. This might give some overhead if thousands of objects...

So now you have a encapsulated renderer with the simple interface:

-enqueue(object,flag)
-flush()

totaly separated from your logics and scenegraph...
it takes care of order and optimalisation by itselfe, and this is hidden from the rest of the system.

-long post

-anders

Its quite common for the algorithm requesting objects to be rendered to be able to trivialy iterate through geometry with common materials .. such as iterating through all the grass blades in the scene.

It would be wasteful to change the problem to something less trivial under the banner of being 'generic'


Some geometry will be part of a "set" .. in such cases, its the SET which should have a render method in order to take advantage of the priori knowledge of common materials.

Other geometry will NOT be part of a "set" in the sense of common materials even though they may be part of a set. For instance, the set of all agents in the world. Each has a dynamic model. It is ONLY these sets here that really should have the whole queue-it-up-and-sort-by-material strategy.

So I believe that the overall design of the rendering system should be capable of both queing up render requests AS WELL AS exposing API specific features that allow the caller to directly leverage batching on its own in those cases where its obvious that a generic queue system is sub-optimal.