   Vertex buffer optimization
  I''m thinking of running some test scenarios, but maybe some of you have already done similar things.Say I have several objects that have high vertex/index counts, and happen to be dynamic.They do however share indices so I don''t have to do any index buffer switches.Should I do:a) Each object has an array of vertices, and every frame I do this (pseudocode)VB.lock();memcopy(obj1);VB.unlock();drawPrimitive();VB.lock();....and so on and so onOr:b) SetStreamSource(VB1);drawPrimitive();SetSteamSource(VB2);....I have read of course that VB switching is very slow, that was for DirectX7. Is it still slower than having to do a memcopy for every vertex every frame?Any insight on this would be appreciated. 
  I heard that using more than one VB is DX7 was a real performance killer.  I started with DX8 and haven''t seen any mention of this for anything other than DX7.  We''ve used multiple VBs in shipping products, across many cards (from GeForce 3 all the way back to Rage Pro), without any issues.Switching VBs is slow (nVidia says as slow as changing textures), but not terribly slow.  But, if your data is dynamic anyway, you can''t do option 2 without doing the copies as well.For dynamic data, if my vertices are the same format (for FVF buffers), or stride (for non-fvf buffers), across multiple meshes, then I''d use the same dynamic VB for all those meshes.  If I have a two vertex formats, then I''d use two VBs.  There is no reason to create more than one dynamic VB for a specific type of data.For static data, I wouldn''t worry about having an absolute minimum of buffers, just that I kept it to a small number, and shared the same buffer for several meshes, and included vertex buffers as a paramter to sort upon.;  It depends on several factors - size of buffer, type of card etc.For dynamic buffers you might get away with locking all the time, then again if you can avoid it I would.  The only real concrete answers you''ll get is by implementing and testing them. 