oop and rendering

In my view, objects should render themselves. However, they don't do the actual rendering. Instead they pass the necessary information to the renderer so that it can do the rendering. The advantage is that the objects (and the rest of the code) don't have to know anything about low-level rendering details, and the renderer doesn't have to know anything about the objects it is rendering.

The drawback is that it creates and additional layer of abstraction/complexity. For a simple game, it is probably not worth the effort and the objects should do the rendering directly.

Another advantage of JohnBolton's method is that the rendering system can then sort by render states, cutting down on the costly state changes you mention.

The previously mentioned method is how I do it as well, for the same reasons.

something like this
youd have like a cMesh that contains all the vertwx info maybe a list of vertexs
every object has a cMesh member.
the object would have a function objrender that returns a pointer to the cMesh
rednder() would do something like
verts=obj.objrender
draw verts

In my paradigm: Each of my classes have a RenderToMem () function which actually overwrite data in the vertex buffer each frame (I lock the vertex buffer each frame and render to this mem area).

Then after all objects finish their drawing functions, I call pD3DDevice -> DrawIndexedPrimitive () once to render all objects to the screen.

Pros: You don't have to mess up with D3DXMatrix* () function family and easy to transform your objects into whatever shape you like. One lock, multiple renderings to memory and one call to flush them all to the screen, it's very fast!.
If you're using matrix transformations to move your objects around, each object must be drawed to the screen each time by itself ---> slow

Cons: Besides this easy approach, it has some disadvantages: if you want to apply some post-rendering effects, you come back to the traditional method: render each object which has effect applied one at a time.

Final: my approach should be used for 2D applications or 3D which needn't some special effects only, for real 3D apps, it show disadvantages more than its simplicity

why don t you put the renderer into a dll
and let the shaders choose a shaderclass/rendererclass whatever you want to call it

this way you can simply extend the engine later on and allow custom authors to extend the engine to their needs and you keep the rendering code seperated from the objects

i store all the geometry in a mesh class and for animated meshes i use a derived class to support sceletal animations and such

I prefer the approach whereby 'graphic representations' (hmm, "grep"s?) of game objects are held in a collection by the renderer, but game objects keep pointers to their own objects. So I create an NPC, attach a 3D model to him (either in the regular member pointer sense, or in the scene-graph sense), and let him set the model's position/orientation/animation as the AI dictates. The renderer has the object in it's array/list of 3D models at all time, so it doesn't need to touch game objects at all, it just pushes through its own lists and renders each object according to the stored parameters.

It allows sorting and the like, and is also pretty extensible (very easy to add new types of graphic representation or to add new parameters to an existing type). I'm not sure how close this is to JohnBolton's approach because I get the impression that his technique still sees each game object wielding a 'Render()' function, which I don't like so much; iterating through a list (or better, static array) of model classes/structures is a little more cache-friendly than traversing the heap to kick each object, and you don't lose any capabilities in the process.

To make it the killer app, use several of the suggestions above. First, JohnBolton's way is correct for abstracting the object and its mesh (or even primitives). Second, also superpig's way is good. This leads to the "multiple parallel scene graph" issue that is discussed more and more in the near history. As one can observe at VRML, the "one overall scene graph" becomes to complex. Hence several implementors have started to hold structures besides the scene graph. E.g. using the scene graph for FK and a BSP for rendering, and other dependency graphs for skeleton bones, and ...

well the concept of using a single scenegraph for everything rendering, updating ... is a misuse of scenegraphs

there s been a nice article somewhere on google that discussed this kind if abuse of scenegraphs which makes them quite useless in some situations

the author pointed out the trend from scenegraphs in the past where they where used for transformation hierarchies

to nowadays where they are used for everything just to get the scene organized


and points out the future where people will use several scenegraphs specialized for special puposes to make maximum use out of them