[On Hold] Important Notice if Using ColorCorrection.TintColor RGB Values Greater than 255

“Powering imagination”


Ahh, yes we all love the company that Powers Imagination as it says itself, but then just ruins everything that made our game look good with horrible updates :smiley:


Love this unnecessary update and the lack of transparency behind the reasoning of this change, truly powering imagination


Why was this needed, who recommended this change, and how will it change anything?? Stop doing things without communicating with developers which are the only reason your company is still alive.


There is literally no point of this update


Someone’s got to be doing this to deliberately sabotage the company at this point.


No, seriously. I don’t understand where the hell these seemingly arbitrary decisions are coming from.

Who the hell cares if the number goes above 255? Why does it even matter?


It honestly smells of Roblox being run by bean counters rather than engineers. Sorry if this offends anyone, but it really is hilariously stupid and there simply is no other word for it.

As an aside, I can’t wait for the next announcement, that Compatibility lighting will be removed, with a 1-week window to adjust our games :sick:


“We don’t think this is necessary moving forward.”


I’ll take your word that we can accomplish the same effect with Brightness/Contrast, but I’m not fully convinced it’s the same and I’ll need to experiment to see. If I recall correctly it just washes the colors out and looks pretty terrible.

This change feels unnecessary and it may seriously impact the lighting in Super Nostalgia Zone and Welcome to Roblox Building. Can we at least have some rationale for why this change is necessary?


Hey Developers,

Thanks so much for your feedback! We’re blown away by all the unique use cases you’ve presented to us on this feature. At this point, we are delaying this change indefinitely while we work with you to better understand how to move forward. We want to take a moment as well though to explain why we wanted to make this change.

We pushed for this change out of consistency. This value is presented as an RGB value similar to other color parameters. Despite this, it was inconsistent with these other precedents as it was allowed to exceed the 255 maximum. This change was to bring it in line with the other color parameters.

While we take a pause on this and reevaluate we would love to hear more use cases for this feature. If your experience uses ColorCorrection.TintColor outside of the normal range [0,255] we’d love to hear more detail on why!

Thanks again for your feedback!


my game uses this to make it look like it’s green


Thank you for the clear communication


In general, allowing for unclamped values lets us create effects like this easily, which has loads of use cases like non earth like weather, consumption effects and more.


Thank you for listening to us. I’m glad to see the feedback went somewhere with this.

As for use cases, I primarily use it to get a bright, glowing ambient without washing out other colors. If 255 is the limit, I cannot raise the value of a color, but rather, I have to lower the value of other colors. Being able to increase one or more above 255 into larger territories opens a lot of possibilities to make games brighter easily without having to tweak bloom, colorcorrection, and everything else to obtain the desired effect.

A good example would be making a bright, blue ambient. If you want to make just blue pop more and add sort of a “blue film” without washing out other colors, you can make the value something like 255,255,350. Another good example would be making surreal, trippy environments. Being able to manipulate the colors so efficiently is overall better, as it’s more functionality without needless complexity. In fact, I wouldn’t mind if this unclamped color was provided for other stuff as well, because it’s pretty helpful honestly.

General rule of thumb - If you have some extra functionality, don’t remove it solely due to consistency, especially if there’s people using it. The less restrictive things are when it comes to development, the better.


Post-processing effects are applied to the buffer before tonemapping is done. That’s how bloom can operate on brighter-than-white values. That means the framebuffer is still floating-point and can have values above 1.

Color3 is floating-point, there’s no reason to clamp it to 1 in many cases. (Roblox Studio displays it as 0-255 for easier editing.)

255 is by no means the maximum for any color space, 255 is simply the maximum of an 8-bit unsigned integer, which is how 24-bit color is implemented. There are image formats which support 12 or 16 bits per channel rather than only 8 (PNG is one).

Roblox accidentally deprecated Weld recently due to them going over all existing joint instances. They have a habit of following trends when they remember something exists.


I’ve investigated closer and you’re correct that I can produce the results I’m looking for with Brightness/Contrast.

I think I may have derived the TintColor strategy from trial and error, because it gave me immediate balanced results. I didn’t think to tune both values to accomplish what I was trying to do because they’d produce very washed out results when changed individually.

So… I didn’t think to leave the Brightness still while tweaking the Contrast? I’m not sure to be honest. Seems pretty goofy in hindsight.

The sliders for Brightness and Contrast also don’t have a defined UINumTicks value in the ReflectionMetadata, so they only use increments of 0.1 when using the slider bar.


This would make sense for your specific use case, but keep in mind this is only effective if all of the TintColor values are equal.


Isn’t it March the 29th…? 2022?


Mod went thru a time machine dw