Raw input/display support in Color3 properties and pickers

Feature Requests Studio Features
#1

The default value for Color3 is in raw (0 - 1), yet all of the color-related features in Studio don’t support it and instead use the should-be-deprecated 8-bit system. This can really slow down my workflow, and also encourages use of inconsistent color formats within the same game.

Here are examples of both:

I often use Color3:lerp() to smooth color transitions between areas. However, this is really slow to do as :lerp returns a Color3 in the raw format, not in the 8-bit (0 - 255) format that Studio exclusively loses, so I need to manually convert each returned value again back into the 8-bit format. The shortest way for me has been to just run this: print(Color.r * 255, Color.g * 255, Color.b * 255) for every color value (usually at least three). It’s so slow and unwieldy though, why can’t I just copy the color in the raw format myself? Not to mention that it’d be much easier in general to just use the raw format in the properties tab so I can potentially process the lerping with my own brain in some cases.

I’m a UI designer and a scripter, and my workflow is generally to find a UI style and make it all in the editor, then script everything. But the problem is that the editor exclusively uses a completely different color value than scripts, which means I have to convert the colors, and when converting between them I either:

  1. Use Color3.fromRGB(), wasting performance (unnoticeably, though) and splitting the colors in my scripts between raw and 8-bit values (raw for quickly constructed colors such as white and black made in the script, 8-bit for colors taken from my UI style, plus by default everything works in raw anyway).
  2. Spend time converting the 8-bit colors to raw colors, and additionally deal with the insane decimals that will result

I consider the first to be the lesser evil and the most ergonomic, so that’s what I use. This situation can be likened to using both the metric and (whatever the American measurement system is called) measurement systems on the same project. Fun fact: A NASA project once failed solely because of incorrect conversions between the two.

Ideally we would be able to set our entire color mode in Studio to whichever one we prefer – this would fix both of the problems I mentioned. I’d personally use raw, as it has the most synergy with scripting. Regardless of which mode we have enabled, values entered in either format should be automatically converted to the correct mode (the difference between them is simple: raw values are decimals 0 - 1, 8-bit values are integers 0 - 255).

Fixing this issue will solve the current inconsistency (and confusion! especially for beginner scripters trying to construct Color3s with the default constructor with 8-bit values) in development and speed up and make-sense-of the entire color system.

3 Likes
#2

I don’t quite understand where the issue is exactly taking place. At what point in your workflow does this necessity of conversion stop you up so much? Or is this trying to read the color values to diagnose issues?

Using Color3.fromRGB() should be fine in all locations. I use this everywhere as it’s a system I’m more used to using. If you do this, I don’t immediately see where the necessity of reading float values in 0-255 format comes up.

Could you elaborate more on why exactly it’s so taxing to translate and where it’s happening?

2 Likes
#3

My main issues are with conversion time and consistency.

Consistency isn’t particularly important, it’s just good practice and keeping things simple. The default Color formats for parts and scripts should be the same, simple as that (and even if they aren’t you should AT LEAST be able to paste in the other format in properties).

Converting is an issue when you need to convert to the 0-255 format, as you need to go through all values one by one and multiply them by 255 instead of just copying and pasting the raw value. It’s a hassle. Both issues are things that never happen in other game engines.

I elaborated on why it is so slow in this quote (and why the entire process of converting could be somewhat skipped in some cases if it was in raw):

The shortest way for me has been to just run this: local Color = Color3.new(R, G, B) print(Color.r * 255, Color.g * 255, Color.b * 255) for every color value (usually at least three). It’s so slow and unwieldy though, why can’t I just copy the color in the raw format myself? Not to mention that it’d be much easier in general to just use the raw format in the properties tab so I can potentially process the lerping with my own brain in some cases.

Here’s an actual step by step walkthrough of this specific case:

  1. Lerp color between areas by running local A = Color3.fromRGB(R1, G1, B1) local B = Color3.fromRGB(R2, G2, B2) print(A:lerp(B, PERCENTAGE))
  2. Copy that output and paste into (and run) local Color = Color.new(PASTE_HERE) print(Color.r * 255, Color.g * 255, Color.b * 255) (could also put into above step but separated because that’s how I did it at the time)
  3. Copy that output and paste into properties tab
  4. Repeat for every PERCENTAGE (I did 3)
  5. Repeat this entire process again for each area transition in my game

Step 2. can be shortened a bit (as I said) so maybe this issue is not as bad but it is still there nonetheless. It is just adding another step to an already tedious and annoying process.

To sum it up, the root of the issue is that you can’t paste Raw values into the properties window. That extra step would be removed, and there won’t be any issues (or potential issues) and it’s just one less thing to think about for developers.