View Full Version : Vertex arrays or display lists for terrain?
02-01-2003, 01:44 PM
I've got a 128 MB Radeon 9700 Pro and I'm getting "out of memory" errors when I try to initialise some vertex arrays (via ATI_vertex_array_object and ATI_element_array) when I start going beyond 640x640 heightmapped terrain sizes. With my current vertex format, that's 17.2 MB for the vertices and 9.4 more MB for the indices (it's alot since I'm using triangles). This could probably be shaved down somewhat (perhaps by using quads), but not enough for what I want to do.
I'm trying to do something like what Morrowind did with terrain: the entire land is broken up into individual cells, which are streamed on and off the hard-drive as they're needed. For this to work well I need to as many as 9 cells open at once. Obviously, I can't do this with 512x512 terrain cells in vertex arrays. Even with 256x256 cells I'm running just short of memeory.
With display lists this would probably be possible, but the result is that rendering would be much slower. It appears I have no choice, though, unless someone has any other suggestions?
02-01-2003, 02:22 PM
Vertex arrays or display lists for terrain?
Use both. You can make a call to glDrawElements() as part of your display list. This is assuming that you are using display lists for more than simply passing vertices to the hardware. There is overlapping functionality between vertex arrays and display lists, but they are still different components with different qualities and possible uses.
Your problem isn't exactly OpenGL specific. You need to find a better trade-off between (image quality versus speed) AND (efficiency versus functionality). Look into techniques such as occlusion culling and variable terrain geometry.
02-01-2003, 02:31 PM
I don't see how this helps me. . . The problem is that glNewObjectBufferATI is tossing GL_OUT_OF_MEMORY back at me when I try and create more terrain cells.
Putting vertex arrays into lists just causes all dereferencing to be done at list compile time and is the same as if you had used immediate mode.
I don't know much about VAOs but shouldn't they fall back to normal system RAM if video ram is all full?
02-01-2003, 07:02 PM
That's what I had been thinking, but apparently it's not working that way. It's not as if I'm trying to create a single -MASSIVE- array, either. Each is big, sure, but individually they are workable. . .
I've got a display list implementation working, though. It's relatively slow, 69 fps as compared to 160 with VAO.
>>nd 640x640 heightmapped terrain sizes. With my current vertex format, that's 17.2 MB for the vertices and 9.4 <<
are u sure the maths adds up?
i assume each block uses the saem indices (the vertices vary) thus u only need one copy
02-02-2003, 02:01 AM
Did you try whether it makes a difference if you call glNewObjectBufferATI with GL_STATIC_ATI or GL_DYNAMIC_ATI? The former should correspond to VRAM and the latter should be AGP (Though I didn't find anything in the spec).
Does anyone have a clue what the memory overhead of VAO is? Seems it's either quite high or ATI allows only a small portion of VRAM to be allocated for geometry. Any facts?
02-02-2003, 08:01 AM
>are u sure the maths adds up?
>i assume each block uses the saem indices
>(the vertices vary) thus u only need one
Quite sure, though you bring up a good point. I definitely -could- use the same indices each time. . . However, assuming the MB I've calculated represent the approximate maximum, reusing indices still wouldn't be nearly enough for nine cells.
>Did you try whether it makes a difference if
>you call glNewObjectBufferATI with
>GL_STATIC_ATI or GL_DYNAMIC_ATI? The former
>should correspond to VRAM and the latter
>should be AGP (Though I didn't find anything
>in the spec).
Yeah, I though that, too, but the result was the same. I guess I can use display lists, though. As long as I keep my cliping plane down to 256 units, my framerates are pretty good (though on a lesser system the story might be quite different).
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.