🔒 Locked

Vertexbuffer data organisation

Started by Kraiklyn Jun 16, 2004 at 5:39 AM 2 replies 700+ views

Original Post

Jun 16, 2004 at 5:39 AM

Hello, I have currently, a large static vertex buffer holding vertex data correlating explicitly with the layout in the respective bmp used for the height mapping. The landscape renderer works on the basis of 33x33 chunks indexed into this vertexbuffer. What im interested to find out is whether there is a major impact having the data organised this way, where the rendering of each chunk would effectively involve skipping over ranges of memory for each draw primitive call. i.e the vertex indices are not all that tightly packed for each patch. Should i upload vertex data patch by patch to ensure a more contiguous configuration of vertex indices, where the rendering of each patch involves vertices within a contiguous block of memory? Im not getting a significant performance hit at the moment, but just wondering if a best practice would be to make sure when rendering from a vertexbuffer, that memory was clumped together when making a drawprimitive call. Thanks in advance for any thoughts given. Kraik

Alex

Jun 16, 2004 at 6:16 AM

You mean vertices within a patch are all together in memory? If you tell D3D to render an entire patch, then It'll clip anything not on screen and it won't get rendered anyway. Depending on the size of your patches in the game world, if D3D is clipping more than it is rendering, then you may want to consider a different organization cause it's kind of wasting the call.

If these patches are kind of small in the game world, and your going to be rendering a number of them at a time, several DrawPrimitive calls probably won't be that big a deal. It gives your computer the chance to use the GPU and the CPU simultaneously.

Not sure if this is what you wanted to know or not...

Kraiklyn

Jun 16, 2004 at 10:13 AM

Thanks Alex,

No, not really. Perhaps I can explain a little better:

I have got the culling handled fine. what im refering to, is a single call to drawindexedprimitive and how the vertices within the vertexbuffer are organised.

At the moment, the memory position of a single vertex within the vertexbuffer can be correlated to the same memory offset the pixel has within the heightfield bitmap.

Doing it this way means that the index buffer defining a single 33x33 patch, indexes into a non-contiguous area of memory. On the other hand, if i define each patch, then upload to the vertexbuffer, the indexbuffer will be defining a patch where all vertices are within the same bounded area of memory.

What i am trying to determine is the impact of my approach, if any.

Regards
Rob

Raloth

Jun 16, 2004 at 10:59 AM

Somewhere in the MSDN it says something similar to: "Use vertices sooner, rather than later."

What this means is that having the indices (0,456,890) to build a triangle is very bad. First is the whole issue of memory cash, but second is the fact that, as far as I know, the video card must transform triangles 0 through 890 just to render that single one. Grouping vertices by patches can definitely increase speed if this is the case, but it really depends on where your bottleneck is.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.