Jump to content
  • Advertisement
Sign in to follow this  
Ainokea

Object render itself or not?

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

Say I have a class for models. What are the pros and cons of having it render itself or a generic render class that renders any object you tell it to? If I where to use a default generic how would I program it? I have no conept of how it would look.

Share this post


Link to post
Share on other sites
Advertisement
For my first game i made every object render itself and i must say it was very easy to do and manage.

The problem arises when u have different types of objects and you need to write functions for every one of them, atleast that was how i was doing it.
However the main problem is that each object has no idea of the current state(Lighting enabled?/hardware capabilities/etc..) or where and how the other objects are going to be rendered. For example, if you were to do back to front rendering for objects with blending, your objects wouldnt know which objects were infront or behind it.

So the solution is to have one class which knows about everything there is to be rendered. Kind of like having all the required information/data and then this class decides the best way to render the objects. So for example if a user did not have VBOs, your renderer would fall back to display lists/vertex arrays. It could sort the rendering order of objects and render them in a more efficient manner.

Also, if you wanted to port your game to a console/diff gfx api, you would only need to rewrite the Renderer class.

However, i must say building such a renderer and ensuring that all graphic api calls remain in it is not as easy as it seems. And it would be overkill for a small project unless ofcourse you wish to reuse the code in future projects.

Share this post


Link to post
Share on other sites
What would the renderer class look like?
Would it be something like this:

class CRenderer
{
int numLights;
int numTextures;
//etc. etc....

public:
void RenderBox(int x, int y, std::string Texture);
void LoadHeightmap(int x, int y);
//blah blah blah....
};


or am I completely off?

Share this post


Link to post
Share on other sites
In general, it could include anything it wants/needs. But basically its main purpose would be to render a list of objects. Therefore you would need to come up with a Mesh/Object/Renderable/whatever class which will be a standard for rendering anything.

SO you have something like this:

void Renderer::drawScene()
{
for all objects
draw(object);
}

void Renderer::draw(Mesh m)
{
all your drawing code here.
}

You will need to come up with a class which contains all information/data about any mesh. The texture it uses/ vertices/uv/normals and anything else a renderer should know before it can render the mesh. This way you just need to hold a list of meshes and render them every frame.

The idea is that all your drawing code will be contained in the draw function. Any optimisations you make to it, will automatically affect all Objects to be drawn.

Remember there are a million ways to do it, and you should'nt be afraid to try your own method. In short there is no right way, but the main purpose of having a Render class is to consolidate all rendering related stuff into 1 class.

Share this post


Link to post
Share on other sites
Ainokea,

The way I approach it with my engine is that every game object knows *how* to render itself but doesn't necessarily actually do the rendering. The renderer has generic Render() methods that are passed a series of triangles (along with the necessary information like the vertex format and such). Then the game object's Render() function basically just dispatches its calls to the Renderer's Render() function, passing an array of the triangles that need to be rendered.

The advantage to this approach is that the Renderer doesn't need to know anything about your game objects (which makes it a lot easier to abstract the renderer into your game engine). And the game objects don't need to know how the game engine actually renders triangles. This works because if you break it down far enough, all a renderer needs to draw at the basic level are points, lines, or triangles.

Now, under the hood there is some cacheing taking place. Along with passing in the list of triangles, each game object also passes in a "skin" that the triangles need to be rendered with ("skin" = texture(s) and material(s) that are used in the Renderer's render states). When the Render() method of the Renderer is called, no rendering actually takes place. The triangles are "cached" into a vertex cache. There are multiple vertex caches in the Renderer (anywhere from 10 - 50+). These vertex caches sort the triangles passed in to the Render() function by the skin that they are to be rendered with. The vertex caches are rendered either when: 1) a cache needs to be "flushed" (rendered and reset) to make room for another cache or 2) the EndScene() method is called (in which all present vertex caches are flushed).

I hope this makes a little sense. If not, feel free to ask any questions :).

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!