Parity with gl-matrix?

[mattdesl]

Thinking about doing the same for gl-mat4. How close are we matching gl-matrix? Couple issues I've noticed:

• no GL_ARRAY_TYPE, only works on typed arrays
• no 'aliases' like idt or mul

Some other questions...

• any tests planned?
• it would be nice if we had some automated way of knowing when this is falling behind gl-matrix in terms of patches, features or bug fixes .. hmm

EDIT:

For the most part, the original gl-matrix files can be split pretty easily and automatically with regexes.. maybe worth considering.

[hughsk]

Thanks for getting gl-mat4 up! Looks good :)

Is GL_ARRAY_TYPE important? It's used solely for creating arrays, so you can still use the rest of the methods on vanilla arrays. Having a shared constant is also a little irky for modules, so not sure on the best way to approach it.

Aliases are easy to add, and I'm happy for them to be in there :)

Tests would be great! Yeah, wondering if we could automate the generation of these modules, and extract the existing tests too. At that point we could even try testing them against the gl-matrix repo tests to see if we're falling behind.

[mattdesl]

Shared constants are tricky since anything could change them... But it would still be useful to have the type check in create(), clone() etc so it works the same in older browsers.

Not sure how important it is that epsilon/random functions can be changed by the user.

[hughsk]

Ah yep, that makes sense! I'm 👍 for falling back to vanilla arrays on older browsers :)

Epsilon might need changing in some places. I've noticed things breaking in the past for being oversensitive. Random's just being used for vec{2,3,4}.random(), so not sure that's as important.

[backspaces]

Toji has converted to a more modular format which uses webpack for the workflow.

Wouldn't it be best for us to simply use his refactored code driectly? We could more easily keep up with releases.

Check out https://github.com/toji/gl-matrix/tree/master/src which has the master gl-matrix simply be several imports of the refactored source.

[mattdesl]

Some thoughts on that:

• the goals of this module (and others like gl-quat, gl-vec3) are to fully modularize the source down to each function
  • this allows it to be used in places like this where there is no need for a "matrix library" -- just some individual vector functions
• modularization down to each function also means that versioning becomes less problematic for front-end uses
  • for example, if gl-mat3 is bumped to 2.0.0 due to a change in a single function, bundlers (browserify/webpack) can still de-duplicate the rest of the functions since they are separate modules
• depending directly on gl-matrix/src/foobar is fragile; if Toji decides to change his build step (for e.g. use ES6) or re-factor internal sources, it could break this module and all other dependents using it
• the strict focus on modularization leads to some different design decisions for a library like this, see Add common file with GLMAT_ARRAY_TYPE, GLMAT_EPSILON and GLMAT_RANDOM gl-mat4#6
• gl-matrix does not have a clear scope or "end in sight" - see recent merges: [1], [2], [3]
  • I would rather encourage new functions to be added independently to npm, even if that means breaking feature parity with gl-matrix

/cc @hughsk @mikolalysenko

[rymohr]

@mattdesl those are all great points but I'm curious what @toji's thoughts are.

I'm just getting into webgl and it's confusing to have such similar and well maintained / well adopted packages as a newcomer. Plus, if I want to use gl-matrix for the SIMD support then I can't use most of the stackgl packages without having duplicate vec/mat libraries.

[toji]

I think @mattdesl points are very valid. It's valuable to adhere to the core goals of the libray: gl-matrix goes out of it's way to avoid introducing explicit classes for the various types, even when that would make some things easier (like SIMD). Similarly this library goes out of it's way to maintain strict modularity. I don't think introducing a formal dependency on my library serves that goal.

That said, if there's any sort of code or style tweaks that I could make to gl-matrix that would improve the workflow for migrating new features to this library I'm happy to discuss them!

[rymohr]

@toji for me the restructuring you've done eases any modularity concerns. Between webpack's dead code elimination and the ability to import individual components I don't have any issues there. 👍 for the restructuring though import vec2 from "gl-matrix/vec2" would be a great shift for v3 over import vec2 from "gl-matrix/src/gl-matrix/vec2".

I'm also a big fan of the simplified imports you get by having these components in a single package.

import { vec3, mat4 } from "gl-matrix";

Although they're not identical concerns, they are related. It's also nice to have a single github project to go to for issues related to vec/mat math.

Personally I'm just bummed I can't use some of the drop-in stackgl components without adding duplicate code. Especially when the libraries are functionally equivalent.

[mattdesl]

I'm just getting into webgl and it's confusing to have such similar and well maintained / well adopted packages as a newcomer.

I think more documentation in these repos would help, and clearer explanation about the philosophical differences to gl-matrix. It should be noted that this is currently a subset of gl-matrix, implementing the core functionality, and not much more. New features are already being added in their own modules.

Between webpack's dead code elimination and the ability to import individual components I don't have any issues there.

Unless I'm mistaken, you will still end up importing the entire vec2.js module even if you just need, say, vec2.add.

Personally I'm just bummed I can't use some of the drop-in stackgl components without adding duplicate code. Especially when the libraries are functionally equivalent.

Yes, it's a bummer. But it would be more of a bummer if all the current dependents on gl-* modules used gl-matrix. Instead of a few duplicate functions, you'd be dealing with hundreds of kilobytes of duplicate/dead code and potentially several copies of gl-matrix in your final bundle. 😆

One solution would be to refactor gl-matrix to use the same architecture as here to keep it modular. However, there's some obvious pitfalls:

• that is a huge overhaul and a lot of work that @toji and many of the gl-matrix users would not benefit from
• gl-matrix and gl-* have different philosophies in regard to new features and scope
• configuration is not easy to solve with modules Add common file with GLMAT_ARRAY_TYPE, GLMAT_EPSILON and GLMAT_RANDOM gl-mat4#6 (comment)

Even SIMD is a lot of extra code for (currently) little gain. Only works in FF nightly, only works on typed arrays, introduces a new avenue for bugs, and the extra performance may be negligible given your use case.

Ultimately I think it's OK to keep things separate for now. Once ES6 and tree-shaking becomes common place in Node/npm/browser, maybe it will be easier to merge the projects.

[backspaces]

Hopefully not OT, but have we considered es6 modules, both syntax and
module loaders via SPDY and HTTP/2?

I've used es6/JSPM for a recent webgl mooc by Ed Angel and loved it. I used
it both in dynamic mode (recompiles each page load, good for development)
and bundled (good for deployment, much faster).

The biggest problem is that there are multiple systems for module loading.
I used JSPM due to being standards oriented. It handled the latest glMatrix
with no problems as a "global" module type. But there are others like
webpack and babel/browserify and the es6-module-loader which JSPM builds
upon.

[mattdesl]

ES6 would be great for gl-matrix - a tool like rollup might produce a slimmer UMD build than webpack. Those using rollup would also get dead code elimination down to each function, as long as jsnext:main is specified in package.json.

However, gl-matrix would still have to pre-publish ES5 to npm for those not using rollup. This means Node/webpack/browserify users consuming the module via npm would not get the benefits of ES6. JSPM might also have the same issue - I'm not sure whether JSPM resolves jsnext:main or main.

Even with all this, there's no point in moving all the gl-vec2 files to a single ES6 file. I'm not aware of any tool that can output multiple ES5 files per function from a single ES6 source.