The following types will be used by ModelIO bindings
* Fix delta to be double
* Rename Simd-compatible matrices and vectors to match our final naming.
This also means removing the new Vector2 and Vector4 variants (but not
Vector3).
This also requires implementing the corresponding matrix (NMatrix4x3).
Fixes this xtro issue:
> !unknown-simd-type-in-signature! OpenTK.Matrix3 AVFoundation.AVCameraCalibrationData::get_GetIntrinsicMatrix(): the native signature has a simd type (matrix_float3x3), while the corresponding managed method is using an incorrect (non-simd) type.
* Rename them to be OpenTK.NMatrix# (instead of Simd.MatrixFloat#x#).
* Remove the Vector2 and Vector4 variants, we'll use the OpenTK types instead (but we'll keep the NVector3 variant, since it's not identical to the OpenTK version).
* Update the API to match their OpenTK counterparts better:
* NMatrix2 and NMatrix3 have a 0-based R#C# scheme for their fields.
* NMatrix4 has a 1-based M## scheme for its fields (i.e. no change).
* Implement Simd vector types (VectorFloat2/3/4/VectorInt4).
* [ARKit/Vision] Use the new simd vector types instead of the OpenTK versions.
* [ModelIO] Use the new simd vectors in new API (MDLVoxelIndexExtent2).
This way we won't have to create a MDLVoxelIndexExtent3 in the future.
* [SpriteKit] Use the new simd vectors in new API.
The OpenTK matrices (Matrix2/3/4) has a different memory layout than Apple's
matrix_float2x2/matrix_float3x3/matrix_float4x4 matrices: the OpenTK versions
are row-major, while Apple's versions are column-major.
This means that when blitting memory from one to the other, the matrix will
appear to have been transposed.
See bug #[58599][2] for an example.
Unfortunately we've already bound several API with Apple's matrix_floatXxX
matrices using OpenTK's matrices, and although they're bound wrong, and the
matrices appear transposed on input/output, we can't change the behavior
because we have to maintain compatibility.
This means we have to introduce new API, and then also just define new matrix
types with the right memory layout (column-major). Additionally, in the future
we might be able to mark these matrices as Simd-matrixes, so that the JIT/AOT
compiler can generate the correct alignment for them, avoiding having to
define a native conversion method (using the [MarshalDirective] hack).
The matrices have been designed to match API-wise the matrices in the
System.Numerics.Vectors namespace [1], but for the moment with only a few
basic operations implemented (Determinant/Transpose/Multiply) defined (we can
always add more later if we want to).
In addition explicit conversion operators to and from the corresponding
OpenTK.MatrixX are implemented, which means any operation defined in the
OpenTK matrices can be used by converting back and forth.
[1]: https://msdn.microsoft.com/en-us/library/system.numerics.matrix4x4(v=vs.111).aspx
[2]: https://bugzilla.xamarin.com/show_bug.cgi?id=58599
Alex Soto
Rolf Bjarne Kvinge