The Vector3 class currently has 5 constants (zero, one, xAxis, yAxis, zAxis), which help readability and performance for the programmer by inlining common unit directions.
However, we are still missing constant units for (1, 1, 0), (0, 1, 1) and (1, 0, 1).
These units are commonly used for “trimming” other vectors e.g. (Humanoid.MoveDirection * Vector3.new(1, 0, 1)).Magnitude, so it would be popularly useful if they were officially added.
The Proposal
Add Vector3.xyAxis, Vector3.yzAxis and Vector3.xzAxis constants to the Vector3 class.
Currently, we must either predefine these constants or add two units together (Vector3.xAxis + Vector3.zAxis), where the latter may perform worse if the compiler doesn’t fold it.
Discussion of the Color3 library, I think, is really beyond the scope of the apparent feature request. As has been pointed out, BrickColor effectively serves the purpose of ‘color constants’ anyways.
I do; and others probably should. It’s plainly more efficient to set a part’s BrickColor directly, as computing the nearest defined color to a RGB value is a nontrivial process.
Color is already a property of BrickColor data.
I can definitely see how this would be useful now. Although “Really Red”, “Lime Green”, and “Really Blue”, are equivalent to their respective RGB maximums, there are as of yet no BrickColors which correspond exactly to pure white, or pure black. Having to go through the BrickColor library to attain these simple quantities, is also about as inconvenient, as it is inconducive to promoting readability.
Do you think this would actually increase readability?
To me it would seem that Vector3.new(1, 0, 1) * foo is significantly more readable than Vector3.xzAxis * foo. With the former there’s some visual explanation to what you’re trying to accomplish which is lost with the proposed approach.
well, easier to put Vector3.xzAxis than Vector3.new(1,0,1).
constants aren’t for readability, are for ease, but theyre very readable.
Instead, you have to create a value and thats more to do and (slightly) less performant.
If you are making the performance argument then you should be assigning Vector3.new(1, 0, 1) to a variable anyway, which makes adding a predefined constant in the Vector3 class kinda moot.
I personally don’t feel too strongly about new constants being added to the Vector3 API given that CFrame objects similarly lack properties that are merely sums of other vectors like LookVector + RightVector, UpVector + LookVector, and so on.
The colors in that aren’t really solid colors. The brick color “black” is not truly black as its rgb is (27, 42, 53), as goes for its other colors like red or green. And there has never been a time in history where I have had to use “27, 42, 53” because it just makes no sense and would make more sense to me to use 0, 0, 0 via Color3.new (with no arguments ofc because no args = pure black). And I can just have that as a variable to act as a constant. I see no reason to use BrickColor still.
I cannot fathom what else xzAxis would be beside having the Axis x and z. It follows the same convention of xAxis, which are single-axis units.
Plus, we already create constants with names like VECTOR_XZ, since its faster than constructing. You also could argue about visual explanation loss for any other constant like math.pi over 3.141592.
Something like xzAxis can easily be typed out as Vector3.new(1, 0, 1), but for something like pi, I would have to search up the digits of pi and guess how many digits I would need to get full precision. Pi is also an extremely well-established constant in math, so math.pi does actually increase readability. Meanwhile, I don’t think I’ve ever seen a constant like xzAxis in math.
Benchmarking results will differ depending on the optimization level. --!optimize 2 seems to inline Vector3 constructs, which means their faster than subtraction in a live server, but slower in studio.
To me that’s another good reason to add these constants. Unify the performance gains so people don’t mistakenly make their code slower.
I outlined this in a previous reply, but the performance implications for a feature like this are negligible given that you’ll be assigning it to a variable if you at all are trying to min-max performance.