Extending Processing.js with a OBJ Importer Part 3 September 29, 2011
Posted by Andor Salga in Open Source, Processing.js, webgl.trackback
OBJ model loaded into Processing.js

For some time now I’ve been working on an OBJ loader for Processing.js. This loader reads and parses OBJ files which contain 3D models as a set of vertices, normals and texture coordinates. The loader then creates the necessary WebGL buffers used to render those models in Processing.js.
A project for Processing already exists: Saitoobjloader. I’m simply trying to make a JavaScript equivalent.
0.1
The project has lagged, significantly. But not because I was working on XB PointStream. It lagged because calling something 0.1 can be very difficult. As I kept adding support for more features, my standards for the loader kept increasing thus pushing the date further and further back.
Then about a week ago, I decided it was too late and it needed to ship now. In a fury I wrote a series of references tests and decided that would mark 0.1. When I finished the tests I ‘released’ the code. That is, I put the associated ticket up for review.
Looking back on the experience I learned a couple valuable things.
Start with tests
If I had created 10 tests and said to myself “Once it passes these, that’s 0.1″ I could have had it out the door a long time ago. At the time I didn’t realize what I did, but in retrospect it makes sense. I had set a hard standard for the project and a completion criteria.
Set Limits
Just before releasing I was hesitant as I wanted to add support for quads. I already had the logic from a previous project and knew it was simple to implement. But I knew as soon as I added support for it, the project would slip once again. Instead of writing the code, I added known failure ref tests. I moved quads from 0.1 to 0.2. In a strange way I’m more proud of my decision not to support quads then the entire project itself.
My supervisor (Dave Humphrey) has a new intake of open source students trying to figure out the whole 0.1 thing too. Hopefully this might help some of them.
Moving Forward
Now I didn’t get the actual code staged into Processing.js. But the result of placing the ticket up for review spun off an important meeting with some of the lead developers of Processing.js: Dave Humphrey, Jon Buckley and Mike Kamermans. We talked about the necessary changes Pjs would need to support libraries and we set some milestones.
I’m looking forward to continuing my work on the loader. Once we have library support in Pjs, we’ll also have a decent OBJ loader to go with it (:
Hey Andor, this is all amazing. WebGL in processingjs really rocks. Is it possible somehow to get a code for obj loader already? Thanks.
Matas,
The devs working on Processing are making OBJ loading native. This means we can get the OBJ loader landed in Pjs sooner since we won’t need to wait on developing a plug-in architecture for extensions.
With that said, the next release of Processing.js will be sometime in the new year. By then I hope to emulate how P5 is using the loader in Pjs.
Can’t wait for this… Just finished writing my own poor .obj vertex loader that recreates vertices between beginShape and endShape in draw() function and as you’ve mentioned already in one of your posts it’s a slow procedure… Will be happy to have static mesh objects implemented by someone smarter in these things
Good luck!
This is great. One question…I’m trying it out with my own obj and it seems it is either too large or too small. Can you post the link to the obj file that you used?
Actually, nevermind. I scaled up my model and now I can see it!
[...] blog post is the continuation of a series of blogs [1, 2, 3] related to adding .obj file support to Processing.js. This code I’m working on is important [...]