Skip to main content
gamedev.net
🔒 Locked

More VertexBuffer Problems

Started by onnel Apr 19, 2001 at 5:15 AM 6 replies 450+ views
Original Post
onnel
onnel
First, thanks to all who answered my vertex buffer questions and gave useful advice and guidance! I''ve now moved my project deom DX7 to 8 and from simply using indexed vertices to using indexbuffers and vertexbuffers. The problem is, using the vertexbuffer under DX8, my code is now actually slower! I know I am doing something wrong, as vertexbuffers work wonderfully for others, so any help figuring out the problem would be much appreciated! I''m rendering a grid of rectangles (each made of two triangles) for terrain purposes. Under DX7 with a 10x10 grid (200 triangles), it was blazing along at 400 FPS..now it''s down to 35 or so and if I up the number of triangles, it crawls to a stillstand. What I am doing is this: CreateVertexBuffer and IndexBuffer. These have set sizes (4000 vertices and 6000 indices) and are reused. this is done prior to rendering. In my render : { Create empty arrays for my vertices and indexs Loop through all my objects until my arrays are full. (the following is done for both the index and the vertex buffers) lock buffer memcpy the array into the buffer unlock drawIndexedPrimitive. repeat as necessary until all objects have been rendered (when 10x10, no repeating necessary, only called once) } Basically, this renders up to 1000 objects (2000 triangles) per call of drawIndexedPrimitive. This puts me at 4000 vertices (6000 indices) per call, which is within the realms of what I''ve seen recommended. Anyone see any obvious problems that would be causing this huge slowdown? Another strange thing I''ve noticed after switching to DX8: my framerate is no longer constant depending on what is onscreen. Under DX7, I''d get the framerate no matter what was on screen (empty screen or my terrain), but now I get a drastic slowdown when my squares are on screen. The only addition thing is that my squares are now textured (all sharing the same texture for now). Would this cause the slowdown when displaying the squares vs. empty space? Might it also explain my drastic slowdown? Finally, what parameters are recommended for initializing index and vertex buffers? Managed, write only, etc...? Thanks as always for the great advice this board always gives! Onnel
sysmark
sysmark
You are rendering to much at the same time! It''s best to send about 100 triangles at a time to the renderen. This means 100 triangles are transformed and lit, and then the videocard is rendering them. While the triangles are rendered the next 100 triangles are transformed and lit, and so on.
onnel
onnel
Really? Most of the stuff I read on VertexBuffers seemed to imply that you wanted 1000+ (often much more) vertices. I thought that around 4000 or so was considered ideal (which is how much I''m doing).

I''ll definitely try it with less, though.

Thanks for the feedback.

Onnel

quote:
Original post by sysmark

You are rendering to much at the same time! It''s best to send about 100 triangles at a time to the renderen. This means 100 triangles are transformed and lit, and then the videocard is rendering them. While the triangles are rendered the next 100 triangles are transformed and lit, and so on.


sysmark
sysmark
I think that if the videocard has hardware T&L it doesn''t matter. nVidia has a white paper on vertex buffers on their site. I suggest checking that out.
onnel
onnel
It''s a great paper and was very useful. That''s where I got the idea of number of vertexs to have in the buffer. They state that sizes in excess of 2000 vertices are "measurably superior".

They actually suggest using 4,000 vertices as the target for a VertexBuffer size. The model they propose for dynamic data is pretty much exactly what I''m doing to:

1. Create a WRITEONLY VB in AGP memory which is large enough to hold 4K of vertices.
2. Create system memory copy of all the data which matches that FVF.

Then at render time:
BeginScene()
Lock the appropriate VB using WRITEONLY and NOOVERWRITE for
the first lock, and using both WRITEONLY and DISCARDCONTENTS
on subsequent locks.
Copy your virtualized vertex data into the matched VB until the VB is full.
Unlock the VB, and immediately render from it. Continue with this VB
and FVF until all data of this format is rendered.
Cycle through the full set of FVFs until they''ve all been rendered.
EndScene()
Flip() or Blt()


Did that optimal usage (ads described by Invidia) change at all for DX8 and using IndexBuffers? am I misreading or misunderstanding any part of the idea or their suggested structure?

Onnel

quote:
Original post by sysmark

I think that if the videocard has hardware T&L it doesn''t matter. nVidia has a white paper on vertex buffers on their site. I suggest checking that out.


sysmark
sysmark
My terrain renderer uses a Quadtree so that I can render only the triangles that I see, so I never had your problem. To add to that I''ve been programming in OpenGL lately, so I don''t have that much experience with vertex buffers. But on several webboards I read that cutting the renderdata into pieces should improve the rendering speed, so...
onnel
onnel
I\ll try it at various different sizes tonight when I get home and report on the results!

Thanks,
Onnel

quote:
Original post by sysmark

My terrain renderer uses a Quadtree so that I can render only the triangles that I see, so I never had your problem. To add to that I''ve been programming in OpenGL lately, so I don''t have that much experience with vertex buffers. But on several webboards I read that cutting the renderdata into pieces should improve the rendering speed, so...


onnel
onnel
I tweked around yesterday and found that around 200 triangles/call to drawPrimitive seemed to be optimal. this means 400 vertices and 600 indices/call.

It seems strange that these numbers are so different than what is recommended in the nvidia paper (2000 vertices+). Anyone else using drawPrimitive care to share any input on what they''ve found to be the optimal number of vertices to pass in (using an IndexBuffer as well).

Onnel

Topic Locked

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

Sign in to reply to this topic.