Color3.fromFull(r, g, b)

Feature Requests Engine Features
#1

Constructing Color3 variables is a mess. Every single piece of image editing / graphic design software I use uses a scale of 0-255 for r, g, and b. Even in the Studio properties window this format is used. When we get into the script editor though, all hell breaks loose and the convention we’re used to everywhere else in graphic design goes out the window – in ROBLOX code, color values go from 0-1 instead of 0-255.

Why? Because it’s easier to store internally that way? It’s fine if it’s stored that way, but RBX.Lua is a front-end interface for ROBLOX developers. All exposing 0-1 to us does is force us to use boilerplate code where we divide each number in Color3.new() by 255. Seemingly randomly using 0-1 instead of the graphic design convention of 0-255, which is used everywhere except in RBX.Lua – including the properties window, is bad. I don’t want to have to append /255 to every value I put into Color3.new(), and I shouldn’t have to waste time converting back and forth between the script editor and the properties window / image editing programs.

We’re obviously past the point of changing Color3.new()'s arguments, but what we can do is add a different constructor. Color3.fromFull(r,g,b), Color3.from24Bit(r,g,b), etc – something like that where I can use Color3.fromFull(123, 52, 254) without having to add /255 to each number.

Edit: Color3.rgb(r, g, b) sounds like a much better alternative than Color3.fromFull. Color3.hsl & Color3.hex would also be good counterparts to accompany Color3.rgb should it be implemented.

17 Likes
#2

Whenever I write a wrapper for this I find that I can only justify calling it if it has a really short name. Typing /255 is really easy, so the function has to be even easier. I’ve always used .new2 but I don’t like the sound of that for an official API. fromFull is much harder than /255. Not sure what a good name would be…

1 Like
#3

What about Frame.BackgroundColor3 = ColorUnit.new(0.5,0.8,0.2) and it just converts it to Color3
Color3 is Vector3
While Unit is a Vector3 but each number is 0-1

1 Like
#4

Yeah, it could be shorter – I’m not sure what the best naming would be. Either way, fromFull isn’t harder to type than three /255s. Color3.new(123/255, 52/255, 254/255) is 36 characters, while Color3.fromFull(123, 52, 254) is only 29. Even if one of the values is 255 or 0 (can be shorthanded to 1 and 0), fromFull is still less characters.

The problem is having to convert 0-255 to 0-1 either mentally (waste of time since Color3.new is the only one that uses 0-1) or by boilerplate /255s. This doesn’t help because you’re still having to convert 0-255 (standard) to 0-1 (only used in RBX.Lua).

#5

I always just… C3 = function (r,g,b) return Color3.new(r/255,g/255,b/255) end

Perhaps Color3.rgb or Color3.new(r,g,b,bool is256Value) ?

6 Likes
#6

Those are the constructors I’ve heard a lot of requests for:

  • Color3.rgb(R,G,B)
    Range from 0-255
  • Color3.hex(“#defead”)
  • Color3.hsl(H,S,L)
    Range H would either be 0-360 or the equivalent in radians
    Range S and L would be 0-1 since nobody uses 255 for that
    It’s L right? I forgot if it’s HSL or HSV. Hue, Saturation and Lighting?)

Using lowercase names since that seems to be how it is for constructor table stuff.
(Only exceptions are CFrame.Angles, Instance.Lock and Instance.Unlock)
(Not that the latter 2 even matter)
(Angles is actually an alias for CFrame.fromEulerAnglesXYZ, so eh)

3 Likes
#7

It’s interesting how years ago, ROBLOX actually supported values ranging from 0-255 in scripts.

Here’s a snippet from Ice128’s minigames; ~6 or 7 years ago

I would want this back, but there has to have been a valid reason to remove it. However I am not quite sure what that would be.

1 Like
#8

He might’ve also just derped or use high values for special effects?

#9

Nah, I used to edit this game and play around with it back in the day. It worked as expected.

#10

These would make a lot of sense; self explanatory and short. :+1: from me

#11

See these feature requests too:

#12

Is this more desirable than Color3.new(0xdefead)?

#13

No. I think Color.new() should just accept HEX and RGB out of the box, without bloating the API

1 Like
#14

This may have weird consequences though. When I say Color3.new(0x000001), it will become Color3.new(1) and thus Color3.new(1,0,0), meaning bright red while I wanted black with a very very faint tint of blue.

Color3.new will just see the input as a number variable, it can’t distinguish between it being hexadecimal or decimal because the difference is only there before parsing.

#15

Is it possible for .new to accept rgb? How do you see that?

#16

It would see the input as one number instead of three and distinguish that way

#17

True but this would be a behaviour change, so it could modify the behaviour of existing code if people relied on the fact it appends 0 for arguments not given. I have no clue if people do that, so I’m not going to assume they don’t.

#18

Yeah, I don’t see a case where people would be doing that. Even if they did it wouldn’t break their games and the fix would be trivial.

#19

I think Color3.hex(0xRRGGBB) and Color3.hex("RRGGBB") would be nice to have.

Other than that I’d either like:

  • Color3.new(R, G, B, Max=1), where the result is (R/Max, G/Max, B/Max)
  • Color3.rgb(R, G, B), where the result is (R/255, G/255, B/255)
  • Color3.new(R, G, B, normalize=false), where the result is (R/255, G/255, B/255) if normalize is true and (R, G, B) otherwise like @TraeMan7 mentions.
2 Likes
#20

I actually use Color3.new(1) in some cases, although it’s junky SB code for special effects:

(That’s not one that uses Color3.new(1) but eh)

1 Like