Not enough coffee to go around. Reminds me of the time I accidentally wrote the year as 2009 in a paper I wrote.
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.
See my later post correcting this: [On Hold] Important Notice if Using ColorCorrection.TintColor RGB Values Greater than 255 - #85 by qwertyexpert
Most effects are done before tonemapping, but apparently not color correction.
Seems like Roblox staff are messing with the spacetime continuum again.
Shhhh, itâs fixed now. You saw nothing.
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.
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.
The âfinal pixel colorâ that you speak of however is a floating-point value and can therefore be above 1.
No. Itâs not. And Iâm going to prove it to you right now.
This is a normal screenshot of the Roblox viewport with no color correction applied, i.e. the final pixel color displayed to the screen:
If I now apply a color correction with a tint color of Color3.new(2, 2, 2)
(multiplying the final pixel color by 2), I get this:
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.
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.
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.
This makes absolutely zero sense. Itâs another example of not following the common saying, âDonât fix what isnât brokeâ
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:
Meanwhile using exposure to do the same thing results in the correct effect:
I thought both methods would result in the same thing, but apparently not.
In the future please do use the correct method if you are trying to correct someone.
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?
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.
Color banding
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?
This is the exact opposite of what I said, and doesnât prove anything.
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.
You should remove color clipping NOW!
Instead of spending time on the many features that havenât seen any updates in a while, they consider this to be more important. good job!
Still waiting for updates on this
Hey developers, Weâve been working up quite a storm! As promised earlier this year, Clouds are beginning to roll in for developers over multiple releases and into the next year as part of a multi-phase series of features to enable more Dynamic Skies. The initial release has a very simple, minimalist API that weâre calling Phase 1a. Donât let that rain on your parade, we have lots planned for Clouds and Dynamic Skies! Hereâs a look at whatâs in store: Phase 1a has Clouds integrate with the SâŚ
After a flurry of bug fixes and stability improvements, we are happy to announce the Parallel Lua project has graduated from a developer preview release to a full fledged Studio Beta! Special thanks to all the developers who kicked the tires on the developer preview and provided feedback and demos. Important Note: For now, Parallel Lua features will only work within Roblox Studio! If you publish a place that has Parallel Lua API calls, things will be very broken. The Parallel Lua APIs can beâŚ