VecN/Color array conversion support

[kpal81xd]

Motivation

When using Vectors/Colors it is very common to want to serialize and deserialize data to either be used for UI (in conjunction with observers) or to synchronise over a network

Overview

• Adds fromArray(offset: number = 0) methods on VecN and Color classes to allow setting from arrays
• Adds toArray(out: any[], offset: number = 0) methods to VecN and Color classes to for explicit conversion to array (avoids potential class fields being added from using Object.values

Testing

• Add unit tests

[Maksims]

I wander if it should be on set method or copy method. As copy - feels a bit more appropriate, as it copies from another thing. While set using array - feels weird, as Color or Vec - is not an array-like structure.

[marklundin]

This would be super helpful for the React lib

[kpal81xd]

I wander if it should be on set method or copy method. As copy - feels a bit more appropriate, as it copies from another thing. While set using array - feels weird, as Color or Vec - is not an array-like structure.

Copy implies that the target you are copying from is of the same type.

[kungfooman]

I understand the wish for #toArray, but not the update for #set, since that's just .set(...arr)

Edit: same goes for #fromArray, we have always argued against bloating the API when it is not necessary

[kpal81xd]

I understand the wish for #toArray, but not the update for #set, since that's just .set(...arr)

Edit: same goes for #fromArray, we have always argued against bloating the API when it is not necessary

It was mainly from typechecking standpoint as we can convert from type number[] whereas set(...arr) requires arr to be a tuple [number, number, ...]. Yes you can cast but the majority of the time you will be dealing with number[] over tuples. This can also get super annoying converting from an array multiple times and usually ends up just being added anyway as a helper.

[kungfooman]

So #fromArray accepts number[] as an argument, which implies that even vec3.fromArray([1]) is "valid" now (so we are ending up with {x: 1, y: undefined, z: undefined}). You just watered down type-checking.

[kpal81xd]

So #fromArray accepts number[] as an argument, which implies that even vec3.set([1]) is "valid" now (so we are ending up with {x: 1, y: undefined, z: undefined}). You just watered down type-checking.

That can easily be fixed by just added undefined defaults

[LeXXik]

Can we add an optional index to the to/from methods? I have similar methods, but I use it with large arrays and need to point to the values location.

[kpal81xd]

Can we add an optional index to the to/from methods? I have similar methods, but I use it with large arrays and need to point to the values location.

I can do it for fromArray but toArray just generates a new array

[mvaligursky]

Can we add an optional index to the to/from methods? I have similar methods, but I use it with large arrays and need to point to the values location.

Agreed, and for toArray I would also provide optional array = [] parameter, allowing writing to a user allocated array (using provided optional offset)

[marklundin]

@kpal81xd Is there something like ArrayLike<number> we can use here? @type number[] isn't happy with TypedArrays.

[mvaligursky]

@kpal81xd Is there something like ArrayLike<number> we can use here? @type number[] isn't happy with TypedArrays.

I used {number[]|ArrayBufferView} in few places.

[kungfooman]

The +1 version of Vec3 😅 Great work anyway, good job

[Maksims]

If array is provided into toArray, should it check if it can fit values in, to avoid array resizing within that function?

[kungfooman]

And this copypaste had to become Vec2

[mvaligursky]

If array is provided into toArray, should it check if it can fit values in, to avoid array resizing within that function?

I would not expect so, that's not worth the cost overhead. It's up to the user to make sure array is in the right size if they don't want resize.

[kungfooman]

If array is provided into toArray, should it check if it can fit values in, to avoid array resizing within that function?

Aren't we just reinventing an opinionated/non-configurable Array#splice?

What if we just did:

pc.Vec3.prototype[Symbol.iterator] = function *() {
  yield this.x;
  yield this.y;
  yield this.z;
}
a = new pc.Vec3(1, 2, 3);
b = new pc.Vec3(11, 22, 33);
c = new pc.Vec3(111, 222, 333);
[...a, ...b, ...c];
arr = [10, 20, 30, 40, 50, 60, 70, 80]
console.log(...arr);
// At pos 5, delete three add three from a at same place:
arr.splice(5, 3, ...a);
console.log(...arr);
// At pos 2, delete nothing, splice c into arr
arr.splice(2, 0, ...c);
console.log(...arr);

Outputs:

We also still can't do:

Array.from(a); // Should output: [1, 2, 3]

(we pretty much successfully added another PC specific idiosyncrasy again)