Color3.fromFull(r, g, b)

[NWSpacek]

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.

[einsteinK]

@EchoReaper

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

@Quenty

See these feature requests too:

• Trello
• Trello

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

mind blown

[buildthomas]

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

[einsteinK]

@buildthomas

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

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]

[Partixel]

@NWSpacek

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.

Oh god yes

[buildthomas]

@NWSpacek

Color3 should be able to do most of the things vector3s do

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.

[EchoReaper]

@buildthomas

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.

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

[EchoReaper]

@Partixel

If Color3.new accepted Vector3s and vise versa I would be fine with using Vector3s for that, but they don’t which makes it a pain in the arse

ಠ_ಠ

@EchoReaper

if you guys want to debate another feature (Color3 math), create a linked topic for it pls

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

[Davidii]

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…?

[EchoReaper]

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

[Davidii]

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.

[Davidii]

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.

[EchoReaper]

@Davidii

I guess if you were lerping mathematically it’d be a problem.

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.

[buildthomas]

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.

[EchoReaper]

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

@0xBAADF00D

Not sure. I was just mentioning that 0-255 is really pretty meaningless. You shouldn’t be choosing colors that way anyway. I would use a Color3Value myself; the property editor in Studio will take RRGGBB, #RRGGBB, or RRR, GGG, BBB.

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.

[0xBAADF00D]

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.

[Fractality_alt]

Here’s my two cents-

• Color3.rgb(0xFFFFFF) takes one integer, already discussed
• Color3.rgb(255, 255, 255) takes three integers, already discussed.
• Color3.hsv(180, 1, 1) is already on the Trello board.
• Color3.hsl(180, 1, 1) because apparently people like color spaces.
• color3AB = color3A:lerp(color3B, 0.5) interpolates between two colors in HSV space.
• color3A[*/^+-]color3B shouldn’t happen because that’s operator overload abuse.
• Tacking more functionality onto Color3.new is also a bad idea.
• If you have a super obscure use case (e.g. working with an RGB scale other than 1.0 or 255), do your own division.

[Tomarty]

I think it’s pretty cool that roblox transcends color depth. In 80 years we’ll want another constructor for inputting colors from 0-65535

[AxisAngle (AxisAngles)]

YES! A reasonable person with whom I agree!

[EchoReaper]

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.

YES! A reasonable person with whom I agree!

But in Phantom Forces you manually initialize health settings & spring values (char module), camera offset & bounds (camera module), and shoulder offsets (replication module)? Those are all modules written by you. How are initializing those variables in the script any different from initializing color settings?

@0xBAADF00D ROBLOX employees declare constants in all of the corescripts i.e.

There’s nothing wrong with declaring constants in scripts. I’m pretty sure your outlook on how constants should be defined is an opinion opposed to a definitive “people are doing this wrong” – I could say that spamming ObjectValues inside objects for settings is ugly and defining them in code is 100x better. It all boils down to opinion. Even outside of ROBLOX, languages like C++ and Java allow for the declaration of constants/final variables, and I’d be hard-pressed to believe either declaring Color3 settings is different from declaring constants or that both declaring constants in C++ and Color3 settings on ROBLOX are nonsensical.