Sign in to follow this  

Is This A Good Approach?

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

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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