I have a lot of data (ply files) and I need a way to load it, display it while loading the next block and then displaying that so and so-forth. I have two separate projects where this is the bottle-neck, one for ascii ply files one for arbitrary photos on a consumer machine.

To load ply files faster, I am currently sequentially loading files using OpenFrameworks’ loadModel. The issue is that this makes openGL calls, it seems pretty hairy to separate them out. OpenGL can only be running on one thread, because openGL has a server/client model, and to shunt graphics to the GPU to display can only happen in one thread.

I would love to be able to make multiple threads running separate openGL instances, and then write them to PBO (pixel buffers), and have one thread grab the buffers and render those.

When researching this issue I ran into this article, it states that since GPU speedup can only hasten the 3D object’s parsing, by Amdalh’s law the whole application speedup is limited by how fast the CPU can fetch the files and read the lines into memory. Parsing is very easy to implement in parallel, especially for my case because the points are unordered.

Potential moves going forward:

more research on why the application is running slow in the beginning:

• tool=memcheck: memory debugger
• tool=cachegrind: estimate on the cache usage of an
application
• tool=callgrind: provides a trace of the function calls(cachegrind.<procid>.out>  kcachegrind: visualization tool of valgrind output files

Tackle the problem at its base:

• Reduce the point clouds with down sampling randomly or perhaps projection back onto the video footage it was made with in the first place since I recorded using a greenscreen.
• Switching to a different file format (right now I am using ascii ply) that will be more efficient, like binary or converting the point clouds to meshes (where I would need to find a way to mesh the points)
• Encoding the movements of the points and then loading only one point cloud and then streaming the transformations.
  • this might work because then I can encode the point movement as a polynomial and then from there reduce the data stream size even more by approximating the polynomial via LaGrangian interpolation.