I’ve just gotten around to implimenting VBO into a heightmapped terrain (quadtree). Is their a minimum amount of polygons to be placed in a given vbo? Each node has roughly about 1200 polies in it, and i’m using interleaved vertex arrays.
however i’m getting the same frame rate wether i’m using VBO’s, standard VertArrays, or even just rendering straight polies. And all i’ve read from other’s posts is that the VBO’s helped a huge amount of engine effency.
Am i missing something in the implimentation that i should be aware of?
btw, the terrain is segmented into quads, I guess, so is yours . and I noticed no difference from using a quad tree for culling compared to simply test every quad (final tree node) for visibility, although more objects were tested, it was faster, seems that the visibility testing is faster than traversing the tree.
Is all of your vertex data floats (except for colors, which can be unsigned bytes)? If not, then your speed won’t be any better than regular vertex arrays.
Adrian is right. Most applications are fill-limited.´
Make sure you have a LOT of triangles (say 100.000 or more), which get ALL rendered. Also disable texturing and all other stuff, which would reduce the fillrate.
When you have your application to be geometry limited, than check again the difference between VBO, VAs and immidiate mode.
Adrian : Reducing the window size did infact change the results, thanks!!
Another question though, how does an application become “fill-rate” limited, and why does that have such a big impact on VBO, VA, & IM?
Does reducing the window size simply reduce the number of pixels required to render? and If that’s how we get around it, then how can games now adays pull off 1024x768 resolutions ??
Reducing window size does indeed reduce the number of pixels rendered.
If you are fill rate limited then it doesn’t matter what other optimisations you do(e.g. VBO etc), the app has to wait for the card to finish filling polys at the end of each frame and this will limit the speed of your app.
An application becomes fill rate limited if you draw lots of overlapping polygons. It’s not that hard to reach the fill rate limit.
To reduce your fill rate usage you can
not draw polys/objects that are completely occluded.
Draw polys/objects in front to back order.
If you don’t require a 24bit z-buffer, use 16 bit.
. and I noticed no difference from using a quad tree for culling compared to simply test every quad (final tree node) for visibility, although more objects were tested, it was faster, seems that the visibility testing is faster than traversing the tree.