Jump to content
  • Advertisement
Sign in to follow this  
Shock

VB, IB and Batching

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

Hello all! I have a few questions about using VB's and IB's. Iv'e been reading some docs and nvidia's developer site. They said you should minimize calls to DrawPrimtive() and should rather have your geometry indexed using an IB. Also they said you should 'batch' your primtives. By batching I'm guessing they mean group them into sets which have the same render states/textures/etc...? The problem is how do you implement such a system! Do I create a vertex buffer for each group that has common render states and then load up all geometry into that vertex buffer? What about index buffers, one for each render state as above? Or a dynamic one that changes every game-state update? Basically, how does one 'manage' geometry objects using this stuff? Thanks

Share this post


Link to post
Share on other sites
Advertisement
That's pretty much the way it is...

However, do remember that IBs are connected with VBs.
In a sense that if you aren't doing some trick, one IB is meant for a certain VB, you don't switch around between different IBs and VBs.

Batching generalized? One common way of doing is to allow pushing of triangles or stacks of triangles, which are then categorized by texture->renderstates and so on and put into the right VB and if used, update the IB appropriatly. (that's one way)

(IBs are really useful for sprites as you render quads all the time and therefore send only 4 instead of 6 vertices)

Don't forget to use static VBs for static objects, they are much much faster unless you really have dynamic geometry.

EDIT: btw, it's said that between 1k-4k tris per VB is preferred, however, I cannot back this up personally but it sounds credible.

Share this post


Link to post
Share on other sites
Thank you for the reply Syranide.

I just wanted to know :

1. Is it possible to load geometry in a VB multiple times but to different sections?

The following is just an example, a static VB with static geometry:

Create a vertex buffer, size is 6
Lock at offset 0, size 3
Copy data for one triangle
Unlock
Lock at offset 3, size 3
Copy data for one triangle
Unlock

DrawPrimitive with offset 0, 1 triangle, triangle-list
DrawPrimitive with offset 3, 1 triangle, triangle-list

( I tried the above, doesn't work for me, hence me asking )

2. If you utilise IB's and VB's with your aim being to reduce the amount of DrawPrimtive calls, wouldn't it still be the same using IB's but instead using DrawIndexedPrimtive?

3. The only solution I could think of to #2 was a single Dynamic IB, but as you said one IB for one VB. But wouldn't it take to long to copy the scene geometry index data every game-state update? [disturbed]

Sorry, but I just want to make sure I know everything clearly before I code this system.

Thanks [attention]

Share this post


Link to post
Share on other sites
Quote:
Original post by Shock
Thank you for the reply Syranide.

I just wanted to know :

1. Is it possible to load geometry in a VB multiple times but to different sections?

2. If you utilise IB's and VB's with your aim being to reduce the amount of DrawPrimtive calls, wouldn't it still be the same using IB's but instead using DrawIndexedPrimtive?

3. The only solution I could think of to #2 was a single Dynamic IB, but as you said one IB for one VB. But wouldn't it take to long to copy the scene geometry index data every game-state update? [disturbed]

Sorry, but I just want to make sure I know everything clearly before I code this system.

Thanks [attention]


For 1, since we are talking about IBs, you could just use two seperate index buffers. One index buffer for one set, and a different buffer for the other.

As far as two, switching Index Buffers is not as bad as switching Vertex Buffers (I believe, it makes sense). Index buffers have a much smaller memory footprint, and using them with Vertex Buffers usually means you can lower the amount of memory for the Vertex Buffer two. For example, if you make a tile grid out of a triangle list you have to use on average 6 vertices per intersection. Assuming you are using textures, that is 5 floats per vertex (20 bytes) and 30 floats per intersection 120 bytes. If you used an Index Buffer, you only need 1 vertex and 6 indexes. 1 vertex is still 20 bytes, but each index can just be a 2 byte short. That means your indexs total to 12 bytes, and with your vertex 32 bytes! You can send a fourth of the information to the card, which can make a gigantic difference when you want to render a grid of 999 by 999 tiles:

With just vertex buffers 120 bytes per intersection. 1000*1000 intersections = 1,000,000 intersections. Total memory required: 120 MB

With Vertex Buffers and Index Buffers: 32 Bytes per intersection. Total: 32 MB.

Its obvious which has the advantage. For more improvement you could use triangle strips instead of lists and cut a lot more of that memory out. Smaller size equals a quicker transfer to card.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!