Color3.fromFull(r, g, b)

Feature Requests Engine Features
#21

I really like the idea of Color3.rgb, it’s exactly what it says it is. Same with hex and whatnot.

The idea of making the code detect if the values are larger than 1, and then switching to 255 mode is one of the most evil things anybody could ever do to an API.

5 Likes
#22

Especially since it would break having 1/255

2 Likes
#23

Color3.from24Bit(r255,g255,b255) would work the best.
Or you know, just localize it at the top of your script along with everything else

local c24 do
    local color3new=Color3.new
    function c24(r,g,b)
        return color3new(r/255,g/255,b/255)
    end
end
1 Like
#24

Yeah, Color3.rgb, Color3.hex, and Color3.hsl are all excellent choices for names. I’m all for the three of them.

from24Bit is longer than .rgb. We’d reap the most benefits from just Color3.rgb().

“Let’s defeat boilerplate code with more boilerplate code!” #GreatestIdeaOf2016 /sarcasm

1 Like
#25

Color3 should be able to do most of the things vector3s do. Multiplication of two color3, multiplication of a color3 and a scalar, division of a color3 by a scalar, adding two color3, subtracting two color3, normalization of a color3, possibly even the dot and cross of two color3. Obviously the parts where vector3 interface with cframe would be skipped.

2 Likes
Color3 values should support math operations
#26

I got more and more confused about it being HSV or HSL…
I just googled… THEY ARE ACTUALLY 2 DIFFERENT THINGS???

mind blown

1 Like
#27

I prefer a third model, HSI (Hue/Saturation/Intensity) :stuck_out_tongue:

#28

You’re serious… that’s also a thing…

[size=10]I’m out, gonna stick with RGB. Maybe HSL if I want brightness stuff.[/size]

1 Like
#29

Oh god yes

#30

I don’t agree, that’s not the purpose of these objects.

You should just use Vector3s for this, and then convert them to Color3s whenever you want to display them.

1 Like
Color3 values should support math operations
#31

Color3.hsv and Color3.hex are fine since they’re pretty much in the same ballpark as Color3.rgb, but if you guys want to debate another feature (Color3 math), create a linked topic for it pls

2 Likes
#33

ಠ_ಠ

I created one for you: Color3 values should support math operations

2 Likes
#34

What would be the problem with just treating it like a 255 if any of the values are >1 and treating it like a unit color if all the values are <=1? And also support for hex code…?

#35

How will it differentiate between Color3.new(1,1,1) (0-1 scale) and Color3.new(1,1,1) (0-255 scale)?

#36

Don’t cover for it because no human being can differentiate between C3(1, 1, 1) and C3(2, 2, 2) or C3(0, 0, 0)? I guess if you were lerping mathematically it’d be a problem.

#37

One other idea, I don’t know if this has been suggested, but there could be a Color3.SetMode(Enum.Color3Mode)

with enums

Mode255
Mode01
ModeHex

or somesuch. Obviously bad names are obviously bad.

#38

It would also be a problem when people, who had never used Color3s up until the update, were under the false assumption that Color3.new() was used exclusively with integers from 0-255 and didn’t know they could use decimal values from 0-1, tried to use C3(1,1,1) on a 0-255 scale and couldn’t figure out why their particle was appearing white instead of black. That’s a weird gotcha that isn’t really good design.

2 Likes
#39

I think they should just leave Color3.new be and instead add additional functions for different representations, modifying Color3.new like that sounds like a way too convoluted solution.

#40

Bringing this in from the other thread since this kind of discussion is more appropriate here:

I select colors in terms of 0-255 because that’s what every graphic design program uses – even the properties window. If I use the color picker to find a good color for a specific button and then I want to create that button through a script, I now have to type Color3.new(r/255, g/255, b/255) since the properties window gave me a value in terms of 0-255. Or say I design an interface in an program designed specifically for that purpose (not because ROBLOX is necessarily bad for this, but because these kinds of programs have years of work specifically dedicated to enabling me to do what I’m trying to do). I then want to rebuild it in ROBLOX once I finalize it in the other software, and now I have to convert every single color from terms of 0-255 to 0-1.

It doesn’t matter how screwed up and illogical it is to use colors in terms of 0-255. If I’m manually initializing a Color3 value in a script, it’s because I know what color I want in there. Where did I get that color from? Somewhere that represents colors in terms of 0-255, hex, or hsv (most likely 0-255). Front-end wise, what makes no sense is to use 0-1 for choosing something’s color when the color you have is always going to be in a format other than that. We should be able to define colors with the formats they typically come in without having to do boilerplate calculations to convert them to a form irrelevant to the end-user.

Color3 values should support math operations
#41

What I’m saying is that it’s sort of silly to manually initialize a Color3 from a script. Generally speaking, it’s often a good idea to separate data from logic.

3 Likes