WebGL Visible Human Project July 30, 2011Posted by Andor Saga in Open Source, webgl, XB PointStream, point cloud.
A couple of weeks ago it was my turn to demonstrate to the other researchers at the Seneca CDOT lab what I had been working on. I gave them a quick presentation of XB PointStream, a WebGL library for rendering point clouds in web pages.
After watching my presentation, Mike Hoye expressed interest in extracting data from the visible human project video and feeding it into the library—creating an interactive version of the video in 3D. The idea seemed fascinating and I anticipated seeing the results. It wasn’t long before Mike casually mentioned he finished everything. He showed me his demo and I was extremely impressed.
After playing around with the demo for a bit I decided it needed at least one change: a slider to slice the subject just like the video. I added a jQuery UI slider which now allows users to create cross sections of the point cloud. I then made some changes to the camera so it always focuses on the section which has been sliced ‘out’.
Something Completely Different
This demo is interesting because it’s different in two ways. First, the point cloud has contents. All my other clouds are actually hollow, while this one has a bunch of ‘meat’ within it.
Second, the file size. Mike mentioned the data set had been scaled down from several gigabytes. This sparked my interest since none of my current point clouds surpass 50MB. If I manage to solve the problem of dynamically loading sections of point cloud files, I could start experimenting with loading the entire 10GB cloud.
Making it Faster
The demo is sluggish right now since it stupidly renders 3.5 million points/frame. However, this can be fixed. Because the user clipping planes work on the Y-axis and because the cloud loads along the Y-axis, it would be possible to do coarse-level culling on sections of the cloud if it was pre-cut along this axis. For example, if I had 5 or so cross section ‘chunks’ of the cloud and one of the clipping planes passed the bounds of a cloud, that section could be culled from rendering entirely. When I have time (ha,ha) I’ll get around to doing that.
A huge thanks to Mike Hoye who on his own time performed some magic and got the data out of the video. This demo would not have been possible without him. I’m looking forward to some higher fidelity point clouds in the future!
XB PointStream 0.75 Released July 21, 2011Posted by Andor Saga in Open Source, webgl, Arius3D, XB PointStream, point cloud.
I spent the past couple of days debating whether I should do a release of XB PointStream. I had all my tickets done for 0.75, but I felt I should add more functionality or fix just one more bug. It can be difficult trying to determine what’s “enough” for the next release of an open source project. It’s something I’m still trying to figure out.
Until that happens, here is 0.75!
In this release I spent most of my time working on the point cloud parsers. I wrote a PLY parser, cleaned up the ASC parser and broke apart and rewrote the PSI parser into two sub-parsers.
All the shaders in the project used to live in string literals. I took care of that problem so the shaders are now much easier to maintain. The necessary code change was minimal, but the impact on the project is rather large. I’m happy I finally freed myself of this burden.
I also began work on creating a proper fixed function emulation shader which I figured users would want.
With that, I’m excited to start working on tickets for 0.8!
Creating Sub-parsers in XB PointStream July 11, 2011Posted by Andor Saga in Open Source, webgl, Arius3D, XB PointStream, point cloud.
I managed to land a major patch for XB PointStream over the weekend. Check out yet another point cloud demo:
The problem originated in the way the library decides which parser to instantiate and use. It does this by file extension. For example, if a .asc file is loaded, XB PointStrem will use the ASCParser. Each point cloud file type supported has an appropriate parser.
However, I recently learned that Arius3D .psi files can have different internal structures. We currently support one format, let’s call it ‘A’. But now the PSIParser needs to support ‘B’ as well. I thought of a few ways to solve this and I analyzed each solution carefully.
My first thought was to just rename the .psi file to something like .psiA. I could then treat it as an entirely new format which would work well with the current state of the library. The downside would be a serious inconvenience to anyone using psi files. This is why I couldn’t follow through with this solution.
Next, I thought of simply placing the logic of both parser A and B in the .psi reader. I quickly decided this wouldn’t work—the logic of one parser is complicated enough. Having the logic of two parsers mixed up would be a nightmare to support. Additionally, it would only be a matter of time before a third format is introduced.
Then I thought about starting an XHR, reading the point cloud header, aborting and then creating an appropriate parser depending on what was read in the header. That new parser would have its own XHR. This would have separated the parsers into their own files, but starting and stopping an XHR didn’t seem elegant.
I ended up going with another solution. I kept the PSIParser which still handles the XHR, but now it reads the header only to decide which sub-parser to instantiate. It then blindly ferries data back and fourth between the library and the sub-parsers. Essentially I created another level of abstraction between the library and parsers. If I ever need to add support for a new .psi filetype, I can easily do so.
Adding a Fixed Function Pipeline to XB PointStream July 4, 2011Posted by Andor Saga in Open Source, webgl, Arius3D, XB PointStream, point cloud.
1 comment so far
For some time now XB PointStream hasn’t had a proper emulated fixed function pipeline shader. I realized I needed to add one since Arius3D‘s plug-in for Internet Explorer reads in parameters which correspond to some fixed function pipeline states. I also figured this would be something other users would find useful.
Because I had already added a small patch which allows passing in shader files to the library rather than strings, piecing together the shaders was easier. Future patches should be less of a headache as well.