Archived

This topic is now archived and is closed to further replies.

Serious performance hit problem with VB's

This topic is 5240 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

OK, this is totally messed up and I don''t know how to solve it. I have a long thin terrain defined, kind of like a road. In total, the road is about 40k polygons, but I do some view culling and depth limitation to cut this down. The problem is: If I turn around completely, my frame rates drop to below 3fps for a few seconds and then bounce back up again to a healthy 90fps. If I turn off my view culling, I don''t get this problem and the whole thing chugs along at a merry 8 fps irrespective of how I look around. I figure that the problem is something like I''m causing the card to stall - if I am looking across the road, I''m only drawing a few hundred polygons because the rest of the road is culled, but if I then turn to look down the road, suddenly there are 10k polygons and the card chokes for a few seconds. I am not switching textures or dynamically creating the VB''s. All I''m doing is assigning a single texture, creating an array of 100polygon VB''s and then deciding which out of that array to draw using a simple culling method. Does it sound like I''m on the right track and the problem is a stall, and if so... how do you fix that?

Share this post


Link to post
Share on other sites
Switching VBs is as slow as switching textures. Using 400 VBs (40K mesh / 100 vertex per VB is 400 VBs, right?) is complete overkill. You could fit 40K poly of data into a single VB and simply tell the Draw[Indexed]Primitive call which part of the VB to use.

Each VB also has memory overhead (several K), which is probably taking even more RAM than your actual data.

Minimize your number of buffers... it's very important.


[edited by - namethatnobodyelsetook on August 7, 2003 1:55:17 PM]

Share this post


Link to post
Share on other sites
Does the stall start/stop coincide _exactly_ with the movement of your camera? I''m wondering if it''s the culling that''s taking so long and dropping your framerate, and not the rendering itself.

I had this problem a long while back, where I had an octree with the maximum node subdivisions set too high - the culling was causing a bottleneck iterating through too many nodes.

Share this post


Link to post
Share on other sites
OK. I understand the "don''t switch vb''s" bit, but it still doesn''t explain why there is such a vicious slow-down for a few seconds and then it goes back to the expected frame rate.

I don''t think it''s the culling. Once I''ve orientated the camera down a particular route, I can move it around with no problems. It''s only as I go from very few polys to very high polys (i.e. from a small cross-section of the road to a long view of the road). I calculate the frustrum, the culled VB''s and the camera every frame... regardless.

Share this post


Link to post
Share on other sites