   Locking vertex buffer
  Hi!I would like to ask, if i can have MORE than 2 vertexbuffers locked?If not, is it a performace hit locking it more frequently ? ( for example 4096 times per frame )Is it OK to have vertex buffer locked for longer time ? i will lock buffer, then will do calculations and after that, i will unlock a buffer.I'd like to be sure, before i will change my code  Thank you very much for your answers.   
  In short, it depends.Is this Direct3D 9, 10, or 11? Also, are the VB's dynamic? Are you rendering with them every frame? Why the heck do you need 4096 locks per frame anyway? Are you locking/unlocking from the same thread as you're rendering in?MSDN has this to say about your problem:http://msdn.microsoft.com/en-us/library/bb147263%28v=vs.85%29.aspx#Using_Dynamic_Vertex_and_Index_Buffers   ;  It's dx9 and yes, it's a same thread.I am going though octree and adding object into renderlist, when this is done .. i copy all items into VB.My idea is not use a renderlist and copy items directly into VB. That's why i need to lock VB, go though octree and then unlock VB.So, yes, i am rendering with them every frame.About 4096 locks. It's for terrain, but if i can lock it on longer time , i don't have to lock unlock it so many times .. i will just go though quadtree, add instance structure into VB and it's done.So, you think, this is possible and ok with parameter DYNAMIC ? and perhaps locking with parameter DISCARD ? ( because i don'T need old data ). What if i want to resize VB ?Thanks   ;It's dx9 and yes, it's a same thread.I am going though octree and adding object into renderlist, when this is done .. i copy all items into VB.My idea is not use a renderlist and copy items directly into VB. That's why i need to lock VB, go though octree and then unlock VB.So, yes, i am rendering with them every frame.About 4096 locks. It's for terrain, but if i can lock it on longer  time , i don't have to lock unlock it so many times .. i will just go  though quadtree, add instance structure into VB and it's done.You'd be better with a single lock, but it's better to keep the lock duration as short as possible. If in doubt, try both and profile - You could test this easily by writing the code to lock the VB once, and profile that, and then create a big global array and write into that instead of the VB, and then lock, memcpy and unlock after the buffer has been filled.What if i want to resize VB ?If you lock the buffer more than once per second or so, you want a dynamic buffer. Generally, it's good to create a large buffer, and lock it in segments, the first segment with DISCARD, and then the rest with NOOVERWRITE until you get to the end of the buffer. For terrain, you can probably just lock with DISCARD every time.What if i want to resize VB ?You can't. You have to destroy and re-create the buffer.   ;  Thank you Evil Steve. Let's code ;-)   ;  You can use a normal memory buffer and fill it with your vertex data while traversing the quadtree.When you've all the data you need, you can lock the vertex buffer, memcpy the memory buffer and then unlock the VB   ;You can use a normal memory buffer and fill it with your vertex data while traversing the quadtree.When you've all the data you need, you can lock the vertex buffer, memcpy the memory buffer and then unlock the VBwhat i do is lock the vertex and index buffer, push each v0,v1,v2 vectors in to a std::vector , then transformcoord on the models matrix that way the vectors are updated at runtime and there's no locking needed at runtime, you're just updating the vector's.   ;  Anddos, can you please elaborate ? I wonder if one can actually change the contents of a vertex buffer without a lock at all in DX 9 (other than using some vendor specific tricks like ATI's render to vertex buffer).   