You could have a base class called Renderable instead of Object. Since Object can be really almost anything as well. Renderable would have the basic functionality of anything tht can be seen on the screen ie:

virtual Render();
virtual SetWorldPos();
virtual GetMaterialAndEffects();
virtual GetBounding[whatever]();
...
...
etc...

But also keep in mind that the Render function shouldn't actually render anything. Rendering on a per object basis is considered bad practice. So the Render function should actually pass it's vertices and indices along to a RenderManager of the sort. The RenderManager then sorts the renderable objects (based on certain criteria obtained via the GetMaterialAndEffects function), and then batches whatever it can out to the gfx pipeline.

It sounds really nice and managable on paper, but it gets very complex when you go and implement the above. But anyway, that's one way to do stuff...

What they mean is that you don't want to render objects as unrelated render calls. It may be tempting to have a class of Renderables that contain all the needed vertices and textures etc and then just call Renderable->Render() to draw them to the screen. But this will always come with uneeded overhead and will quickly sink performance as you increase in scene complexity. Consider what code my look like with that design.



It is likely that Car1 and Car2 will use the same vertices and textures yet because of this design, materials and textures will be set more times than they are really needed.

Now consider an alternative



When adding to the RenderList, it can group objects that share identical textures and/or vertex data. That way, it eliminates unneeded state changing calls.

Quote:Original post by andyb716
Can anybody please help me deciding what to do, because
I'm going in different directions each day.

Engine design (and graphics engine design, especially), can be complex and confusing enough to make your head spin. Lay your thoughts out on paper, but don't over-engineer or over-analyzing. That's when you start going around in circles. Simply put, the best way to learn what works and what doesn't (in the long run), it to implement it and find out.

With that said, make sure you account for a flexible material system. A material contains anything that has to do with how the object looks (ie the shader, textures, constants, renderstates, ect...). You can also extend the material properties to include physics and sounds, if you so desire.

When rendering, the objects should be batched by their material. First, sort by the shader, then the textures, and finally any constants. This will minimize calls to any of the costly functions listed here.

Here is a great thread on the whole material concept.

[note: some of this is just a copy and paste from what I posted over in the Engineering forum]

Sometimes batching by object isn't enough. A game object could potentially have multiple objects it needs to render (think about a person, a gun, other attachments, etc.). Those other objects might be duplicated many times in the world also. I happen to think that it is best to approach the rendering of a 3D engine at a low level. Think about rendering triangles, not objects (even a mesh is just a collection of triangles).

This is an approach to the problem that I learned from the book "3d Game Engine Programming". The game objects (like a Sprite, or a Mesh), simply pass all the vertices they need to rendered to a VertexManager. So, the objects don't actually do any rendering themselves. They still perhaps implement the common Render() function, but the Render() function simply passes the vertices that need to be rendered to the VertexManager.

This method makes it a lot easier to "batch" and organize your drawing calls if possible. Trying to batch and organize the drawing calls (like organizing the drawing of vertices by texture) becomes a lot more painful if all the rendering is done by each object. This is because there is no "watch dog" to actually do the organizing (especially if one object will use multiple textures (as is usually the case)).

Personally, I do it by having a VertexManager that is accesible through the renderer. Something similar to:



Your VertexManager would then have Render() methods that basically add the vertices to a VertexCache that caches the vertices and doesn't draw them right away. This allows the VertexManager to prioritize and organize the vertices any way in which you choose and the game objects don't even have to know that anything is happenning. For all the game objects know, the VertexManager is drawing the vertices right away (which it isn't).

So, a boiled-down and simple VertexManager might look like the following (very boiled-down mind you):



Please note, there are many opinions on this topic. I think the important thing is to build your engine in such a way that it will be easy for you to change. That's one of the reasons I like the approach specified here.

Not only does it allow you to easily change the drawing algorithm (if you decide to change how to order your drawing calls), it also allows you to more easily abstract the engine away from the rendering-specific technology. For instance, in the above example, all DirectX specific classes (i.e. D3DVertexManager, D3DRenderDevice, etc.) would be in a library included at run-time. The game would use the abstract engine classes and would hook them in at compile time. This allows you to easily plug in in OpenGL renderer instead of a Direct3D renderer (or vice versa). So, changing renderers can even be done at run-time and doesn't require a single change to any of your game objects.

Remember, abstraction and architecture are your friends :).

I hope that helps at least a little bit. The best of luck to you :). (And don't forget to enjoy yourself :D). Happy Coding!