Jump to content
  • Advertisement
Sign in to follow this  
biohaz

[help] I am having renderer design issues

This topic is 4403 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!