I have been reading and reading and reading about the best way to render my terrains and objects. I think I have a solution and wanted to ask if this is a proper or preferred way of doing it. Basically I will have a base class, IRenderable for example, that all renderable items will inherit from. This will allow me to create a render function for everything that I deem able to render. The render function won't actually draw anything, but instead add the geometry for the given object/terrain to another Renderer class. The renderer class will iterate through all the geometry, and do the actual rendering by sorting on lighting, material, textures and then filling up vertex/index buffers, and then drawprimitive will be called on all the buffers. Does this seem like a proper way to do it?

Filling buffers is slow; I think if possible you should create buffers of data as seldom as possible, create once use many times :). It all depends on the volatility of the data though.

Edit: and/or how much memory you have available

So my IRenderable class should have a create function which adds the geometry on load to a vertex buffer, and creates the appropriate index buffers. The renderer's render will just draw those buffers?

I'll not try and detail a solution, because i'll probably get caught out as I have yet to fully implement it :p

But in general there is going to be a lot of static vertex and instance data; if you can get them into buffers early on and keep them there and then use offsets to pick out the data you need, would seem like an efficient approach to me.

There actually appears to be a couple of ways to do this effectively. Either use the offset value when you set the buffer or the start location values in the draw call.

My knowledge of DirectX is not complete though and i should also point out it is very Dx10 centric.

Edit: As for the indices; i think you could use BaseVertexLocation of the Draw call to keep you indices zeroed in on the correct vertex data.

Something I have been glad i looked into was a parameterised object tracking class. Its just a template class that has a few statics for holding unique instances of the parameter Type and keeping count of the GUID.
Then inherited from this for a resource holder that will ensure mesh and texture data is only loaded once (note a controller class parameter was add here with static load functions.
Now I have render object holder from this tracking class which could possibly hold data regarding any offsets within fixed buffers.
Now maybe these in turn will be held by a Game piece class taken from the same parameterised object tracking class. This takes care of tracking for everything :) (also incase anyone notices, yes i know the GUIDs are not GUIDs, probably something like GTUID (typed) :p )

Sorry i kind of started rambling there :s any way templates are cool and might help you with this, they seem to work well in my experience. Check out the C++ articiles here on gamedev about templates, there is resource holder example as well.

You may have thought of this anyway :) or indeed it maybe a crap solution.

[Edited by - Guthur on December 2, 2008 10:39:40 AM]

I think you went over my head with that one. My implementation will be fairly simple and be built upon from there. I am just trying to understand the best appropriate as far as rendering geometry because I do no want to have to create a vertex buffer for each item I plan to draw if its not the way to do it. But perhaps that is the way to do it?

Ya templates sound scary but they aren't as bad as they appear or people make out. I avoided them for ages but it was mistake they can be such an elegant solution to some problems. If you get the time definitely look at some of the tutorials here on game dev, that and a semi decent book should be enough to grasp it. It will be worth it :)



Disclaimer: I'm saying the basics are within grasp not some template magic out of Modern C++ Design by Andrei Alexandrescu, really want to get that book actually :p