   DrawIndexedPrimitive not rendering correctly
  Hi all,In optimizing my engine, I''m switching from a setup that used DrawPrimitive to one that uses DrawIndexedPrimitive.To quickly give you an idea how my "mesh" class works, it does this (in the DrawPrimitive form)1. Select the vertex buffer of this mesh as the stream source2. Set the shader for the next group of primitives3. Draw primitive4. Repeat steps 2 and 3 until all primitives in the mesh are renderedWorked fine, but retransforming all the vertices goes a little slow.So, I made myself a routine that generates an index buffer for all the vertices, and doesn''t add duplicate vertices to the vertex buffer.Now, the rendering code is:1. Select the vertex buffer of this mesh as the stream source2. Select the index buffer as the indices source3. Set the shader for the next group of primitives4. Draw primitive5. Repeat steps 3 and 4 until all primitives in the mesh are rendered* * *So, my first tests on it worked great-- HUGE speed increase.  BUT (there''s always a but), thought it works great for meshes that have only one material (and thus goes through steps 2&3 only once), it''s a disaster with multi-material meshes.When I comment out the D3DDevice->SetMaterial statement, everything renders fine-- albeit, in one material.  If I have that SetMaterial statement in there, only the first group of primitives will render.  The rest just won''t.Another note: If I set up my vertex buffer to go ahead and put in duplicate vertices, then everything renders fine if I fall back to DrawPrimitive.  However, an attempt to use DrawIndexedPrimitive still fails, even though the index buffer is a straight 1:1 match to the vertex buffer.Does anyone have any suggests as to what I might try?  I''ve done dozens of different code permutations... the only thing that works is to remove all SetMaterial calls.  Anything else leaves me with only the first primitive group in my mesh.Thanks in advance! 
  Read my second reply here:http://www.gamedev.net/community/forums/topic.asp?topic_id=171896I explain which parameters do what in a DrawIndexedPrimitive call.  Chances are you''re not telling D3D which parts of the mesh to draw correctly.;  I read it... but I''d already been through dozens of help files and online tutorials.  I know what the index numbers are for.Let me stress again: As long as I don''t do a SetMaterial between DrawIndexedPrimitive calls, it works fine.  As soon as I do a SetMaterial, such as:D3DMATERIAL8 aMat;aMat.Diffuse.r=1;aMat.Diffuse.g=0;aMat.Diffuse.b=0;aMat.Diffuse.a=1;D3DDevice->SetMaterial(&aMat);...Then only the calls before the material gets set render anything.  So, if I did...SetMaterialDrawIndexedPrimitive...DrawIndexedPrimitive...SetMaterialDrawIndexedPrimitiveThe first two DrawIndexedPrimitives up there will be fine, and the third won''t render.  If I remove that second SetMaterial, then the third one renders fine.(And yeah, I''ve been through a lot of iterations to make sure I''m actually setting a material that IS visible... I am). ;  Well, first the obvious things to ask...When running with the debug runtime and debug level cranked up, do you see anything in the debugger''s output pane that would indicate a problem?Does this problem occur when running with the Reference Rasterizer?This is really reaching, but if you set the material values to the same in your second call, does the problem still occur?  This might help you narrow down the problem to something being set wrong in the material struct.If you really get stuck, you can try to debug your code using ProcessVertices.  Look at the resulting color values of the processed vertices in the destination VB and see if they are what you''d expect.;  Im really starting to not like DrawIndexedPrimitiveSomeone else has posted as well as I about this function rendering incorrectly or not at all without any complaints. For instance on my machine I can write a demo that draws an entirely flat 257*257 vertex terrain using one index buffer for 256 vertex buffers tiled across the map. In the demo it draws correctly but in my game the same thing does not render anything. With d3d debug info all the way up it doesnt complain at all, and it works with the reference driver. This points to both driver issues and my code because it does work in one demo but not another. But the one it doesnt work in it works using the reference driver. Ohh and both methods of my rendering work on other video cards, just to add to the confusion.In otherwords Goodlife... good luck, I havent found a fix yet but you can at least get portions of yours to show up. I hope an answer is to be found just around the corner.   // Full Sail Student with a passion for games// This post in no way indicates my being awake when writing it ;  >When running with the debug runtime and debug level cranked>up, do you see anything in the debugger''s output pane that >would indicate a problem?Not a whisper.  Everything peachy keen, and according to all output, everything rendered just fine.>Does this problem occur when running with the Reference >Rasterizer?This I haven''t tried...I''ll give it a go, however.  Not optimistic, but I''m down to the brass nails here.>This is really reaching, but if you set the material values to>the same in your second call, does the problem still occur?>This might help you narrow down the problem to something >being set wrong in the material struct.No, that''s not it. I wish!  I''ve actually done dozens of different things here, including writing a WHOLE OTHER mesh class to take out any complexity.  I even turned off optimization on the off-chance that my compiler was doing something a little too enthusiastic with code op.>If you really get stuck, you can try to debug your code using>ProcessVertices. Look at the resulting color values of the >processed vertices in the destination VB and see if they are >what you''d expect.I''m really stuck... but I think I''ll wait until I''m really, really stuck to try this.  My fear is that I''m doing something very INTEGRAL wrong with how I set up my draw pipeline, and I''m totally broken.  The fact that this renders jus'' fine when I don''t set any shaders really creeps me out.>Im really starting to not like DrawIndexedPrimitiveYou and me both, buddy.  At first, this looked like my dream function... I was having some framerate problems on a slower test machine, and the use of DrawIndexed fixed them all-- as long as I don''t switch materials, of course.Though my situation is better than yours... at least mine screws up on all the machines I try it on, so it''s gotta be something I''ve done boneheaded... I just don''t know what!  And it could be something as simple as I didn''t set D3D_USEUNBROKENDRAWPRIMITIVE somewhere.;  To those that might help...I''mm attaching here the code I use to generate my index buffers from discrete vertices.  Essentially, it''s a class that you just dump vertices in.  It looks and sees if they''re already in, and matches up indices accordingly.If you have the time, would you please look it over and see if you see any glaring errors?  (NOTE: I do check the return values of the D3DCalls... they all return okay.  I''ve omitted the check code from here in order to make this as small as possible).class IndexedVertexList{public:IndexedVertexList(int aMaxCount){mVertexList=new Vertex[aMaxCount];mIndexList=new WORD[aMaxCount];mVertexCount=0;mIndexCount=0;}~IndexedVertexList(){delete [] mVertexList;mVertexList=NULL;delete [] mIndexList;mIndexList=NULL;}voidAddVertex(Vertex *theVertex){int aFoundSpot=-1;for (int aCount=0;aCount{  if (theVertex->mX==mVertexList[aCount].mX &&theVertex->mY==mVertexList[aCount].mY &&theVertex->mZ==mVertexList[aCount].mZ &&theVertex->mNormalX==mVertexList[aCount].mNormalX &&theVertex->mNormalY==mVertexList[aCount].mNormalY &&theVertex->mNormalZ==mVertexList[aCount].mNormalZ &&theVertex->mTextureU==mVertexList[aCount].mTextureU &&theVertex->mTextureV==mVertexList[aCount].mTextureV )    {aFoundSpot=aCount;break;    }  }if (aFoundSpot==-1){//// Add the vertex in, because it''s new//mVertexList[mVertexCount].mX=theVertex->mX;mVertexList[mVertexCount].mY=theVertex->mY;mVertexList[mVertexCount].mZ=theVertex->mZ;mVertexList[mVertexCount].mNormalX=theVertex->mNormalX;mVertexList[mVertexCount].mNormalY=theVertex->mNormalY;mVertexList[mVertexCount].mNormalZ=theVertex->mNormalZ;mVertexList[mVertexCount].mTextureU=theVertex->mTextureU;mVertexList[mVertexCount].mTextureV=theVertex->mTextureV;aFoundSpot=mVertexCount;mVertexCount++;  }mIndexList[mIndexCount++]=aFoundSpot;}LPDIRECT3DVERTEXBUFFER8MakeVertexBuffer(){LPDIRECT3DVERTEXBUFFER8 aBuffer;gD3DDevice->CreateVertexBuffer((mVertexCount)*sizeof(Vertex),D3DUSAGE_WRITEONLY,D3DFVF_Vertex,D3DPOOL_DEFAULT,&aBuffer)))void *aVertices;aBuffer->Lock(0,0,(unsigned char**)&aVertices,0);memcpy(aVertices,mVertexList,mVertexCount*sizeof(Vertex));aBuffer->Unlock();return aBuffer;}LPDIRECT3DINDEXBUFFER8MakeIndexBuffer(){LPDIRECT3DINDEXBUFFER8 aBuffer;gD3DDevice->CreateIndexBuffer(mIndexCount*sizeof(WORD),D3DUSAGE_WRITEONLY,D3DFMT_INDEX16,D3DPOOL_DEFAULT,&aBuffer)))BYTE *aIndices;aBuffer->Lock(0,0,&aIndices,0);memcpy(aIndices,mIndexList,mIndexCount*sizeof(WORD));aBuffer->Unlock();return aBuffer;}public:Vertex*mVertexList;WORD*mIndexList;intmVertexCount;intmIndexCount;};;  Reasons why apps work with the Reference Rasterizer and not with the HAL are frequently (but not limited to):1) Buggy drivers.2) Your app isn''t heeding the caps returned by the card.  Since the Reference Rasterizer supports damn near every feature of Direct3D your app will probably work here when it won''t work with the HAL device for a particular card.  This might not be your fault because the driver could be returning incorrect caps.  This used to happen quite frequently.Good luck and let us know how things work out when using RefRast.;  I haven''t run the REF rasterizer yet, becuase I have some corrupted files and have to reinstall my whole SDK...But among my machinations, I made myself a special mesh to give myself control data to work with.Surprisingly, when I rendered it with a 1:1 index buffer, it was full of holes...Rendering via this:gD3DmDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST,0,numTriangles*3,   indexPositon,numTriangles);...leaves me a mesh with holes.  But, rendering with THIS:gD3DmDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST,0,numTriangles*4,   indexPositon,numTriangles);...reduces the number of holes, and rendering with THIS one:gD3DmDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST,0,numTriangles*5,   indexPositon,numTriangles);...eliminates the holes altogether-- but is probably intruding on memory somewhere, I bet.  Now, from this, I''m concluding that I''m doing something screwy with the class I use to set up my index buffers (posted above), but for the life of me, I can''t figure out what it is.Well, I''m gonna go reinstall the SDK now... if you have any help, I would greatly appreciate. :S;  Well... I got it-- or got about halfway there, at least.It seems my video card is lying about SOMETHING.  If I reduce the size of the index buffers, it works better...Then, if I give each index buffer its own unique vertex buffer to relate to, it works perfectly.Fast too.  I''m a big nervous about setting a new stream source for each subset of my meshes, but I''ll play around with consolidating them into one big VBuffer later.So, as near as I can tell, either the vertex buffer or the index buffer was considered "too big."  The caps for the card are ridiculously high numbers, so perhaps they''re just dumping bad info at me.Anyway, by shrinking the size of the data to be processed, and by making lots of little vertex buffers instead of one big one for each mesh, I got my performance up, and everything working.Thanks for the help, everyone.