Vertex Buffers

Started by
7 comments, last by JSCFaith 22 years, 4 months ago
Hey, I am creating my first 3D program which is a basic 3d isometric engine. All I am not sure of is this. Is it alright for each tile to have its own vertex buffer? Is that ok or bad? This may sound like a stupid question, but I just had to ask. As of now, each tile has its own vertex buffer and I want to make sure that is not terrible design. Well if you could answer my question I would appreciate it. Later, James
Advertisement
You should probably store at least all of the ground tiles in their own vertex buffer. In general, you want to batch things together as much as you can. You should always be looking for ways to batch because the graphics card does much better when dealing with big chunks than when dealing with small chunks. Something to consider:

SetStreamSource(TileVB1) - moderately expensive operation (when used unnecessarily)
DrawPrimitive() - really inefficient for small batches
SetStreamSource(TileVB2) - there''s that expensive part again
DrawPrimitive() - inefficiency again

etc.... You aren''t going to be able to put *everything* into one bucket, but make it a rule to look for batching opportunities.
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials
As CrazedGenius said, switching vertexbuffers is expensive and often unnecessary. The Graphicspipiline only work efficiently if your VB contains at least a few thousand vertices (see DX SDK help/ chapter optimization). I would recommend to use indexbuffers. Create one indexbuffer per object/tile/ whatever, but use only one big VB (2 if your first VB is full) Then use SetIndices() and DrawIndexedPrimitive(). This is the way I draw my objects. It''s a lot more efficiently than using one VB per object.
greets Flo
Well, basically what you are saying is, create one gigantic vertex buffer and many index buffers. I can guess then that SetIndices() is not a very expensive operation. Well thanks for your help guys.

Later.
Well don''t get this wrong, it''s also expensive if you have hundreds or thousands of small indexbuffers. The problem is that you have to find a good way in between. Keep your buffers large enough to be processed effectively by your graphicscard and at the same time keep the number of buffers as low as possible. The more DrawPrimitive() calls you need, the slower it will get.
Hope this helps.
greets Flo
I''m guessing that you have several tiles that are all moved or drawn at the same time with the same transformations. Those are the types of things to throw into one big vertex/index buffer.
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials
Well, I was thinking about making one large Vertex buffer and one large index buffer for the tile map, but then I thought. How will I change the texture depending on the tile? If its one large vertex buffer and one large index buffer and you use 1 call to DrawIndexedPrimitive, how can I allow more than one texture on the map? If you could help I would appreciate it.

Thanks a lot,
James
Well, I don''t think that every single tile on your map will have its own texture. Generally you will have some bigger parts of the map which have the same texture. If thats the case you can simply make indexbuffers for the chunks of your map which have the same texture. That reduces your buffercount, your buffers will be larger and you need less DrawPrimitive calls. The easiest way to do so is to write a map editor which generates the map information automatically. Internally you can still use your n*m grid for collision or whatever.
greets flo
Also, depending on the sizes you need for the textures, you could create a larger texture from several small textures and use texture coordinates to sort everything out.
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials

This topic is closed to new replies.

Advertisement