This feels like gatekeeping of a problem that doesn’t exist.
Everybody who has requested this has gone on to achieve what they needed, by writing a wrapper. The only difference is we all lost time writing the same code rather than it being built-in. If multiplying a color by 0.5 to get it “half as bright” was a use case & problem, people would still run into this with their wrappers.
Mathematical operators are technically incorrect on unit vectors too, but developers still survive because… people working with math typically understand some math!
IMO the built in solution should push you in the right direction though. Why not provide :Darker(alpha) / :Lighter(alpha) which are actually what people wanted in the first place and do the right thing rather than providing a math construct which makes you do more work for a worse result?
Going to put in my two cents, I’d be for a :Lighter and :Darker method. However, I think that if you were to implement Darker and Lighter methods, we would also need :Saturate and :Desaturate, and possibly :HueShift methods for consistency since (in my experience anyway), I’ve been in both situations (where I’ve needed to de/saturate, and where I need to darken/brighten colours).
To only have :Dark/Lighten and not desaturate/saturate would still be an inconvenience, and then you also run into the issue of needing a custom Saturate/Desaturate func but not a Dark/Lighten method which is just inconsistent, not implementing both would feel like a partial solution. I also think that implementing Dark/Lighten would give the impression that only modifying one channel feels like an arbitrary solution.
However that doesn’t take away from the fact that I do think that math operations should also be implemented, nearly every other data type that houses numbers in some form have it (Vector3, Vector2, Vector3Int16, Vector2Int16, UDim2, UDim, CFrame…, you literally work on the engine so you know this so I’m not sure why I’m listing). To not have Color3 math operations just feels like a feature that is so obvious and should be there for consistency.
To be frank I don’t really think most devs that want a darker colour really take into account the specifics, just would want the colour to be more or less saturated and they can change the number it’s multiplied by if need be. That’s just my opinion tho.
Sure. Fancy methods to darken and lighten a color with the correct gamma adjustment would be nice for simple use cases.
However, Roblox should not spend 4 years designing this magical API that satisfies everyone before doing the bare minimum for a simple datatype that should just be an extension of Vector3 behind the scenes anyway.
Currently, to write your own algorithms involving color transformations or moving between color spaces, you’re better off just using a Vector3 as an intermediary, or working with the RGB components as separate variables and duplicating math across all of them manually. Like a caveman.
If I recall, Vector3s have some optimization behind the scenes for mathematical operations. Where does that leave this classic gist standing in terms of performance? CIELUV Interpolator
I don’t see how it’d bloat API, wouldn’t shader language allow color multiplication and addition and things (tho its done via vec3, vec4, you get it). I have no idea why can’t the same be done to color. I had to multiply color few times and it’s VERY painstaking process, you’d have to extract colorvalues from one color and another color and reconstruct this Color3 value.
All the other stuff about :Lighter/Darker and :HueShift would be cool also, but these above are my main pain points. I shouldn’t have to create a wrapper just to add two colors together.
Having math operations on Color3 would be extremely good and much faster than trying to treat Vector3 values as a Color value to do math on, and then convert said Vector3 value back into a Color3 value.
If Color3 could handle all math operations that Vector3 could do, it’d be perfect:
Color:Dot(Color)
Color:Cross(Color)
Color *= 0.5
etc
Bumping. Honestly surprised this isn’t a thing. You can add/subtract/divide/multiply Vector3s, both Vector3s and Color3s are compatible with TweenService, so it’s very odd that you cannot do math operations with Color3 values.
