Graphics Engine Renderer

I am most certainly not the best person to answer it, but this is how I plan to set mine up:

The renderer will have poointers to all the various structures dealing with rendering. these include the scene graph, render tree, camera, etc. Basically, the user can update the scene graph, and the renderer always has a pointer to the data. The render tree is an item that circlesoft has mentioned that seemed like a great idea. Basically it splits the renderable objects into a heirarchy of render states (shader, textures, matrices), so each state can be apply and popped at each depth level.

My renderer will probably also deal with all the initialization of the window and graphics API (OpenGL for this one).

So basically, here is what happens during the render routine:

Traverse Octree and mark any non-visible geometry.
Add all the visible nodes in the scene graph to the render tree.
Traverse the render tree and render nodes.
Render all 2D geometry.

You aren't talking about writing an API, are you? If you are purely interested in a rendering engine, try Ogre (Object-Oriented Graphics Rendering Engine).

There are a thousand ways of doing it and all has it's pros and cons. I do it like this:

1) The renderer just renderes stuff, no surprise there:). It's merely a handy wrapper around the graphics API eg. DirectX, OpenGL etc. It have metods to set up matrices, shaders, states, geometry etc.

2) I have a scene manager where all the real work is done. I holds the scene graph and spatial strctures. It performs culling and sends the visible objects to a render queue (also hold by the scene manager). The queue is then sorted by shader, texture, states etc. Then the scene manager loops the queue and calls the renderer to render each object, ie. calls the methods briefly outlined in 1.

The main advantage is that the renderer is totaly separated from the rest of the engine and supporting new API's is just a matter of subclassing the renderer and it's supporting classes.

This is pretty much how it's done in Ogre by the way.

Of course 'what' a renderer is specifically is dependant on the engine and the implementor interpretation, so here's my interpretation:

Quote:

1) The renderer only renders the scene, nothing else, correct? Data is sent frame by frame to the renderer, and the renderer can sort based upon texture, distance, materials, shaders used, ect.. Depending on the input, it could render to a texture, or to the screen itself.

Yes, the renderer takes renderable input and renders to a render-target which could be the screen (a window), a texture or a file.

Quote:

2) Should the renderer keep the data in it, or have it passed every frame? I would think keeping the data in it would be faster, but passing it in, the renderer would only need to know how to draw stuff.

Usually the data will change frame by frame so the data would need to be sent to the renderer each frame. However a complex renderer might wish to retain the previous frames data to optimise the sorting process for the current frame or for special effects.
Typically though the actual data itself is stored elsewhere and only pointers to the data are ever passed around as copying data is far too slow.

Quote:

3) If the data is sent in, it would be structs that contain vertex/index buffers, material, textures, and shaders. Thus for every object rendered, a struct would be pushed onto a list and sorted out.

Well as I mentioned before you would be passing structs that contain pointers to the buffers and materials that describe the object to avoid copying.

Quote:

4) Space partitioning, I have thought objects are clipped based on their location in the quad/octtree, using aabb’s and spheres. But I have read a few things that show static objects get broken down to polygon size in the partitioning and the polygons, not objects are partitioned that way, is this correct? I would assume movable/dynamic objects would not be broken down into the node due to the possibility of it moving.

Yes often the worlds static geometry is partitioned at the polygon level. Dynamic objects arent split at the polygon level because obviously they could move and the whole process would be painfully slow.

Quote:

5) Where should space partitioning take place? In the scene graph, where we figure out where everything is located?

In my system I have a separate spatial tree for my static geometry, its a separate construct to the scene-graph but there is a scene-graph node that reperesents the whole tree as a renderable item so that all the static geometry is sent to the renderer when the scene-graph is traveresed for rendering.
View frustum culling (where objects are clipped based on their whether bounding volume, AABB/sphere, is in-view) is done in my scene-graph though, if they are rejected then they arent sent to the renderer.


At the heart of my renderer I have an API abstraction layer which separates out the graphics API (OpenGL/Direct3D). Each frame renderable objects issue data to the renderer about how they are to be renderered (pointers to buffers, shaders, transparency, etc), these are then sorted in the render-queue to batch up state-changes. The renderer then sets the states (shaders and what-not) and sends the geometry off to the GPU to be rendered.

Hope that was some help