We’re making a small behavior change as a Studio Beta release specifically to address the issue of fog range control being too limited when underwater.
The simple change to the underwater fog range only affects the WaterTransparency API, sticking with [0-1] controls we have already. Previously, setting the value to 1 meant a limit of visibility at around 200 studs. With this beta update, setting the transparency to 1 will have a limit of visibility increased to 2000 studs. For a simple approximate rule of thumb, underwater fog is modified 10x in distance further than it was before and we expect that will be a useful range for all experiences that take place underwater going forward.
If the responses we get from the Beta are positive, we will move to full release, noting that this will then affect existing experiences which take place underwater.
As a small non-destructive change (that is, only visibility is increased), we ask that underwater places update their WaterTransparency parameters by simply dividing the current value by 10, or making fine tuned manual adjustments where more visibility is desired (and keeping in mind the performance implications of longer visibility ranges).
I’ll check the change out later when I’m at home (and create a second reply) but this is a really, great update that will surely make terrain water more appealing as a material. Now we can create large underwater showcases without always feeling confined, and crystal clear beaches can have similarly crystal clear water- superb.
A question I have, is: Do you plan on making the visibility range go beyond 2000 studs in the future? Or is this restriction set in place for performance reasons?
Secondly, would you consider adding a slider so that I can more easily test out transparencies without having to type in different values each time I want to change the value or instead of using the arrows and clicking a bunch? Thanks!
I’m worried about the fact that you guys have no proper way to handle breaking changes on older games besides asking developers to do it. What happens to the game that isn’t being maintained or the developer who doesn’t see the update?
Would it be possible to only apply these changes to games once a developer edits them? When they do, maybe you could show them a warning asking them to change their settings?
I understand the change isn’t “destructive” but it still increases a game’s water visibility by 10x - and this isn’t the only instance of a breaking change that could be, theoretically, automatically resolved without developer intervention
Currently afaik there is no easy way for Roblox co automatically resolve cases like this which is why they ask for developers to update things. Having 10x the vision underwater isn’t going to break any games or make them unplayable, at the very least it’ll make a cutscene or two look weird.
What was the design choice behind retaining the alpha slider instead of expanding the slider to 10? Wouldn’t that ensure backwards compatibility for games that no longer receive support?
Excited to see what people do with this update, however. Keep up the good work!
Yes, I did. I’m saying that some sort of automated way to ease the process of releasing a breaking change would be preferable rather than just asking developers to do it.
I see. I’m just extending that a bit further: it will be automatically applied on new games, but will be disabled on older games until the developer opens up the game in Studio. When they do, they would be warned of the change and could then change the value on their own.
I love this change, this will make a massive difference for my game which has a very detailed underwater area of the map which is currently mostly abandoned due to distance limitations.
I will bring up concerns with the max distance if I have any after I get home and try it out. Unless there are grander plans, I personally would have preferred this 0-1 slider be replaced with fog ranges like we have for the old fog in Lighting.
I also severely doubt there will be any great impact on old games, if anything they’ll be improved because you’ll be able to see underwater better than not-at-all.
Why are there performance implications with this? Was Roblox previously doing culling based on fog range?
The only thing I dislike about this change is that there aren’t two separate properties for the transparency of the water’s surface and underwater visibility. With this change, if I want to have the same underwater visibility as I had before on 1, I need to set it to 0.1 which will greatly reduce the transparency of the water’s surface.
Please consider changing this.
(Accidentally posted this on the wrong thread earlier, oops!)
This is why they often take months, if not years, implementing features that are asked for frequently. The necessity of this simply outweighed the disadvantages. There are a lot more projects that couldn’t advance in development without this change than games that got negatively affected.
Oh, I’m not against this feature at all, and I agree that the positives outweigh the negatives here, but I still think that a way to automate the process of updating the property older games would have been preferred.
This is an issue specific to Roblox that cannot be solved. As a web platform, they have to maintain a consistent level of security around their software, which means they have no choice but to carry a load of historical garbage and barely logical API in one package instead of releasing multiple versions. I’d say about 20% of present features are deprecated, if not more. The only way to avoid this is to carefully plan the API to be future-proof, which they haven’t done in the past. (pre-filtering network model, parts being both render and physics objects, etc.).
I understand the technical implications of doing this, but at present there are solutions that the engineers can choose to use that wouldn’t break compatibility, like what @HollowMariofan mentioned:
This is a long awaited update and I’m happy we finally have it! Thanks Roblox!
I also realized that setting the Transparency to 0 makes it completely fogless. I think it’s a bug, but I like it. There should be a way to disable the fog like that.
kind of attitude to more updates coming forward… I feel often many updates are pushed out without strong community involvement and not to mention but the feature request for this was made in 2019. This is more than long awaited. I’m optimistic that we are turning over a new leaf here and starting to take community input a bit more serious.
You rarely see a #feature-requests come to fruition but in retrospect it happened here. Lets hope there is more situations like this going forward.
