   "correct" way to use static VB's??
  Just getting frustrated trying to find the "best" way to use the static vertex buffers..I know that for the dynamic ones, you can create a small loop where you attempt to lock down the VB, append new vertices, then blast them to the GPU..I want to maximize the GPU with static buffers, but not sure how to go about this..ie. DrawPrimitive with only 2 primtives is an extreme waste (even for static vb''s) isn''t it?thanks..  
  I would go fully dynamic - not even the "fill and throw away" thing. I made tests wiuth terrain, and so far - the tests went well.The idea is: use a dynamic vb as a "buffer", like a file. One vb can hold the vertices for a lot of models, as long as they share the vertex declaration. Upload new data as needed, but be CAREFUL WITH THIS - no "discard", as I change parts of the buffer, but not uploading models every frame - works perfectly if you stay out of CLOD algos (but you may use VIPM''s). As you upload data seldom, performance is ok.Now, for your calls: render a couple of hundred polys per call. Period :-) RegardsThomas TomiczekTHONA Consulting Ltd.(Microsoft MVP C#/.NET)  ;I posted a dynamic vertex buffer class here ---Brent Gunning | My Site;  Thanks for the responses guys..I''ll check out that Vertex Buffer class that was posted by RapidStunna..I have another stupid question then. Let''s say I''m implementing all my rendering with dynamic vertex buffers. How then would I be applying matrix transformations to my objects?   //ie. I''ve got object structs defined, but do I even//need matrix transformations to move them now?struct sVertex {   D3DXVECTOR3 vecPos;   DWORD  dwColor;};//so if I have some objects (cubes, pyramids, whatever) //composed of the above sVertex, would I just go through//and modify their positional coordinates individually?//How would I implement a matrix transformation to one object//if my dynamic vertex buffer contains 1000''s of vertices of//objects throughout the entire scene..  ;  Dynamic vb = agp traffic = bad. Static vb = local memory = much higher bandwidth = good. In any case you have three options for xforms: 1)use vertex shader 2)use fixed function xform 3)use ProcessVertices() on cpu. You take your geometry verts, put them inside a dynamic vb, setup vertex shader and constants or fixed function model to world xform then issue a rendering call. You specify the range of verts in dynamic vb that you want to render and api will automatically xform them when you issue rendering call. Or you can pre-xform on cpu then fill vb then set world matrix for vertex shader or fixed function xform to identity and render the geometry again using vb fences. If your app need xformed vertices for some reason ie. collision detection, etc. you will have to use cpu for that. You don''t want to read vb unless they''re in system memory and even then they might be compressed or optimized. Any reading from video card is bound to be slower than reading from system memory. If you use software vertex shader than put vb in system memory so cpu doesn''t have to go to video card.  