Is there a maximum in terms of number or memory space available for creating vertex arrays? I seem to have run into some sort of limit. . .
I have 17.2 MB of data for the vertices and 9.4 for the element array. 409 600 vertices, each taking up 44 bytes. The large number for the element array is due to the fact that I'm rendering individual triangles, rather than strips, to make it easier to divide the mesh for my octree. For this reason, the total number of elements is 2 457 600, each being an unsigned integer -- 4 bytes. This is only 26.6 MB of the 128 that the 9700 Pro has (plus the 512 MB that my system has), yet if I make the mesh much bigger (650x650 rather than 640x640) OpenGL tosses a GL_OUT_OF_MEMORY error at me.
Have I struck a limit or is something wrong?
I have 17.2 MB of data for the vertices and 9.4 for the element array. 409 600 vertices, each taking up 44 bytes. The large number for the element array is due to the fact that I'm rendering individual triangles, rather than strips, to make it easier to divide the mesh for my octree. For this reason, the total number of elements is 2 457 600, each being an unsigned integer -- 4 bytes. This is only 26.6 MB of the 128 that the 9700 Pro has (plus the 512 MB that my system has), yet if I make the mesh much bigger (650x650 rather than 640x640) OpenGL tosses a GL_OUT_OF_MEMORY error at me.
Have I struck a limit or is something wrong?
Yeah, it's huge. . . It's Perlin Noise generated terrain. I'm trying to do this sorta like how it is in Morrowind: the land is broken up into individual cells which are streamed in and out of memory as they are needed. I figure that I'll need to have a bare minimum of four cells open at once. I'd prefer nine, though, just in case the user turns around to go back to a cell that was just taken out of memory. If I simply reused the indices I'd save some memory, and I could probably get this to work if I used 256x256 cells, but I'd really prefer 512x512.