[help] I am having renderer design issues
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement