Repository: three.js
Issue: Proposal: Making flattened math classes that operate directly on views the default
Labels: Suggestion

##### Description of the problem

Clara.io has been struggling with the non-memory efficient Three.JS math classes for four years now.  Basically Three.JS math classes use object members to represent their data, e.g.:

```
THREE.Vector3 = function( x, y, z ) {
  this.x = x;
  this.y = y;
  this.z = z;
}
```

This pattern above leads to a lot of inefficiencies.  It is an object and it is an editable object.  It has a large overhead per object in terms of allocation time and extra memory usage because it is an editable object.  There are also costs to copy from a BufferGeometry array to a Vector3 and vice versa.  Also there are costs to flatten these arrays when using them as uniforms.

As we are looking to speed up Clara.io, I think we need to move away from object-based math classes and instead make the hard switch to math classes that are based around internal arrays.  This would be the primary representation of the Three.JS math types, although we could still emulate the object-based design we have by building on top of these.  Thus I want to see this design being the primary design for all of Three.JS math:

```
Vector3.set( array, x, y, z ) {
  array[0]=x;
  array[1]=y;
  array[2]=z;
}
Vector3.add( target, lhs, rhs ) {
  target[0]=lhs[0]+rhs[0];
  target[1]=lhs[1]+rhs[1]
  target[2]=lhs[2]+rhs[2]
}
```

I think the above pattern is the only way that Clara.io can achieve the speed it needs.

Important point: I was talking to one of the JavaScript spec designers and he said that we should use large arraybuffer allocations and then try to use views for each individual math element in a large array (e.g. var usernameView = new Float32Array(buffer, 4, 16) ).  He said that views were incredibly cheap as now you do not even pay an array allocation cost per element.

I think we could keep around the Vector3 object (as opposed to the new functional interface), but it could be built by creating a BufferArray (or alternatively initialized by a passed in view) and remembering it, and then using all of the pure array buffer functions I am advocating as the primary interface.  It could have accessors for x, y, and z that map onto the BufferArray.  This would give us backwards compatibility.

But going forward it would likely be best to nearly always use the versions of the math classes that can operate directly on a preallocated array.  This design would be ultra fast -- no allocations for the most part, and ultra cheap and easy conversions to uniforms and BufferGeometry.attribute

I think this is necessary for Clara.io to move to the next level and I think Three.JS wants to get there as well.  We, ThreeJS, have been moving to this solution slowly but we've never made the full break to transform the primary math-objects.  I think it is time to do this.

/ping  @WestLangley 
##### Three.js version
- [x] Dev
- [ ] r75
- [ ] ...
##### Browser
- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer
##### OS
- [x] All of them
- [ ] Windows
- [ ] Linux
- [ ] Android
- [ ] IOS
##### Hardware Requirements (graphics card, VR Device, ...)