Extending Processing.js With a .OBJ Importer Part 2

Run me!

Yesterday I wrote a blog about creating a .OBJ Importer for Processing.js. My demo compared begin/endShape performance against my importer and things looked pretty good. I could get 100 textured boxes running about 4-5 times faster using the importer.

Last night I decided to see how well Processing.js would perform with a much more complex mesh. I used Blender to export the COLLADA duck model into .OBJ, fed that into Processing.js and saw it ran much faster than I imagined.

Here’s a new demo which renders 25 ducks (over 12,000 vertices each) at 50 FPS on my system. These results are pretty exciting and I can’t wait to get back to hacking on this. Hopefully I can make it in for Processing.js 1.2.


Extending Processing.js With a .OBJ Importer

The only way to create textured geometry in Processing.js is to place vertex() calls between beginShape() and endShape(). This method also allows constructing geometric meshes in a sketch at run-time.

This feature is great for dynamic meshes, but it isn’t efficient if we want to render a static mesh. The library needs to allocate a typed array, assemble the vertices and finally create a VBO which will be discarded in the very next frame. For static meshes, this should only occur once.

This problem has already been addressed in Processing by use of a .OBJ importer and we already have a corresponding bug filed in our issue tracking system.

I was certain I could get a performance boost if a VBO was only allocated once, but I had no idea how big that boost would be. So this weekend I put a few hours aside and hacked out a quick and dirty .OBJ importer. I created a simple demo which draws 100 cubes per frame. I found that on Minefield my .OBJ importer can render 4-5 times faster than using beginShape/endShape.

Run me!

The performance gain isn’t bad, but don’t forget the other problem this can solve. This can allow users to import rich 3D assets into their sketches very easily. Creating a complex mesh with vertex() simply isn’t realistic. Even if this were done, editing the mesh would be an incredible ordeal. Using an importer just makes sense.


The question I’m trying to figure out is should the importer be built into Processing.js or should it be an extension? If we make it an extension it forces the user to deal with multiple js files to include. On the other hand, I can see this being deprecated with another, more relevant file standard such as COLLADA. Thoughts?

XB PointStream 0.5 Released!

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:

  • Support for multiple point clouds per canvas
  • Support for user-defined parsers
  • Support for user-defined shaders
  • A matrix stack
  • A makefile for better distribution of the library
  • Major code refactoring
  • Lots of bug fixes…

Next steps

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.

Upcoming XB PointStream 0.5 Features

Check out what’s coming!

Run me! Run me!

I’m working on some great new features for our 0.5 release of XB PointStream: Parser plug-ins, Shader plug-ins and a much needed matrix stack.

Parser Plug-ins

We anticipate many users will use proprietary file formats which contains their point cloud data. We have an .ASC parser, but many other point cloud file formats exist. So we will allow users to register their custom parser with our library, which will then be responsible for feeding in a stream of vertices and vertex attributes into XB PointStream. I’m still working out the final implementation details, but here’s a rough set of functions users will need to write.

Shader Plug-ins

Some users may want to render only vertices and colors. Others may want to render with realistic lighting or possibly non-photorealistic effects. To accommodate for these cases I have added some functions which allows users to create program objects and set their uniform values.

Users will be responsible for creating their shaders, which gives them total freedom in how they want the final result to appear. I have simplified the XB PointStream built-in shader and optimized it for speed. If users require anything more than just rendering vertices and colors, they will need to override the default program object.

One issue with this is the library sets the model view and projection matrices. But the user needs to define them in the vertex shader. The easiest solution I came up with is requiring the user to define the basic transformation matrices as “ps_ModelViewMatrix”, “ps_ProjectionMatrix” and “ps_NormalMatrix”, much like OpenGL.

Matrix Stack

While working on some demos, I found that trying to create object hierarchies was awkward. So I added a few public functions to manipulate the XB PointStream matrix stack. This will allow users to easily create and manage hierarchical transformations. This is demonstrated in the first example above.