Sign in to follow this  
biohaz

[help] I am having renderer design issues

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this