Matrix/Vector/Color conversation and utilities cleanup

Questions
1

Hello,
I am working on a technical application and there I often have to map some data from my data model to vectors, matrices and colors. I noticed that I often have to repeat pieces of code to map my data although there is already plenty of helper functions in the appropriate classes.
Sometimes I noticed there is even 2 helper function that do the exact same thing and I was wondering wether one of them is preferred and the other one should be marked as deprecated.

So here is my list of questions and suggestions. I am willing to contribute here if there is a consent how to move on.

  1. Colors: There is no way to convert a Color4 to a Color3, but there is two ways to convert Color3 to Color4:
  • Color4.FromColor3
  • Color3.toColor4
    Is there a preferred version? I know the first one as “NamedConstructor”. I think it is more verbose while the second one is shorter as you do not have to explicitly mention the Color3. I think I prefer the second one. Is there a reason to have two? I’d probably deprecate one of them and add a way to convert from Color4 to Color3.
  1. Vectors:
  • We use Vector2 and Vector3 a lot and there is no way to convert them. I’d love to have either Vector3.FromVector2 or Vector2.toVector3 and vice versa.
  • Sometimes I need to create a Vector where all elements are initialized to the same scalar, for example to pass it to the scaling vector of Matrix.Compose. What do you think about a Vector.FromScalar that initializes all elements with the same number?
  • Vector3 has transformCoordinates while Vector2 has transform
  1. Matrix:
  • I often need to create a Matrix that contains a translation that I already have as a Vector3. Currently, I need to pass myVector.x, myVector.y, myVector.z. What do you think about a Matrix.TranslationFromVector3 that accepts a Vector3, same for Vector2?
  • Recently I found Matrix.Compose and Matrix.ComposeToRef. What do you think about a Matrix.ComposeToArray that directly writes to a Float32Array?
  • In order to copy the contents of a vector to a Float32Array, there is Vector4.toArray. Matrix has copyToArray, but there is a second overload to Matrix.toArray that looks like it behaves the same as Vector.toArray. Is one or the other preferred? Should one be deprecated?
  • I often create a uniform scaling matrix but I need to pass my scaling factor 3 times to Matrix.Scaling. What do you think about a Matrix.UniformScaling(number)?
  • There is no Matrix.multiplyInPlace.

There are the ones that I found and sometimes miss. Are you aware of more things like this? What do you think about my thoughts?

Best regards,
Axel

2

Hey!

We are in a process to improve the vectors and colors library to make it less… fat :slight_smile:

The idea for now would be to add importable functions here:
Babylon.js/packages/dev/core/src/Maths/math.vector.functions.ts at master · BabylonJS/Babylon.js (github.com)

This way we can only get them if we need them and treeshake when not needed.

And thus we can consider having “static” only for now as the goal is to keep the classes themselves as untouched (or even start deprecating some duplicated functions)

Regarding all your ideas I like them all :slight_smile: Feel free to send a PR if you want to integrate some

1 Like
3

There is x% of people who do not use any of these methods, there y% who use the static version and there z% who use the instance version. Assuming x,y,z > 0%, removing methods guarantees to make some group worse off. Unless there is any other trade-off.

4

My point here is not to take anything away from anyone but agree on a preferred version so that for future additions to the API, only one version needs to be added. For example, I can add Vector3FromVector2 or Vector2ToVector3 or I can add both.

I created a PR that added most functions as suggested by @Deltakosh to math.vector.functions.ts as a base for discussion:

What is missing:

  • Matrix.multiplyInPlace: This one I cannot add to the mentioned utility file.

Also ComposeMatrixToArray is only a slightly changed a copy & paste from Matrix.ComposeToRef. The proper way would probably be to have only of these implementations.

What do you think? I am also fine with removing again any of them if they don’t feel ready.

Best regards,
Axel

1 Like