Loading VRML into three.js

There’s a couple of VRML worlds in my old collection that would be of great interest to the same communities today, that they were originally created for back in the late ’90s.

There is a javascript library called VRMLLoader.js. The idea is that you can load a VRML world, also known as a .wrl file into your runtime and display it with OpenGL using three.js.

How exciting. I have a whole pile of old .wrl files from back in the day. People with Cosmo Player used to visit them, explore them, and have a good time. I haven’t seen any of them in action for a decade. It would be awesome if I could get them to work using VRMLLoader.js, I could embed them here to show off, and I could re-invent my old site with content people could see. There’s a couple of worlds in my old collection that would be of great interest to the same communities today, that they were created for back in the late ’90s.

Sadly – this ain’t gonna fly. The Loader is at best fussy, at worse, impossible to work with. Only certain types of VRML are supported. Only certain patterns of line-breaks and indentations are supported. Rotational transforms are not supported. Arguments you could easily pass in VRML are not recognized by the loader, and have to be re-written as other, different arguments. And, just when it seems too insane to continue – IndexedFaceSet is not supported.

Excuse me?

That’s like saying you can have a salad, as long as you don’t want any vegetables. That hardly even counts as loading VRML into three.js.

I started off with a cute little 53-line VRML file that just shows a few boxes. Even that wouldn’t work – turns out, back in the day, I had initialized some boxes with the standard “height, width, depth” – but the loader wouldn’t hear of it. Kept throwing errors. I hand-replaced these with “size” – the errors stopped – but the “thing” that ultimately rendered had nothing to do with the original model. Transforms simply weren’t being applied. Without those transforms – every little bit of the model was the wrong size, the wrong shape, and in the wrong position. And that’s just with 53 lines of code!

Here it is. You can try it. This is indeed a VRML file loaded into three.js. And it has “Orbit Controls”, so you can spin it around by dragging your mouse over it. But it is clear to me – those boxes are just sitting on the origin. They haven’t been rotated as the file specifies, the haven’t been translated as the file specifies, they just look silly. This uber-simple VRML file gets firmly brutalized by the .js loader.

Next up, I tried a file I’m a little more interested in, and would spend more time on if it worked. This one is 2,616 lines, and was originally output by 3DSmax back in ’98 or so. I had to re-write all the the “Appearance” DEFs and USEs to get the errors to stop – and convert all the “height, width, depth” constructors with “size” – even just to see something with the translations ignored – and all I wound up with for my trouble was no errors coming out of a black screen that did nothing.

It seems clear, after a couple of hours of discovering that there is no end to roadblocks in my path, that reviving my old VRML files with VRMLLoader.js is just not on the table. It looks like I’d have to re-code them all, by hand, to conform to the finicky expectations of the loader – then I’d have to re-invent IndexedFaceSets and rotations? And what, re-code that up by hand too? No thanks. That really doesn’t satisfy my requirement that I could “use” these old files.

I’ve filed this post under “experiments“. I did some experiments. The results were not encouraging. In fact, the results have encouraged me to look elsewhere for a workable solution. That’s experiments – sometimes, even knowing something like that is a legitimate, valuable outcome.

I still do want to resurrect those old VRML worlds. But I think the next place I’ll try is with Blender. With any luck, it can read these files, and turn them into something that three.js, or X3DOM, or maybe even blend4web, can load into a browser without a plugin.

More on that soon

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookEmail this to someone

Author: Pete

Editor-in-Chief, Lead Software Developer and Artistic Director @ 3dspace.com