This would add a fourth property to the Color3 constructors called alpha. Basically it would allow changing the light/darkness of the color.
All current Color3 functions would add it like this:
Color3.fromRGB(255,255,255,0.5)
Color3.new(1,1,1,0.5)
This would add a fourth property to the Color3 constructors called alpha. Basically it would allow changing the light/darkness of the color.
All current Color3 functions would add it like this:
Color3.fromRGB(255,255,255,0.5)
Color3.new(1,1,1,0.5)
If you do indeed want a “brightness”, and not an actual alpha, there’s already a relatively easy way to accomplish that: You simply do a weighted blend of the color you’re working with with either white to lighten or black to darken:
function darken(color, percent)
return Color3.new(percent*color.R, percent*color.G, percent*color.B)
end
function lighten(color, percent)
return Color3.new(percent + (1-percent)*color.R, percent + (1-percent)*color.G, percent + (1-percent)*color.B)
end
Yes I’m fully aware of the ability to do this via functions, I use my own; but having this as an official feature would be even better.
I can think of many usage cases where I’d like this. In fact I would use this for something I just worked on yesterday.
If Color3 values had h, s, and v properties (not sure why they don’t when we have a HSV constructor), you’d be able to do
color = Color3.fromHSV(color.h, color.s, color.v + delta)
Value in HSV does exactly what you’re wanting it to do (control brightness/darkness). I think completing an existing API is a better bet than adding the new concept of alpha.
Edit: Posted feature requests here Add h,s,v properties to Color3 values
Edit2: Apparently you can do
local h,s,v = Color3.toHSV(color)
color = Color3.fromHSV(h,s,v + delta)
Just so you know, the a
in CSS’s rgba()
means alpha
- which is another word for transparency.
Basically, rgba(255,0,0,0,1)
means ‘full red, no transparency’ and rgba(255,0,0,0)
means ‘full red, full transparency’.
Honestly, I don’t see much need for making a color lighter/darker by a percentage to be built in; it’s not hard to do it yourself and it’s more of a utility function.
An RGBA type would be nice (Color4 probably), but considering that we already have Transparency for most objects which take Color3s, I think it would just be superfluous and confusing to add a whole new type.
I wouldn’t put it like that… it would be way better if Color3 had just had an alpha property from the start. Attaching alpha to the color (and ignoring it in the cases where you really don’t want it) is just generally the right way to do things, as has been proven by many APIs over time.
The problem is rather a backwards comparability one. It’s not really an option to change over from separate transparency properties now, and it would make the API really messy to have both.