Sign in to follow this  

Dynamic VB question

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

Hya there I've got a simple question on dynamic VB's. If you have one dynamic VB which can hold a max of 2000 vertices then with triangle lists that works out at around 666 triangles / polys. So if I have two triangle / poly arrays and the first one holds 300 polys / triangles and the second holds 400 then which of the two methods below should I employ? (Each array has a different texture) Method 1 Add the first array to the dynamic VB Add part of the second array to the dynamic VB. Render and discard. Add remainder of second array to the dynamic VB. Render and discard. //this method makes better use of the vertex buffer but results in 3 passes. Method 2 Add first array to the dynamic VB. Render and discard Add second array to dynamic VB. Render and discard. //this method doesn't make good use of the vertex buffer but it only uses 2 passes. Thanks for your time Matt

Share this post


Link to post
Share on other sites
I'd suggest learning how index buffers work.

Typically if you have a 2000 vertex mesh, you'd render 4000-6000 faces, as many vertices are used in several faces. You're getting 666 faces out of 2000 vertices. So, in practice you'd get ~10x as many polygons for the same amount AGP data transfer. Not a bad investment of your time, is it?

I'd use method 2, but I'd make the dynamic VB a bit larger. I'd make the VB enough to hold 2-3 large objects, which might also mean hundreds of small objects. Even in the worst case, I'm still using NOOVERWRITE more than DISCARD, and percentage of wasted to used space becomes better. This is simpler to design around, and when using indices, you can't guarantee that you'll be able to split the mesh in the middle like method 1 requires.

Share this post


Link to post
Share on other sites
Thanks for your reply 'namethatnobodyelsetook'

For my currently put aside outdoor engine I was using vertex buffers and index buffers but I couldn't work out how batching my index buffers would work. Should I offset them when I set the indices like so:

pd3ddevice->SetIndices (MyIndexBuffer, 5);

(I can't remember how many params set indices takes).

Then I would just use setindices every pass with a different offset.

Currently I'm working on an indoor engine which doesn't really allow me to use index buffers because of different texture co-ordinates and that I don't have to average the normals which makes lighitng look a bit better. Do you think I should use index buffers here instead? How would I do that with different texture coords?

Thanks again.

Matt

Share this post


Link to post
Share on other sites
Hi again 'namethatnobodyelsetook'

I was just searching the forum for index buffers and found that you said:

<quote> Even in a cube, using indices you can use 4 vertices per face rather than 6, so you need some really basic meshes to make indices useless. </quote>

Of course. I never thought of that. I can do that atleast.

Thanks for the help. I'll go and see if I can't implement this stuff.

Thanks agan

Matt

Share this post


Link to post
Share on other sites
The extra parameter to SetIndices controls which part of the VB the IB refers to (note, this extra parameter is gone in DX9, and has been moved to the DrawIndexedPrimitive call). This is useful to pack multiple meshes into one VB, without having to renumber your indices to take into account other meshes come first.

I'm not sure why you'd offset the indices for additional passes. If it's because each of your passes requires different UV coords, and you prefer not to put more than one set of UVs in the vertex, you could look at using Streams. This allows you to put the position and normal in one stream, and put the UVs in as many seperate parallel vertex buffers as you'd like.

(normal geometry case)
vb0 = pos,norm,uv0,uv1
SetTextureCoordIndex 0, Draw, SetTextureCoordIndex 1, Draw

(streams geometry case)
vb0 = pos, norm
vb1 = uv0
vb2 = uv0
Draw pass 1 using (vb0, vb1), Draw pass 2 using (vb0, vb2).

I'm not sure why you'd need the changing UVs though, as most cases of UV generation can be done via a shader, or in the fixed pipe with D3DTSS_TCI_CAMERASPACENORMAL, or D3DTSS_TCI_CAMERASPACEPOSITION, and a texture transform matrix.


As for using index buffers, it's very rare to find a case when not using indices is better. Most vertices share normals, and UVs, except along texture seams, or sharp corners. Even something simple like a cube benefits, despite the large amount of "vertex duplication" it needs.

A basic cube needs 6 vertices, which may be indexed
A textured or lit cube needs 24 vertices if indexed (4 * 6 faces)
A textured or lit cube needs 36 vertices if non-indexed (6 * 6 faces), or 24 vertices if drawn as 6 2-triangle strips which would be horrible performance wise.

Without knowing your exact geometry, or why you need extra UVs, or why your geometry should change, using different indices between passes, nobody here can say for certain what the best method is. I'd be really surprised though, if indexing can't work for you... and I'd probably redesign whatever portion of your art pipeline is causing the problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by Namethatnobodyelsetook
The extra parameter to SetIndices controls which part of the VB the IB refers to (note, this extra parameter is gone in DX9, and has been moved to the DrawIndexedPrimitive call). This is useful to pack multiple meshes into one VB, without having to renumber your indices to take into account other meshes come first.


This is true for Lock/Copy VB1/Unlock/Draw, Lock/Copy VB2/Unlock/Draw, and so on for each vertex list. If you are trying to do batch reduction by Lock/Copy VB1/Copy VB2/.../Copy VBn/Unlock/Draw, then the index list has to be recopied and renumbered to reflect its vertex's new position in the VB. This can get pretty expensive for lots of dynamic meshes.

joe
image space

Share this post


Link to post
Share on other sites

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