Re: Matrix4x4 proposal

On Tue, Jan 24, 2012 at 10:32 AM, Chris Marrin <cmarrin@apple.com> wrote:

>
> On Jan 24, 2012, at 6:58 AM, Timm Drevensek wrote:
>
> > Hallo
> >
> > We were discussing about your implementation proposal and there came up
> some question about the constructors and the underlying data type of a
> matrix class:
> > Related to the Khronos TypedArray specifications:
> http://www.khronos.org/registry/typedarray/specs/latest/
> >
> >
> > Would it be an idea to design the Matrix class in a way that:
> > - It works internally on ArrayBuffer as the underlying data container.
> > - The Matrix class itself derives from an ArrayBufferView like
> TypedArrays does.
> >
> >
> > Pros:
> > - Extendable by any existing libraries that are acting on TypedArrays
> (glMatrix) without any copy of data from and to the Matrix class (just
> provide a pointer to the underlying TypedArray container)
> > - Possibility for a performing way for creating arrays of matrices: By
> multiple views into a single container (see subarray() &
> constructor(buffer, byteOffset, length) @ TypedArray spec)
> > - Same interfaces for 32 and 64 bit Matrices
> > - No overhead for copy to the GL context
> >
> >
> > Cons:
> > - If you act on a ArrayBufferView you cannot create a 3x3 matrix "view"
> into a container, holding a 4x4 matrix (like subarray() of TypedArrays) due
> the offset after each row break.
> > For work around this issue, the Matrix could act on an extended 2
> dimensional ArrayBufferView...with holds information on size and offset for
> the 2. dimension...or a construct like the step_iterator, available in the
> boost gil library: (see
> http://stlab.adobe.com/gil/html/gildesignguide.html#StepIteratorDG)
>
> I don't think the overhead of copying a matrix into a Float32Array is
> significant, compared with the rest of the overhead involved. So I think it
> would be better to avoid the internal dependency on Typed Arrays and stick
> with the current functions to create and copy into them.
>

I'm curious what the need is for these Matrix classes. It seems to me the
only need is speed. Otherwise just use JavaScript. If the need is speed
then the design should do what is needed for speed, not decide "well this
is slower but I think it's fast enough". It's never fast enough.

I don't see what the downside is for basing them on ArrayBufferView and it
would let you use them for skinning characters without having to manually
upload 15-70 matrices per character per frame.

Consider.

  // at init time
  var boneArrayLocation = gl.getUniformLocation("u_bones");
  var boneArray = new Float32Array(numBones * 16);
  var boneMatrices = [];
  for (var ii = 0; ii < numBones; ++ii) {
     boneMatrices.push(new Matrix4x4(boneArray, ii * 16));
  }

  // at render time
  gl.uniformMatrix4fv(boneArrayLocation, false, boneArray);

vs non ArrayViewBased

  // at init time
  var boneLocation = [];
  var boneMatrices = [];
  for (var ii = 0; ii < numBones; ++ii) {
     boneMatrices.push(new Matrix4x4());
     boneLocations.push(gl.getUniformLocation(program, "u_bones[" + ii +
"]"));
  }

  // at render time
  for (var ii = 0; ii < mumBones; ++ii) {
     gl.uniformMatrix4fv(boneLocations[ii], false, boneMatrices[ii]);
  }


>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>
>