I am having trouble designing a renderer for my engine. The problem is not how to do it, but the design issues of it. I am going to add in a material system in there eventually, but lets say I have those 3 types of geometry I want to render ( TriStrip,TriList,Mesh). I want to derive these types of geometry into different classes, so that each class can work on only that type of geometry. I also want to add types new of geometry, or how to render them easily without having to re-write the renderer code. So that is what I want. Now for what I need: The geometry needs to be sorted and batched. The problem: Should each derived geometry chunk have it's own render() function, or how should it be setup so that I can indeed batch these together. I was thinking each geometry chunk should have thier own, but others have said no. Of course it is up to me in the end, but I would like to know how you can do this without having to have all the rendering code re-written each time. Am I going too far with object orientation? perhaps I should hard code this into a renderer. So, this is what I see so far, with a render() in every geometry chunk that render() in the renderer calls class Renderer(an example in psuedocode-ish and missing a lot) { private: std::list<geometrychunk*> renderlist; public: bool AddToRender(geometrychunk*);//adds to the render list - everything that is to be drawn must be passed into this per frame bool Render();//After it renders, it clears the renderlist }; This has unequivocally been my bane in re-writing my engine in modular code. [Edited by - biohaz on October 3, 2006 4:40:49 PM]

Today's graphic cards are designed to render bunch of triangles, so you don't have to worry about multiple kinds of geometry chunks. In my engine I plan to use a simple structure for geometry chunks : I treat a geometry chunk as a bunch of vertex buffers, with a vertex format and an index buffer. It also contains the index to begin with, a primitive count and primitive type field, and of course a material field. Ultimately, you are going to send triangles to the card, so you don't need to bother with multiple kind of geometries.

But how you render a tristrip over a trilist is ultimatly different since one needs a IB and the other does not. Should all data be send a certian way to the renderer and deal with it that way?