1
\$\begingroup\$

Currently I have one buffer for my vertex data and one buffer for normals data. I fill them and then pass them to OpenGL for rendering.

The problem is when I load too large mesh file like "Lucy" from Stanford

The program stops responding or the computer freezes. I allocate my buffers like that:

Vector* vertData = new Vector[numVertices];
// then fill the array with data

where numVertices = 14 027 872 in this case. That allocation doesn't throw bad_alloc exception so I guess there is nothing wrong with the allocation of memory.

I am testing the program on a x64 windows 7 platform with 4GB RAM and GTX 470 which has 1280MB of memory. Windows task managers shows that the program uses about 2GB ram when I run it.

Note that when I choose to render not all the voxels of the mesh - every 2nd for example, then I have no problems. Maybe the GPU runs out of memory and that's why the program hangs ?

Shoud I split my mesh data into more vertex/normal buffers and then pass them to OpenGL one at a time or there is a better way to do this ?

\$\endgroup\$
  • \$\begingroup\$ That buffer is only 320 MB (assuming three component positions and normals only). You're more likely to be running into a vertex count limit than a memory one. Do you get any errors from glGetError or the debug callbacks (if you have them)? \$\endgroup\$ – Josh May 7 '14 at 17:23
  • \$\begingroup\$ I can check tomorrow for errors from gl , can you tell me more about that vertex count limit ? Is that some limit by OpenGL ? \$\endgroup\$ – Geto May 7 '14 at 17:43
  • 1
    \$\begingroup\$ There used to be a parameter you could pass to glGetIntegerv that would tell you the maximum optimal number of elements in a glDrawRangeElements call, as a performance suggestion. It appears to have been removed in more modern versions though. I don't realistically think you are running into any limitations with only the data you've provided, but I wonder if something else in your program is; that's why I think you should do an error audit. \$\endgroup\$ – Josh May 7 '14 at 18:16
  • \$\begingroup\$ Definitely check for errors after glBufferData/glBufferSubData! \$\endgroup\$ – glampert May 7 '14 at 19:20
5
\$\begingroup\$

Generally, to render extremely large meshes you want to subdivide the data into smaller, separate meshes and render each of those individually.

This can be useful to alleviate memory pressure (although it won't always do so, in practice), but it also allows you to perform some culling on the large geometry to avoid bothering rendering huge chunks of geometry that are not, for example, visible.

Note that you probably don't want to just split the buffer by taking the "first N" vertices followed by the "next N" vertices and so on, as in general this will produce a subset of vertices that isn't logically grouped well for culling. You'll have to load the entire set and intelligently subdivide it, perhaps into a 3D spatial partitioning structure like an octree.

(The reason this doesn't always alleviate memory concerns is you still need to keep the data somewhere on the GPU if you want to be able to quickly render it, and that might actually introduce more memory pressure due to the small per-buffer overhead. You can evict things onto the CPU but then you start trading on the performance cost of resubmitting the geometry when you need to render it, and potentially fragmenting the GPU's memory space, and so on.)

\$\endgroup\$
  • \$\begingroup\$ Thanks for the answer, I thought so. Maybe I will divide the mesh into groups of voxels and render them separately. I will try to implement that this week. \$\endgroup\$ – Geto May 7 '14 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.