Three.js OR x3dom

找到一篇讨论关于实施Web3d时选择框架/库的帖子，

http://3dspace.com/2016/02/x3dom-vs-three-js/

Here’s a quick look at X3DOM vs. three.js. Two very different tools, that both do something I’m very interested in – allow you to publish 3D content and virtual worlds on the open web, without a plugin.

 

I found two good ways to get 3D content (from an ancient VRML file) out of Blender, and out on the open web where anyone with a browser can see them without a plugin. So I’d like to compare X3DOM vs. Three.js.

I loaded a COLLADA file into Three.js:

 

And I loaded an X3D file with X3DOM:

 

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.

And there they are. X3DOM vs. three.js. Not side-by-side, but 0ne on top of the other at least. Both running in your browser, without a plugin.

They certainly look different. Though, each comes from a different type of file. The difference could arise from different information about materials, textures, shading, and lighting contained in the files. Or, they could simply be rendering differently. I think one of them looks “better” – though, the way the other one looks is more suited to what I want to use it for. (I like the deeply shaded, glossy look of the three.js one.)

The X3D file is way smaller. 133K, compared to 298K for the COLLADA file. But again, the fancy lighting and shading – that could simply be one of the benefits of using a more equipped, and heavier to move, file format.

But of course, for each example, we have to load a little bit of JavaScript to give the browser a way to show the file. For three.js, we load a 400K base file, and a 100K loader. For X3DOM – we load 900K. These are both quite small, compared with the file sizes that would be involved if we were to load virtual worlds much more complicated than the simple examples I’m showing here.

I think I like the “orbit controls” on the three.js example a little better – I find the controls on the X3DOM one a little harder to handle.

But those are pretty superficial observations. Under the hood, these two approaches are really quite different.

X3DOM vs. Three.js – under the hood.

One difference is that three.js is a framework for WebGL. Which is to say, without WebGL in place, it just isn’t going to try. That’s all it does – act as a framework for WebGL. X3DOM, on the other hand, uses a “fallback” system. If you don’t have OpenGL2.0, it’ll try OpenGL1. If you don’t have that, but have a sufficiently advanced Flash player – it will try that. And it goes on to try a couple of other things I’ve not heard of, if none of the above works.

That implies that X3DOM will work in some places that Three.js will not. And sure enough – I tried one of the household beater laptops that doesn’t run OpenGL2.0 – and cannot show Three.js stuff – and the X3DOM content shows. One more point for X3DOM vs. Three.js!

Still, I’m going to stick to my modus operandum of being a “tool agnostic“. I’m going to learn about both, and keep an eye out for which situations would clearly call for one over the other. For example, thinking on my Virtual Silver Maple Keys demo – in my mind, that totally calls for three.js, because it’s a totally programmatical construct. It’s nice to have handles on everything that’s rendering, rather than having the handles part of the DOM. Quick and dirty array work, no muss no fuss.

Though, for something like the “scene” from a virtual world (twice) at the top of this post – I’d think, in general, that would be more of a candidate for using X3DOM. It isn’t structurally programmatic. It would be nice to have handles to the bits and pieces, through the DOM – it could interact with other things on the page. Quite unlike the maple keys.

Anyway, there’s a quick look at X3DOM vs. Three.js. Two very different tools, that both do something I’m very interested in – allow you to publish 3D content and virtual worlds on the open web, without a plugin.

转载于:https://my.oschina.net/u/3331511/blog/854112