github uses Three.js

[gero3]

There is a new blogpost from github where three.js gets used to demo stl files on all repositories.

https://github.com/blog/1465-stl-file-viewing

[mrdoob]

Recursion!

[bhouston]

With Three.js's stl loaders and renderers, it mustn't have been much work for them. :-)

[gero3]

They edited the stlloader at least a bit. I'm not sure what yet.

[mrdoob]

It would be pretty handy if they did the same for OBJ, DAE, etc :) We need more loaders! 3DS, DXF, VRML, ...

[erossignon]

It would be even nicer if they did implement support for 3D CAD Format such as STEP IGES or OpenCASCADE Brep using node-occ

[gero3]

It seems like they did some interesting changes(not really sure if they started from scratch or not):

• They used jquery to do Ajax requests
• They download the content as string instead of arraybuffer.
• They have a special binaryreader for the conversion
• They have always calculate the normal

[mrdoob]

• They download the content as string instead of arraybuffer.
• They have a special binaryreader for the conversion

That's cool. Currently the editor can't load STL files because of that. All the other loaders use string but STLLoader (and PLYLoader) relies on arraybuffer xhr. Maybe it would be better using their approach.

[mrdoob]

@skalnik are you guys planning open sourcing or upstreaming the loader?

[sshirokov]

Sure, I can clean it up and submit a patch.

[mrdoob]

@sshirokov Sweet!

FYI, @gero3 managed to to rescue some of the bits you guys have implemented: https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/STLLoader.js

[gero3]

@sshirokov

Do you mind if I ask why something is implemented like it is in github implementation??

[sshirokov]

Sure. What's up?

[gero3]

This piece of code:

I understand that it creates new vectors but it could be a lot smaller.

    normal = (function(func, args, ctor) {
      ctor.prototype = func.prototype;
      var child = new ctor, result = func.apply(child, args);
      return Object(result) === result ? result : child;
    })(THREE.Vector3, readFloat3(), function(){});
    for (_j = 1; _j <= 3; _j++) {
      geometry.vertices.push((function(func, args, ctor) {
        ctor.prototype = func.prototype;
        var child = new ctor, result = func.apply(child, args);
        return Object(result) === result ? result : child;
      })(THREE.Vector3, readFloat3(), function(){}));
    }

[sshirokov]

Sorry, the original code is written in CoffeeScript, so that's the compiled result from the asset pipeline. That section looks more like this originally

normal = new THREE.Vector3 readFloat3()...
for [1..3]
   geometry.vertices.push new THREE.Vector3 readFloat3()...

Which is a lot nicer on the eyes. I can port the code back over to more idiomatic JS, or include both the .coffee and .js versions. Though, I think pure JS would be ideal since the rest of Three.js is not a Coffee project at all.

[sshirokov]

Here's the original loader file in full in the original Coffee: stlloader.coffee

It's basically a port of Three.js's examples/js/loaders/STLLoader.js into Coffee with a few tweaks.

Let me know if any parts are unclear, of if you'd still like me to do the pure-JS port. You seem to be off to a pretty solid start.

Highlights

• The parseFloat() wrappers in the ASCII parser that prevent the mathematics from suddenly becoming string additions during translation.
• The normal recalculation is borderline required for trustworthy normals. A large portion of STLs in "the wild" have a normal defined as <0,0,0> and this largely okay according to the de-facto format.
• The binary/ASCII test is done using the binary spec instead of the ASCII spec to be more robust.
• Loading is done with jQuery instead of raw XHR, which was done for consistency, but also forced the use of a string -> binary reader instead of typed arrays.
• A bounding box is also computed at load time.

[mrdoob]

@sshirokov Btw, as a side note... I think you guys should enable antialias :)

new THREE.WebGLRenderer( { antialias: true } )

[gero3]

@sshirokov

I think I have everything now. The only things left is to remove some of the logic that the coffeescript compiler added. And then it seems we'll have a decent STLLoader. There are some additional notes we have to pay attention on.

A few notes

• I think it is best that jquery will never be necessary for three.js support. But the change from arraybuffer to string is a great one, so we'll have broader support.
• I think it is best to keep the normals from the file in (the maybe special) case that normals have been adjusted though their tool chain. It is easy enough to calculate the normals afterwards with geometry.computeFaceNormals(), geometry.computeVertexNormals().
• Coffeescript is indeed something that won't be added to the library. It would only make maintaining performance a bigger problem.

These are of course only my opinions.

PS: The changes I did are some what documented in the commits of following repository => https://github.com/gero3/threejs_STLLoader