Tomorrow I’ll be giving a talk at FSOSS 2011 titled “XB PointStream: Rendering Point Clouds with WebGL”. Okay, the name is a bit dry, but I’ve packed a lot of awesome into this talk. If you liked my recent post on turbulent point clouds, you should definitely come to my talk! (:
I’ll be in room S2169 at 2:00, hope to see you there!
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!
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.
Emulated fixed function pipeline demo
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.
I borrowed code from Processing.js and C3DL, two other WebGL libraries and wrote up the necessary vertex and fragment shaders.
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.
I spent most of my weekend hammering out a major issue with XB PointStream which the folks at Arius3D pointed out.
The problem was WebGL would not render point clouds on Chrome/Chromium or Webkit when I tried to stream a PSI file over a network. However, after the page loaded and I hit refresh, everything worked.
Additionally, there were no issues on Firefox and when I streamed PSI files locally, all browsers rendered the point cloud without a problem.
I started debugging by checking drawArrays() and getError(), both of which had no issues. I kept trying to look for reasons why the point cloud would not render, but I couldn’t find any evidence of rendering problems.
I made my first breakthrough when I changed the background color. That’s when I saw a single point in the middle of the browser window. I called pointSize() to better see the what it was. It turned out all the points appeared to be clustered together at (0,0,0) with a single black point occluding all the others. This is why it appeared no rendering was taking place. All the points were small, covered by a black point which blended in with the background color.
This helped me better understand the real issue. I continued debugging, trying to figure out why the vertices were all at the origin. After hours of digging through the PSI parser, I found the crux of the bug. I was reminded there are differences between how Firefox and how Chrome/Chromium/Webkit XHR files. Firefox makes fewer requests but reads larger portions of data. The other browsers make more requests, but read smaller portions of data.
I learned the PSI parser assumed it would read tags such as <Min> and <Max> (which contain important bounding box data) in the first XHR request. These tags do appear near the beginning of PSI files, but assuming we’ll have read that far in the first request just won’t work. In that first request, firstLoad() is called which sets up necessary variables used when parsing the vertices. If <Min> and <Max> aren’t encountered at that time, certain variables aren’t set and the vertices eventually get multiplied by zero placing them at the origin.
So why did refreshing work? Since the file was sitting in cache, it appeared to the PSI parser to download in one XHR request. This allowed it to read those crucial Min and Max tags and load properly.
I added extra logic which forces the PSI parser to wait until necessary tags are read before attempting to parse any vertices. While I added the fix I noticed the parser is in some desperate need of cleaning and restructuring, so I’ll need to file a bug on Lighthouse for that.
The core of this entire ordeal boils down to lack of testing. Before doing releases, I run all demos and ref tests—locally. This is why I didn’t catch the bug and why it slipped into the 0.7 release. Since then I uploaded Sundae.js (the ref tester) to a server so I can run all tests over a network as well as locally.
If you want to see the running demo, it’s here.
I’m taking over the completion, debugging and maintenance of the PSI parser module for XB PointStream from Mickael Medel. I’ll be writing a series of blogs while I learn the PSI format and resolve issues.
The first thing I wanted to do was to create a framework that allows me to easily test files generated by Arius3D‘s Pointstream 3DImageSuite Viewer. I created a small demo where I can drop PSI, ASC and PTS point cloud files from my system and see the results immediately.
Watch the demo:
On March 22nd we had a small party in Seneca’s research lab (CDOT) celebrating Mozilla’s release of Firefox 4. We discussed the possibility that Mozilla had waited too long and were ‘beat’ by Microsoft’s release of IE9 . Dave Humphrey reminded us of a prominent open source adage by Matt Mullenweg:
If you’re not embarrassed when you ship your first version you waited too long.
I digested the statement and broadened it to include a small project I’m working on for XB PointStream. It’s an idea which was brought up in our last meeting with Arius3D. It’s simply a virtual museum used to view point clouds. Very much alpha.
So, here’s the demo: (works best with Firefox 4. No, really)
The room is rendered using Processing.js along with a .OBJ reader hack I wrote about a month ago. I hope one day it can reach the level of polish and sophistication of Google’s Body Browser Ha! Yeah right.
Let me know what you think. What should I add, remove or change?
I’m happy to announce we just released XB PointStream 0.6! In this release we fixed a number of problems and added many features. We managed to tie together a number of tools which use point clouds including Arius3D, 3D Studio Max and Blender. Go ahead and upgrade to Firefox 4 and check out the demos page!
The following are some of the major additions we added to the library:
Skip the blog, watch the video.
I recently found out about Project Helix by reading a blog by Chris Mounts. Project Helix is a 3D Studio Max add-on that is being developed at Autodesk Labs. This add-on enables users to work with a large amount of point cloud data and export that data to a file. The technology is still under development, but will eventually become native.
There are two types of files used when working with Helix: PTS (ASCII) and PTSB (binary). The add-on can only work with binary file types (for performance reasons) so converting from PTS to PTSB is necessary before editing the cloud. Once you have modified the point cloud, you can export to PTS.
I was excited to see that PTS was plain text, since it meant I could hack together a parser for XB PointStream and import a point cloud straight from 3D Studio Max.
I opened the sample PTS file and saw it wasn’t much different from ASC:
PTS file:
755047 5.74190 7.95260 4.15158 0.1 255 255 255 5.74190 7.95260 4.15614 0.1 240 240 240 5.74190 7.95260 4.15870 0.1 245 245 245 ...
ASC file:
5.74190 7.95260 4.15158 255 255 255 5.74190 7.95260 4.15614 240 240 240 5.74190 7.95260 4.15870 245 245 245 ...
The are only two differences. First, PTS declares a count at the start of each point cloud. Second, PTS contains a per-point intensity value. I was able to quickly adapt the ASC parser to read PTS files because the formats were so similar. I filed a ticket in Lighthouse and committed the patch for 0.6.
We’ve released XB PointStream 0.5! Have a WebGL-enabled browser? Run the demos! Or check out our video on YouTube.
 |
 |
| Run me! | Run me! |
We added quite a bit since 0.4.5, such as:
Our next release we hope to complete the .PSI reader, have some decent documentation and add more optimizations. To see a list of all the 0.6 issues, visit our Lighthouse page.
Andor Saga 