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 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.
What’s your source for this? I don’t believe you’re correct here, at least in the case of ColorCorrection.
ColorCorrection works by multiplying the final pixel color by the TintColor, hence why Color3.new(0, 0, 0) ends up with an entirely black image, Color3.new(1, 1, 1) doesn’t impact the image at all, something like Color3.new(0, 1, 0) leaves you with just the green channel, and something like Color3.new(10, 10, 10) ends up blowing out half the image.
Yes, it does. The “final pixel color” that you speak of however is a floating-point value and can therefore be above 1. The tonemapping step “flattens” these floating-point values into values that can be displayed on-screen. I believe Roblox however does not use a proper tonemapper and instead multiplies by exposure and then clamps.
Notice that if you have something brighter than white and you use a color correction, you can get it to display the brighter-than-white details.
Isn’t the whole point of the HDR pipeline that the engine supports color values outside of normal range? Color values above maximum intensity emit light. That’s what HDR means to me, and to most people.
The engine uses 8 bit color almost everywhere. This is especially noticeable on UIGradients, and flat colored images. Color banding is a really obnoxious side effect of using 8 bit colors, meanwhile, most displays support 24 bit or even 32 bit color channels, when even just 16 bit color channels are enough to eliminate a large majority of color banding.
This has sort of led to me never really fully investigating HDR, because, why bother with it if Roblox is just going to sometimes do it for me, and I don’t really have much control otherwise.
That’s just my thoughts on this overall, the color support in the engine is all around just pretty limiting.
Just to clarify so we understand correctly, you’re saying that the HDR values are flattened back to a 0-1 range after post processing?
If so then yeah that makes sense. You would want HDR processing available for post processing effects too, and the operations to flatten it back into a 0-1 range would be done after post processing. Not sure what Rocky is confused about.
Now, I’m going to do the exact same thing but in Photoshop using the levels filter. I’m going to use the first screenshot as a base meaning there’s no HDR data.
Whaddya know! The EXACT. SAME. IMAGE. I can send you the .psd if you STILL don’t believe me.
THEREFORE, the color correction effect in Roblox MUST be applied AFTER the tonemapper and AFTER the brightness values have been normalized.
Welds are already planned to be deprecated. This wasn’t a random “accident,” this was miscommunication on the engineering side.
Seeing from their perspective, they probably added the deprecated tag because a senior engineer said something along the lines of “add the tag to all legacy constraints and movers,” or something else as silly as that.
That’s not comparable to clamping a Color3 value. Adding a deprecated tag takes moments, while clamping a value is an intentional and planned change that has to be tested internally.
I didn’t even know this was possible until I read this thread. Can certainly see how it could be used to make some very interesting alien environments and create glowing artifacts.
What would be nice to help with those sorts of use cases is the addition of emission maps for SurfaceAppearance.
Definitely prefer Roblox not to clamp values when there is minimal chance of it breaking down the road. The creativity afforded by unconstrained properties is a huge compensator for Roblox’s narrow range of post processing and graphics effects. It’s a letdown to add artificial limitations without replacing the functionality lost.
This is the exact opposite of what I said, and doesn’t prove anything. Increasing the brightness loses information, which can be done either by the pixels only having 24-bit color (in Photoshop), or by Roblox clamping the pixel values before displaying them to the screen (which is their super-basic “tonemapper”). After further testing I’ve come to the same conclusion, but not using your method as it’s completely incorrect.
The correct method involves testing whether it can add information back that would have been discarded in the transition from floating-point to 24-bit color.
The part on the left has a SurfaceGui with a brightness of 10. The part on the right has its SurfaceGui’s brightness set to 100 instead.
They both clip and cause bloom. Information is lost due to them both appearing as white on-screen.
Using ColorCorrection to darken the image would have resulted in the one on the right being noticeably brighter according to my theory, but it doesn’t:
After most post processing. I recently did a few tests and discovered that ColorCorrection is indeed applied after the HDR values are flattened. But most post processing effects (bloom, sunrays) do operate on the HDR buffer.
Shhhh, it’s fixed now. You saw nothing.
