Sign in to follow this  

Object Oriented Renderer Design

This topic is 4599 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

Hi all, I'm trying to decide the best way to organise my rendering code and I'm fairly sure this must be a common problem. Essentially it boils down to providing a render method for each type (triangle->render(), mesh->render(), etc) or to have an engine->render() function which iterates through the various elements of the scene and renders them. So, some pros and cons of seperate render functions... Pros: Seems 'object oriented' (bad criteria I know...) Flexible/generic. Easy to add new types? Encapulation. e.g. vertices may not need to be exposed if a triangle renders itself Cons: No overview of scene. e.g. Several triangles have the same texture but each loads it because it doesn't know the previous one have. Does it make things like shadows hard, as these would depend on interaction between geometry? Although a triangle could render itself, a mesh would not call render() on each of it's triangles because it would want to take advantage of strips/fans. So both triangle and mesh would have contain triangle rendering code. Is this wasted duplication? If this train of thought continues then whatever is above mesh might have mesh rendering code. Get to the top of the tree and you've just got one big function anyway... So what are your thoughts? I notice OGRE has a Renderable class but this appears to just hold properties rather than providing a rendering method. Thanks, David

Share this post


Link to post
Share on other sites
Im not sure about how you want to handle your render() method - I personally have a method within the renderer for renderPolygon(), renderNode() etc - but you dont want to be rendering each triangle - you want to batch as much as possible - this is where scene/renderGraphs are useful. In a modern octree/opTree you are probably going to be culling against a node containing objects rather than triangles - so a renderer::renderNode()/renderOnejct() (semantics) function is probably more useful - though if you really need to render the odd triangle/polygon then renderPolygon() would be useful...

Share this post


Link to post
Share on other sites
Personally, I prefer having a render queue to which renderable objects send data that the queue can handle. Keeping things as separated as possible is often a good thing, like having a renderer which is the only bit of code actually touching any render calls, opaque object types that are the only "entities" knowing what their data mean etc. Makes it easy to maintain and upgrade to new features without wreaking havoc in the project.

Share this post


Link to post
Share on other sites
Ok, well thanks for the thoughts guys. Overall I guess thats two votes for not providing each renderable object with it's own render method. But i'm going to give it some more thought/experimentation. Other issues (collision detction, physics, etc) are going to affect my design as well.

Share this post


Link to post
Share on other sites

This topic is 4599 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.

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