anybody who uses compatibility lighting to completely remove any grade of shadows when building certain stuff aren’t gonna be happy. this has to be the worst update to roblox studio
3 Likes
You can fix “appearing through object” by simply changing DepthMode in Highlight setting to “Occluded”, although you have good points about the angles. Never heard of Line Handle adornment either.
1 Like
it is lol, originally when i migrated i thought it didnt work because literally nothing had changed. the only differences are local lights, bloom, and shadows.
1 Like
Adding new features is cool and all, but did you really need to force all devs to eventually migrate at gun point?
It doesn’t look quite the same, and some shadows come out absolutely horrendous. Really disappointing
4 Likes
Guys we gotta save 3kb in our rendering dll this old lighting system is simply too big guys
9 Likes
adapt or die
(in regard to roblox)
3 Likes
Retro tone mapping is great! Thanks for listening to the fans and providing tools to fix the issue for a smooth transition.
With shadow map or future, it will still look realistic in some way. Compatibility just did it better.
But the migration is definitely more-than good enough to preserve the feel; in some aspects, it’s actually more faithful to “true” legacy than compatibility ever was!
What I meant to say is you can still make unrealistic games in other lighting technologies if you model stuff a certain way but yeah.
If people are getting mad about it, they should be mad for a good reason.
1 Like
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