For a 0.1 release, I think we have something fairly decent. I does mostly what it should–it renders a large amount of point cloud data on Minefield, Webkit and Chrome at a fast frame rate. The largest issue we have right now is compressing files, which Mickael is working on.
It took a while to get to 0.1 and I think we’re on the right track. Here’s how we did it:
Creating the Octree
The fundamental problem we face is that of rendering millions of points in the browser in real time. I knew one way we could speed up rendering is to spatially partition the point cloud and do frustum culling. I looked into a few different forms of spatial partitioning and found octrees could be an appropriate data structure. After doing a bit of research and reading, I felt I had an understanding of how to implement one and wrote one in a Processing sketch. As test data, I just generated a series of random points along the surface of a sphere and inserted them into the octree:
The theory was if I had it working on Processing, I could take the exact sketch and feed it into Processing.js. Using a WebGL-capable browser, I should see a similar result. Unfortunately, I did run into a bug, which took up an entire evening to track down. I got some help from the Processing.js community and by using a newer parser, I managed to make the octree and points render on Minefield using Processing.js. The main problem was it was very slow.
Parsing ASC Files
After I had a (mostly) working octree, I was interested to see it accept some real data. I used Arius3D‘s PointStream ImageSuite to convert a PSI file into something I could easily parse, an ASC file. This format presents the data in an easy human and computer readable format:
-8.088 -12.421 -14.033 64 32 16 -0.372 -0.247 -0.894
-8.088 -12.293 -14.033 64 40 24 -0.380 -0.153 -0.911
-8.088 -12.165 -14.033 56 40 24 -0.341 -0.012 -0.939
It was clear the order was positions, colors then normals. I wrote up a small XHR script to download the data, split on spaces, parsed the strings to numbers and inserted the values into the octree. I managed to make it render, but only at around 1 FPS.
The problem with Processing.js is there isn’t a way to create a shape once and render it from a cached buffer. Each frame, shapes need to be re-created in case they deform. The renderer then suffers a performance hit, but this has been filed on our lighthouse account. So I had to create a work-around and optimization to get things rendering at a decent frame rate.
I recently added some fixes so XB PointStream renders on Chrome and I’ll be implementing octant/frustum culling this week. I’ll also start to remove the Processing.js crutch so our library can begin to take shape.