Currently ColorCorrection.TintColor RGB values are not clipped, this will soon change so they are clipped to [0,255].
If your game uses ColorCorrection.TintColor values outside of this [0,255] range, you can accomplish the same visual effect with in range ColorCorrection.TintColor values combined with adjusting ColorCorrection.Brightness/ColorCorrection.Contrast values.
While this should not affect the majority of experiences we still want to make sure you have time to make any changes. We will enable this on 3/30 at 10 AM PT. Please let us know if you feel more time is needed and we’d be happy to work to shift.
I can’t believe you’re removing capabilities like this after moving Roblox to an HDR pipeline with Future Is Bright. Shouldn’t you be unclamping values, not clamping them? Right now, my ability to take full advantage of the HDR pipeline is adversely impacted by the clamping done on certain color values all throughout the engine, and this change does not help.
While I understand this specific change is possible to remedy by using the other properties available to ColorCorrection instances, I also recognize that this may be the start of a trend of removing all currently unclamped color values, which would make the situation even worse.
The situation that I described in my post, being unable to take full advantage of the HDR pipeline due to color values being clamped, is a real issue that I already run into during my day-to-day development.
If additional color values that are not currently clamped were to become clamped in the future, then that situation would become worse.
This specific change isn’t very harmful on its own, but tells me that Roblox is looking at whether certain color values are clamped or not, which can result in the situation changing for the worse.
Either that or they’re just looking to shrink the size of their shader uniforms.
Any idea when emissive effects for PBR textures will be available? I would like to know the reasoning behind clamping this. Obviously it’s not intended behavior, but some developers are using it in an exciting way. Are there plans to provide officially supported ways to achieve wild post processing effects?
This was my first thought. If TintColor is being clamped, it’s not unreasonable to think other color properties will experience the same. I currently take advantage of the Decal’s unclamped color value to mimic emission on certain models, and I would hate to see that capability go before we have a replacement.
not a fan at all, especially since the previously mentioned (3 years ago) tonemapper controls still haven’t been exposed to us.
we use this trick on our games (both dragon adventures & winds of fortune iirc) in order to make the color white, especially in objects like the skybox, actually white and not the light grey it is in default lighting. this is remarkably short notice for us to change over and validate the lighting on both our current and past projects. please consider delaying to give developers more time to change this over.
Clamping the tint color does nothing to your ability to take advantage of HDR. Methinks you don’t fully appreciate the “post” part of “post-process”.
What are you proposing they raise the maximum to then? 255 is generally the maximum for RGB and there’s quite a few colors available, especially now with parts being able to utilize color3.
As off-topic as this is, I too would like to see tonemapper controls exposed to devs.
This is a valid concern but a symptom of a much larger issue, and it’s that while the lighting engine may support HDR brightness values, the skybox does not and we’re limited to PNGs for our skyboxes and environment maps. A proper solution would be for Roblox to truly support HDRIs for environment textures, considering there’s even a control for camera exposure!
Highly unprobable. I would consider this a fallacy due to nothing really supporting that Roblox would follow such a trend. The concern is valid, but unlikely to be based on true nature.
100%. would be wonderful to see HDR image data in general better supported but skyboxes would be a very good first start, especially with exposure already being adjustable.
No seriously, why? What is the point behind this change? I actually don’t have anything to say other than… what’s the point?
I have no idea about the logistics or what goes behind video rendering. I’m just a programmer, if you can detail further why this change is being made, that would be appreciated.
I’ve been using this trick for years to get some really cool results really quickly and efficiently, as well as to circumvent several poor limitations.
So now you’re telling me I have to use crap-tons of other meaningless workarounds just to get the intended effect again. Great. Awesome. Thank you so much for even more work I didn’t need to have after I’m already scrambling to fix all the audio in my projects.
Roblox is yet again, fixing something that isn’t broken, and we, the developers, have to take the fall for it.
Why is it that every single time something good exists Roblox absolutely has to screw it up? Be it materials, the animation engine, the audio… God. Developing on this platform is a nightmare. I’m sick of horrible and unnecessary changes like this.
Can you please focus on problems that need actual attention instead of being afraid of numbers in surplus of 255?
Unless this has some significant performance improvement or will open up opportunities in the near future to have identical visuals but with more options, I don’t believe this is a good idea.
There’s no real reason to do this, it’s not like it’s being abused or like it’s breaking anything, and from the many replies to this thread it’s clear that this functionality (intended or otherwise) is very heavily used and appreciated.
While I may not use this myself, I use other unclamped values to make cool effects, and I seriously hope this at the absolute worst only sticks to this, and won’t mean other values get clamped down. (No, I’m not naming which ones because I am definitely not going to give Roblox any more bad ideas)