Description
So I've got a bit of free time on my hands and wanted to direct it at something I've been meaning to do for a while: Start the second iteration of the glMatrix library. This issue is to collect feedback on the proposed changes before we go crazy implementing them.
To be clear, the bump to a 2.0 library would indicate breaking of backwards compatibility, and thus several ill considered design decisions/flaws can be corrected without concern about breaking existing usage. The library in it's current form will likely stick around for a while longer and receive a few minor bug fixes, but new features would be 2.0 facing.
A few items that I feel must be part of the refactor:
- The current method of using array-like objects will stick around. The library will continue to create typed arrays by default, but can accept anything numerically indexable.
- As proposed in Proposal: always require a receiving object in every API #41, the semantics for input/output parameters should completely standardized. ALL functions would require an output object where applicable, no more implied change to the first/second param.
- Related to the previous item: Parameter names should be consistent. Names like "vec2" are confusing, since vec2 is also a "type" in gl-matrix. Preferred naming conventions for parameters are "a", "b", and "out", unless a different name would clarify the usage substantially.
- Standardize error handling. There are a couple of cases (matrix inversion, for example) that may have no valid solution. Currently the error handling is "return null and hope they notice." but that's not terribly well defined. Whatever method is used to handle errors, it needs to be well documented and consistent.
In addition there are some things that I would like to see
- I've long lamented the fact that the symantics for matrix multiplication are essentially "backwards" in gl-matrix, as noted by this Google code bug. I feel that any applicable operations should be changed so that the result is a more natural
out = a * b
instead of the currentout = b * a
. My only reservation here is that it may make porting code slightly more confusing. - When gl-matrix was first introduced TypedArrays were fairly new. Now even browsers without WebGL support them, so we should investigate ways to utilize them better. A specific example would be creating a "clone" function that passes the structure to copy into a
Float32Array
constructor.
Finally, there's a couple of items that have been proposed by the community but that I'm not sold on:
- This Google code bug suggests changing to a non-namespaced pattern, so that
mat4.multiply()
would bemat4Multiply()
. The reason given is that it would be faster (and it would be, if only a little!) but I'm not sure if I like the idea or not. - I've heard a couple of suggestions that along with requiring an output parameter on all operations we also introduce a set of functions that explicitly alter the first param, most likely named
___Self
. a.k.a:vec3.translateSelf(a, [1, 2, 3]);
would altera
. This would allow us to retain some current functionality and may even be faster is some cases, but the API is pretty large as-is, and I'm a little reluctant to clutter it further. - Stop returning the output parameter. This would (theoretically) be faster, but would eliminate the ability to nest functions.
I'm sure there's other items I can add to this list, but that's what I've got off the top of my head. More feedback is appreciated!