Render huge point cloud that doesn't fit in RAM

OpenGL
1

Hi!
I’m not sure if it is the right place to ask, but I’ll give it a try. If it is not, just tell me, I will delete my post.

I would like to create an application with OpenGL that can render point cloud that are too big to fit in RAM (see 200Go Files and more).
In order to do that, I was thinking about creating a file-based octree, in which every file contain node point cloud. But call for file is really time consumming.
My question is, would it be possible to associate a VBO to a file, so everytime i want to draw a file, I just have to render the associated VBO?
(Or is there any other method I didn’t think off yet, that you know to achieve that?)

Thanks a lot!

2

200 Go Files doesn’t in-and-of-itself establish that it won’t fit in RAM (sounds like it’s a text format and not very space-efficient), so I’ll assume that you know this somehow.

What kind of call are you referring to. A GL draw call?

Sure, that’s one of many, many possibilities. Also, you need not have the number of VBOs correlate with the number of objects in your “game world” either. For some tips on that, see: Buffer Object Streaming techniques in the OpenGL Wiki.

Moreover, for the case where you’ve stored multiple objects or meshes in shared VBOs, you can combine the draw calls using MultiDraw Indirect rendering.

3

Hi !
Thanks a lot for your answer. Sorry I was out of office for a while!
I’m talking about IO call (here, it would be to read from a file), but I just learnt about memory mapped file, maybe it’ll help me.

But, to create a Buffer Object Sreaming with file, I assume the program will have to read the file everytime in order to read the new points, no?

4

Yes, presumably.

Buffer Object Streaming is concerned with efficient transfer from CPU memory to GPU memory. How you get it into CPU memory in the first place is a separate issue.

That is, unless you get disk I/O to directly fill a subrange of an already-mapped OpenGL buffer object (which incidentally need not be done on the draw thread). However, it didn’t appear that Go files were in a “ready-to-render” format, so that’s all academic.