Ok so im writing a general library of my own that will consist of things like classes that make quads and cubes etc. What i used to do is have the other classes that make up the engine, like the font (text writing class) and console to be able to ask the gen_qud class to make a quad. Then the Mesh or VB for the quad is retrieved from the quad class and used and rendered etc. Thats what i previously did and obviously its so slow, but a start. So what i want to do now is to have the quad class only provide the vertices for the quad and not make the mesh or VB. Then what i want to do is to have a render queue so that all the vertices created by calling the quad and cube classes are copied into one VB, then i an index through applying the textures etc. Now, im not sure how to do this. What i could do is have a linked list that would have an element for each quad or cube in the scene, and have a member of the linked list structure holding the vertices for that shape. Then go through the linked list each frame copying the vertices accross. Is Locking/Unlocking a VB say 10000 times a frame a bad idea? if not this means that i could render only 1 object at a time by copying that 1 object into the vb, then overwiriting with the next? any hints tips about this? ace

You're copying an object one at a time into the VB and rendering it?
You'd be much better off building a scene cache of the vertices (eg: build up a store of the vertices in the current viewable frame) and sending them into the VB once (or twice) per frame.

Continously locking/unlocking the vertex buffer will slow it down, as will the several small memory copies into the VB.

right so supposing the gen_quad function just setup an array of struct with the correct vertex data, copying that into the vertex buffer along with any other quads cubes and cylinders all in one go would be a fast way of doing it?

Yes. Remember, you're generally trying to avoid locking/unlocking the VB as much as you can. In my DX game I used to fill an array as I went along and then dump this to the VB for rendering at the end of the frame. You could gain more performance by using IndexBuffers too.

well once its filled what i want to do is be able to effectively render the each scene object with individual textures etc.

Consider batching your vertices together by texture.

Imagine this scenario:

[This is a VB containing the following]

--Model A-- == Model B == -- Model A -- == Model B == -- Model A --

You change the texture state 4 times here. A->B (one change), B->A (one change), etc...

If you batch your scene buffering up by texture, you can reduce the number of state changes in your rrendering.

-- Model A -- -- Model A -- -- Model A -- == Model B == == Model B ==

You've moved from 4 state changes to just one - which will boost performance a lot if you're rendering a lot of models.

Your rendering loop would look like this:

- Fill VB buffer with vertex data
- Begin
- Change to Texture A
- Render Model A x 3
- Change Texture to B
- Render Model B x 2
- End
- Present

cheers evo...

What I do is build a mini model vertex buffer when I load the model - this is sat in system memory and is essentially a 'compiled' version of the model. What I do before the level begins is create a VB and copy across the cached model vertices to a level VB buffer. My rendering then uses the main VB as it's vertex source (using DrawPrimitive with either the raw VB or an IB) - this way you get little or no lock/unlock calls per frame, which would slow things down a lot. This would probably need chaging if low-level vertex manipulation was required on animated models, but for static models it works a treat. Again, I limit the number of state changes per frame too, so I'd render all models of one texture first from this VB and so on.