Blend4web vs. Three.js

As a sequel to my Feb 23 post X3DOM vs. Three.js, I’d like to quickly compare Blend4web vs. Three.js, using that same old arbitrary VRML file as a neutral sample. Blend4web is an add-on for Blender, the open-source 3D authoring tool I use.

Here’s how the Blender workspace containing my old VRML file looks when I export it using Blend4web:

And here’s the same Blender workspace exported as a COLLADA file and then imported into Three.js:

You can drag your mouse on either of those to move them around. Each button gives you a different motion when you drag. Each example uses each button in a different way.

As always, we see that they render differently. But they do both render in your browser, with no plugin, so that’s cool right there. As always, I find myself preferring the way the Three.js engine handles the “glossy” texture that was put down in the VRML file almost 20 years ago. Retro VR.

While both technologies are doing a similar job – getting 3D content to render in your browser with no plugins – they are doing it in an entirely different way.

Blend4web vs. Three.js – under the hood.

I’ve described the process by which we can load COLLADA files into Three.js. We set it all up in an html file. We import libraries. We create scenes, cameras, and controls.

When you “export to html” with Blend4web – there’s none of that. No writing a blank, container html file. No loading JavaScript libraries. No setting up a camera or controls. No importing an external file. When you export – you get this html file that contains EVERYTHING you need to deploy.

On the one hand, that’s mighty convenient. On the other hand, you could never work with that file. If you wanted anything different – you’d have to go back to your Blender workspace and do any changes there. Though, maybe that’s exactly what you’d want out of life? For example, when you’re working in Flash – that’s how you do it.

I see that Blend4web has 2 export options. One is to export html, as described above. The other is to export JSON. Interesting, I have done a couple of things that used a generic JSON-export option – and then hoovered the JSON up with JavaScript – but I found that option so limiting, so clunky, that I moved on to COLLADA files. Perhaps – when the JSON option is handled by the Blend4web software – it’ll kick way more butt. But for now, I haven’t tried that yet.

The Blend4web one comes with a “loading” screen. With samples as trivial as these, that seems a little silly. But for bigger, more complicated worlds that actually do take a while to load, that would be quite polite. And it’s “free” with your “one-click” deployment.



One difficulty I’m having with the Blend4web one is that funky flourish of social media icons. That has nothing to do with me. And, as it’s buried in that all-in-one hashed html file, I can’t just pop it out of there. And this is because there is a free version of Blend4web, and a “Pro” version that costs (eek) $990. I think that’s gonna stand in my way. On one hand, I’m not gonna pay $990 for something I may only use for these cheeky weekend demos I do for my blog. And on the other hand, I don’t feel I can go very far with a thing that’s gonna distract from any whimsical user interface I may feel like experimenting with.

Anyways, an interesting technology. As a tool agnostic, I see no reason not to have this in the toolbox.

 

 

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

One thought on “Blend4web vs. Three.js”

Comments are closed.