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.
Excuse my ignorance on the general subject of lighting, but how exactly does color banding occur in the engine? Also, what do you mean when you refer to bit color channels?
It’s literally exactly what you said, and disproves exactly what you said.
YOUR claim was that color correction was applied BEFORE the tonemapper, which for the record IS a “real” tonemapper, not that I have any idea what would constitute a “fake” tonemapper (you just seem to not know what you’re talking about). I disproved your claim fairly easily by producing the exact same image as produced by the color correction effect, but in an external program using only a screenshot.
If what you claimed was true, and that color correction was indeed applied before the tonemapper, such a feat would be impossible.
Oh, and as Sentross brought up to me on Discord: Nobody in the history of ever has implemented post-process effects the way you seemed to think Roblox’s were implemented. It defeats the entire point of post-process. (Bloom is an entirely different story and hardly constitutes a post-process effect anymore)
I think that this change is rather good. It is illogical to have an RGB value that is below 0 or above 255. That is just how RGB colors work on Roblox so why should this be an exception?
Because it provides us with a lot more options to easily create fancy lighting.
It’s not hurting anything, so it shouldn’t be changed arbitrarily. It’s not teaching anybody any bad practices and it’s really just an outlier. If it had some sort of adverse effect, it would make sense to remove it, but in this case, the tradeoff is very much not worth it.
Yet another terrible change that isn’t needed in the first place, limiting what is possible in the engine like the glowing effect on textured 3D objects. good job roblox.
I still think it makes sense to clamp the values to the standard 0 to 255. If you walk up to someone and say that you want your website to have the color value of “RGB(260, 260, 260)”, they are going to think you are crazy. I understand that this is a different way to accomplish something, but it is an unintentional bug. Bugs get patched. Maybe out of this we can get more nuanced control over color and lighting through the intended system instead of an unintended roundabout method.
If clamping it is the exact same performance as it being unclamped, what’s the point of clamping it?
Why have it clamped in the first place, let experience developers do what they want to their own experiences, bugs can bring out very unique visuals regardless and should be embraced as art.
I don’t see Unity or the Chrome Browser clamping your RGB values. You use what you want, it’s your platform, your content.
I don’t see the problem. Yes, you get consistency with other RGB values and people can’t say, “You’re crazy!”. But it’s not worth outright removing perfectly operational functionality because of a trivial and minor reason like that.
The animation update is doing that for a slightly less small issue, but it’s still screwing up functionality that existed for years before-hand. It’s not necessary and most people are against it. Since that update is separate, I’ll keep my opinion on it to myself, but in this case, the ends do not justify the means.
I’d rather not lose most of my cool lighting functionality for an undisclosed amount of time just so that a value can be clamped and be consistent with other RGB values. Not only would it break existing games using that, but it would be impossible to replicate until Roblox released new lighting features to make it possible again, and unfortunately, they have been very slow about that sort of thing in the past.
