   Vertex and Index buffers of the gods....
  right heres the deal...ive got a structure called:sVertexthis structure has the following elements// code beginstruct sVertex{   float x,y,z;// positions   float nx,ny,nz;  // normals   float u,v;  // UV Co-ords};// code endive got like a 50x50 array full of those babys.... its like a little terrain program thingy....BUT anyway... heres one problem... there is a function that fills the array and makes a flat terrain... but then when i want to go put it into the vertex buffer i realise DAMN! they are not in the order they need to be to get rendered.... so i thought HEY! i will use an index buffer to put them in order then i can dynamically change the values of the original 50x50 array... Anyway... this is the main question here...lol i know your all loveing this rant so i shall continue...when making a vertexbuffer i would use:(this is the minimaliztic version of code)// Code BeginCreateVertexBuffer(sizeof(sVertex)*Terrain_Size, 0, VERTEXFVF, D3DPOOL_MANAGED, &Terrain_VB, NULL);// Code Endthen once thats made i want to use an indexbuffer but heres the thing... MSDNs kinda vauge... so anyway heres an example:// Code BeginCreateIndexBuffer(<this part here>, D3DUSAGE_WRITEONLY, D3DFMT_INDEX16, D3DPOOL_DEFAULT, &Terrain_IB, NULL);// Code Endas you can see if i used <this part here> in the actual code i think Visual C would pack up and leave me...BUT anyway back to the question at hand.... where i specify the length of the index buffer... should it be "sizeof(sVertex)*Terrain_Size" so that it has the same size as the vertex buffer or should it be "sizeof(BYTE)*Terrain_Size" because then it acts like a pointer to the vertex buffer when its locked and unlocked etc...As you can tell by now i aint used index buffers before... im thinking that the 1st usage is the correct way, which makes it the same size as the vertex buffer... BUT this would make 2 copies of the data taking up MASSES of memory with larger terrains....So basically if you have skipped all the crap above my main question is:Should the indexbuffer usage be of the type of data the VB holds (sVertex) in this case or should the index buffer be a load of pointers such as (BYTE)... OR is there an alternative method that would get same results... not being 1000 miles different to my current method...Well thats the end of my rant... i hope you all like it..lol
  Remember, index buffers only contain words or dwords as their data, depending on 16 bit or 32 bit, so the amount of memory say 100 words would take up is much less memory than 100 vertex structures used in a vertex buffer.  To access the data in the index buffer, you would provide the Lock function a WORD or DWORD variable's address.  All that WORD or DWORD contains is the index of the vertex structure in the vertex buffer that will be used.  I believe it's 0 based.Also remember that index buffers are a way to reduce the number of vertices stored in the vertex buffer, so more than often the vertex buffer should actually contain less "points of data" than the index buffer.  They really aren't comparable though.For instance, for a simple quad, 4 vertex structures are stored in the vertex buffer and, depending on how you draw the primitives(let's assume triangle list right now because it's probably what you will use), you'll have 6 points in the index buffer.  The index buffer will use 2 of the vertices in the vertex buffer twice.  So, for a single quad, you'll need 6*sizeof(WORD or DWORD) as the number of bytes in the index buffer creation function.  If you have n quads, n*6*sizeof(WORD or DWORD).  If you have n triangles, n*3*sizeof(WORD or DWORD).Hope this makes sense,Chris   [edited by - Supernat02 on February 3, 2004 12:25:30 AM];  LOL thats music to my ears.... i thought they used WORD/DWORDS as it would make sense... as the IB is basically just a list of numbers pointing to the VBs contents... This will be a great help as it will DRASTICALLY lower the amount of data flowing around...lolthanks chris... now i can get back on with it....yay! lol ;  I think you''re a little confused about how index buffers work.  But that''s ok, they''re not the easiest things in the world to pick up the first time you use them.The size of your index buffer will depend on the way your app will refer to the data in your vertex buffer.  For example, say you have a quad.  It''s made up of four vertices:vertex[0] = (-1,-1, 0)vertex[1] = (-1, 1, 0)vertex[2] = ( 1, 1, 0)vertex[3] = ( 1,-1, 0)D3D allows you three ways to render this quad: triangle list, triangle strip, and triangle fan.  In all three cases, your vertex buffer will stay the same, however, your index buffers will all be different.  These are all described in the SDK docs.If using triangle list:[0,1,2,0,2,3]If using triangle strip:[0,1,3,2]If using triangle fan:[0,1,2,3]For terrain, there are some optimizations you can make to increase performance.  But since this is the first time you''re dealing with index buffers, your best bet is to stick with triangle lists.  They''re easy conceptually and modern graphics hardware is made to optimize for triangle lists more than for the other two.The size of the index buffer is basically the number of elements in the index buffer multiplied by the size of each element.  An index buffer element is just a number that tells us where we need to look in the vertex buffer to get a particular vertex.  The size of each element of the index buffer is specified by the Fromat parameter in the call to CreateIndexBuffer.  Each element can be either 16 or 32 bits.If you use 16bit index buffers, then each element of your index buffer is a WORD.  If you use 32bit index buffers, then each element is a DWORD.So say you''re going to draw your terrain as an triangle list.  Each triangle in the terrain must be specified by 3 indices from the index buffer.  Your terrain is a 50x50 grid.  So that would be a total of (50-1)*(50-1)*2 = 4802 triangles.  Each triangle is made of 3 vertices.  So the size of the index buffer would be 4802*3*sizeof(DWORD).  I suggest you use D3DFMT_INDEX32 for the format in case the size of your terrain starts to grow a lot.  That way you don''t have to come back and change your code.Hope this helps,neneboricua ;  yeah thanks...well ive already made a crappy method of making the terrain and rendering it without index buffers and yeah i was using trianglestrips... thats the whole reason why i thought..oh while im re-doing this i may as well try Indexbuffers so i can set the order of the triangles in there... becasue the whole idea was that i could make a terrain, and dynamically alter it during runtime...The plan was to have the Array[X][X] and then if i wanted to change lets say [22][13] or the ones surrounding the player then i could do it quite easily through the raw terrain data... then if i had an index buffer i could go nuts changing the data in the VertexBuffer (Y axis movement atm), and the Index buffer would never need to change as the order never changes..the values do though..but anyway.. yeah what you said does clear it up a bit more... i was planning on using the DWORDS with the 32bit thingy as you said so i can expand more later...anyway i shall sit and cry while DirectX laughs at me for chosing to do this in D3D instead of OpenGL... LOLthanks again ;  Just be careful, 32-bit indices are not supported on older cards, and you only need them if you use more than 65534 vertices in the index buffer.