I get you’re mad about it, but it’s a technology used since around 2019 and could have been killed off earlier on already. I’m not trying to make this a fully heated argument, I just want you to know they’re GOING to kill it
1 Like
So you don’t agree with people having differing opinions to you on a public forum? You might want to re-think that one, too.
8 Likes
Final statement; Like I said before, change happens and some things we just can’t control. I said I wouldn’t engage in your replies but you’re completely unprofessional. I get you’re mad but it doesn’t mean you have to shoot down Roblox and argue like this every time they make a change you don’t like.
And one last thing: Based on your views, If developers shouldn’t maintain their commitments for Roblox anymore, why are you?
Edit: You know flagging my posts won’t help you.
2 Likes
Oh piss off, ‘Constrained by Compatibility’.
First it was Legacy that took up too much or whatever reason it was, after which the wacky Compatibility alternative was given. And now, now that one’s going too?
How does one replace a system with yet another system that’s not ‘futureproof’. Heck, here I go again having to fix all my game’s places after yet another update that breaks it. I’ve been waiting almost a year on a proper reply back from a previous change that broke aspects of my game…
Wouldn’t be surprised if after two years I yet again have to fix something …
7 Likes
I can probably fix the PointLight stuff myself by running the sample code in every one of my 100+ place instances, and going though every script imagineable that may create a source of light with a deviating Brightness…
The shadows however, require even more finicky manual adjusting, as a lot of playing with the Ambient and OutdoorAmbient allows you to get closer to the original lighting.
This also requires going through all instances of scripted in-game lighting changes (think day/night, different biome/region, special boss lighting, etc.)
It seems that changing (or adding and then changing) the BloomEffect fixes the overly shining neon a bit, but also has the colour go lighter…?
… Yea, no idea how to do all of this and how long it will take to convert everything to a decently matching alternative - and for how long.
Since we’ll have to swallow it again, Does anyone have any tips for converting?
4 Likes
Sure I made a topic about Migrating from Compatibility to Voxel
also for some reason you can now set the technology to Compatibility again for some reason which is useful for comparing I guess edit: you can change it back if you set the tech to voxel instead of migrate button
Re: Why is the Brightness clamp going away?
Re: Compatibility was lightweight, why sunsetting it?
Bundling these 2 questions as the answer is similar.
(@ittrgrey, @az09az99096, @GuilleLopezD, @Metallochrome, @monkeymario1000, @ittrgrey, @Enzotsky, @Beyond_5D , @YTFTAshPlays)
Hey everyone,
I’d like to add more clarity into why we are sunsetting Compatibility, and removing Brightness clamp. In a nutshell, we have to balance the pain points from the sunset of Compatibility (i.e. losing brightness clamp and light anisotropy) against helping the vast majority of our developers who are having important issues with the Lighting system’s scalability.
The main problem we’re trying to solve is that automatic scaling, which reduces Lighting quality when an experience runs at a low framerate, often does not respect developers’ intent – it doesn’t make the best performance decision for many existing experiences and it breaks their artistic intent. It also over-aggressively cuts other features such as draw distance.
To respect artistic intent and improve scalability at once, we need to:
- Separate artistic decisions from the underlying Lighting Technologies as much as possible
- Make sure that any artistic controls work as intended across different Lighting Technologies to preserve artistic intent
Compatibility is not a Lighting Technology (the Technology is Voxel), but it is an artistic choice. The main artistic difference that could be supported across all lighting technologies (Voxel, ShadowMap and Future) is its tone mapping.
As some of you pointed out, the brightness clamp and anisotropic lighting are also part of Compatibility’s aesthetic. The brightness clamp was not extracted into a property because:
- It would have incoherent visual results on other Lighting Technologies.
- It would also impose significant complexity to our lighting shaders which would impact the performance of every experience, even those not using it.
- As a scriptable property, it would fully invalidate the lightgrid every single time the property would change, causing light flickering and performance instabilities.
On the other hand, we tested the migration on a high number of places using Compatibility and we found it is possible to achieve a similar result by adjusting local lights, even if not a perfect 1:1 match. Since similar visual results to Compatibility (although not perfect) can continue being achieved and considering the downsides of the clamp when used with other Lighting Technologies, we decided to sunset it.
9 Likes
In respects to artistic intent, wouldn’t this be a perfect solution for Lighting technologies as well?
If not, have Retro ColorGrading be a complete preset pack that fully converts or preserves all aspects of Compatibility’s style and aesthetic, possibly even with its own sub aspects that you can toggle, change or adjust. In the future, it could even allow users to create their own Lighting packs and publish or distribute them for others to use.
This retro pack currently doesn’t include everything Compatibility has to offer, as clearly there’s aspects that aren’t fully mimicked. Only when the preset includes and offers a proper reproduction for Compatibility’s existing style and aesthetic should it be released as a replacement 
If a developer or artist can’t achieve their carefully composed style again, then abolishing it would only remove this artstic expression. Definitely willing to toggle, switch and convert, but not to reinvent and readjust every aspect of the game/experience’s lighting.
They picked Compatibility and worked around its tech to achieve their style.
Others chose Shadowmap to achieve their desired style.
Removing one and offering a ‘half-functional’ alternative is basically just wiping the style altogether.
7 Likes
It’s very sad that you had to get several moderators from your group to like your comment because not enough people agreed with you… whoops! you’ve accidentally proved everybody else’s point.
8 Likes
Foreword that I don’t intend to personally attack anyone in this post, but it is likely to be otherwise blunt in putting my points across.
How is it respecting artistic intent to remove behaviour (not just the anisotropy but the brightness clamp and even particle appearance) that a substantial number of games rely upon? I simply can’t comprehend how that makes the slightest of sense, either for Roblox or for its developers.
Moreover, how is it improving scalability to require developers with large maps such as @milanomaster to painstakingly spend hours adjusting their games?
The whole reason it was added was to stop older games which relied on Legacy from breaking. It wasn’t added solely as an “artistic choice” in 2019.
Please stop spreading false information about your own product. I appreciate that some of the rendering engineers from the time no longer work at Roblox but that doesn’t mean that the facts have changed.
I don’t understand how this can be a road-block against keeping the brightness clamp and disabling of anisotropy under a setting when developers using the other Lighting Technologies will not have been using or expecting such behaviour in the first place to begin with.
This seems like a needless, self-imposed limitation.
Then, as per the material update 2 years ago, let the developers decide what looks best for themselves? Lock it to Voxel if you want to?
Not offering the functionality at all because the visual results would be “incoherent” with other technologies doesn’t sit right with me in the slightest, because it confirms my suspicion that it would be completely achievable for Roblox to add the feature if they had the will and the desire to do so.
It is not reasonable for developers to be required to, in no uncertain terms, navigate what equates to a mine-field in order to preserve the visual design of their games. It should be perfectly understandable why retaining such behaviour is important to so many.
Letting a number of no longer actively maintained games die off at the expense of what is a self-imposed limitation is quite honestly pathetic and reeks of the same mindset behind the original catastrophic plan for the material update in 2022. Please reconsider.
This just implies that the less complex thing to do for engineering’s sake in the first place would infact be to keep Compatibility as it is. I don’t know how familiar you are with the original reasoning for why it was added, but one of the key points was because of the complexity of keeping Legacy lighting afloat.
The fact is simply that when faced with a similar situation to 5 years ago, Roblox in 2024 instead decides that many use cases aren’t worth supporting 
Nobody said the property had to be scriptable. Quite literally nobody has said that this would be, in any way, a necessity.
MaterialService.Use2022Materials is infact, not scriptable. Lighting.Technology is also, not scriptable. As with the first issue this is a completely self-imposed limitation that doesn’t make any sense.
On the latter point, “causing light flickering and performance instabilities” is also something that:
- To some extent, already occurs if switching Lighting.Technology in Studio.
- Would not be a problem once again, if the property was not scriptable in the first place.
Sorry, but this doesn’t wash. Developers already had to tweak their light appearance in 2019, 2020, and now again.
Except this time, without the brightness clamp, many games’ visuals will simply break! Fantastic work 
Then don’t allow the clamp to be used with non-Voxel technologies. Even if not limited to Voxel, I think I speak for a good deal of people in saying that this is a non-issue and does not, in any capacity, justify the removal of a widely-used feature.
If it behaves weirdly on other Lighting Technologies, that’s the problem of the developer, not Roblox. Hence, it should not be limited out of what is inherently an artificial concern.
In all seriousness, please reconsider removing the clamp and anisotropic changes. There’s a plethora of reasons as to why they were added in the first place and those largely haven’t changed.
7 Likes
Probably will be more than hours. Got a simple game that didn’t take long to fix, but that’s in stark contrast to one of my bigger projects, one I’m finding little time for to develop already.
Now with yet another impactful change to the game/experience which counts over 30 individual places, each with their own custom set of lighting and enemies/weapons/lighting changers that have gone affected. I gave it a go for an hour, but wasn’t getting anywhere much - especially with the considerable thought of going through every light instance of every world. Feeling very much discouraged to enter studio again and try to fix/solve yet another change that’s had massive impact on all of the game/experience… No idea how long it will take and whatfor I must spend days or weeks to painfully try and adapt, tweak and adjust every instance of lighting throughout all 30+ subplaces - oh, and eh… that’s just one game…
And for how long will it even last? Already mentally awaiting the next update to negatively impact the project’s visuals 
4 Likes
True. Compatibility was lightweight, it shouldn’t be too hard to maintain. Just clamp Brightness, change tone map curve and disable anisotropic occupancy.
I’m pretty sure more people are using Compatibility than had issues with Lighting system’s scalibility other than migration of Compatibility to Voxel. Tho I’m not exactly sure. Like Ittr said,
I’m pretty sure a lot of people use Compatibility because it clamps brightness, which makes it easier to light up areas without making it too bright.
Compatibility is actualy more both. While Compatibilility was originaly made to replicate the old Legacy Technology, it is also often used as an artistic choice due to the tone mapping curve, the brightness clamping, and light anisotropy.
Then limit it to Voxel technology, after all Lighting.ColorShift_Bottom is limited to Voxel. (as far as I know)
Again, Compatibility was lightweight, it shouldn’t be too hard to maintain. Just clamp Brightness, change tone map curve and disable anisotropic occupancy.
Just make it not scriptable (I’m getting kinda tired I kinda regret wasting time writing this reply)
Also I sugest making a guide for Migrating from Compatibility to Voxel I’ve already made mine you could maybe do better.
5 Likes
i was wondering why it didn’t appear for me
This is cool, of course, but when we see additions to the shadow technology of the future, or an additional post-processing effect, like chromatic aberration? I hope it will be added someday. Of course, I may be wrong and there are enough effects, but for a more realistic game, it seems to me that it is not enough 
The shadow issues can usually be fixed by just turning up your ambient or disabling shadows for the biggest parts.
The more I read the damages caused by the update the more I realise how unnecessary this is. I would keep defending to keep the compatibility lighting technology or provide an alternative that isn’t just “close enough”, however I don’t look at this update as Roblox trying to improve there platform or anything like that, since the start I looked at it as just an excuse for Roblox to remove something that makes it harder to experience old Roblox (Yes I know compatibility is used for more than that), hence there terrible logic on justifying it’s sunsetting and lack of motivation to do anything about it. If you guys actually want to do something about it there are a lot better ways to do it, I would recommend some sort of petition to give Roblox an idea on how beloved this lighting technology really is (Make sure the petition goes into detail on the flaws of removing it and why the alternative provided by Roblox is not good) and just hope a big YouTuber covers it at which point non-developers will not want the update either which is Roblox’s main target audience which will result in them not sunsetting it.
This is the only realistic way I can think of Roblox actually keeping the technology, arguing with them here isn’t doing anything, they aren’t going to agree with you no matter how good ur argument is, they work for a company and they are going to defend there actions no matter what.
5 Likes
I think this update is pretty fine for most part. I mean, there’s not really much problems, but there’s definitely some flaws in it such as poor quality shadows, not accurately correct lighting, so you are right about that. Hope ROBLOX fixes that soon, otherwise we would be doomed.
3 Likes
but im LAZY
i dont wanna edit every single building in my game because roblox said so
2 Likes
this absolutely breaks my game’s lighthing by a lot. two examples here:
This is how the game looks usually.
Now: this is how it looks with the new “same format lighthing” (Which looks NOTHING alike)
All colors are oddly changed and is not even the same. fix this because one of my game’s style is because is all plain colors. with this update, all colors look so uneven and odd.
What solution do you have for Developers that use this lighthing? I don’t understand why it has to be like that: Always removing old features to add new ones, Why not having BOTH at the same time? what’s the issue behind that?
5 Likes
No idea, it seems like every update nowadays has to “sunset” an older feature
3 Likes