It’s good practise, because they’re not going to change how it functions, it has been so long since they’ve first introduced the glass material and so far no change. It’s safe to say it’s finally grown in and we can use it as a feature.
Just because staff recommended against it upon release doesn’t mean it’s still accurate today. Especially when majority of Milsim games which is like 30% of Roblox Games have also adopted it and of how lazy Roblox typically is.
I definitely agree
Roblox is not above removing features people rely on though, and I expect they’ll have more leniency on removing things they already claimed they would
Here’s my take on this feature request: Far more developers are held back by this feature than those who are helped by it. The better option is to optimize glass refraction and remove the whole decal & translucent part disappearing behavior. Then, Roblox should do one of the following:
Option 3 seems best to me
Wow the original post already said this, I didn’t realize haha
Saying that “glass missing layered transparency is not a bug” is not only semantic argumentation, it’s also quite misleading.
When the glass material was added the lack of layered transparency was a concession made for performance reasons - this does not make it any less of a bug, it is giving an unexpected result to developers who want to use it for it’s intended purpose. However, Roblox felt that this was okay at the time to mitigate the performance loss of the light refraction, but make no mistake, the glass material was NEVER intended to stay this way, so yes, this is both a bug, and a missing feature.
Regardless of semantics - the glass material should not stay this way and still needs layered transparency to be properly supported before it can be used the way it was intended to be used, and several Roblox engineers agree with me on this, so don’t get too attached to this behavior, but I do think that people would also benefit from also having a way to natively achieve this same effect in engine, possibly with some kind of allow/deny list.
As a footnote I would ask that you stop flooding this discussion with petty argumentation if you do not have any meaningful information to provide about actual alternative solutions other than “don’t add a feature that everyone wants except for me!”. Not because I want to silence you, but because you are arguing with people just for the sake of arguing, it’s not at all productive and fills an otherwise well thought out discussion with low quality responses.
minor spelling mistake
this is not confirmed and they stated not to rely on this behavior as it COULD be changed
does this mean they can’t and won’t change it in the future? NO. they already told people not to rely on this behavior for hacky methods lmao
they would’ve stated otherwise if they intend to keep it:
they have done this recently with os.time, which broke multiple games, if you remember. this is the example I was looking for. do NOT rely on unintended behavior no matter how long it’s been working
Chill out man, it’s a joke. Don’t dwell on it. This doesn’t invalidate my main point whatsoever and was not meant to insult.
They changed os.clock’s behavior, removed the last online API, and have done so many other things to remove things from times ago. It’s not good to believe it’ll remain this way.
They’ve stated it multiple times for other things, and it was correct almost every time.
I never stated they removed it, I may have worded it wrong given the context. They changed os.clock’s (I think it was os.clock not os.time, to correct my previous mistake) behavior with no prior notice, causing multiple games to break and cease to function. They’ve also made similar changes to other stuff that I really don’t remember, but
Do not rely on unintended uses for features.
Bugs aren’t intended. This was stated by staff to be intentional. Its more of a missing feature and less than a bug IMO.
Just curious, is there a source for this? This technically confirms that it’ll change in the near future if notable staff members agree on it.
That is just a rewording of the exact semantic statement that I spent that paragraph explaining why it was misleading. Yes, staff said it was intentional. That doesn’t change much of anything because it still defeats the entire purpose of the glass material’s usage in builds. Something can be both a bug and a missing feature at the same time. In this case it’s not a bug in the sense of a literal software error, but rather, it’s a bug in the sense that it’s not giving the expected result to the end user for it’s intended use case.
Just a side note - I am not inviting discussions about semantics on this because it’s not a great use of your time or my time. If you disagree with my assessment then that’s fine, but it’s not productive to the actual post at hand and we should instead be focusing on for what reasons the glass material should have layered transparency, and what options we should give to people who rely on the current behavior.
I suppose I should’ve been a little bit more clear in my wording there, engineers haven’t directly agreed with me on this, but they have certainly indirectly reached the same conclusion as I have.
The primary source is the confirmation from engineers over the years that this is indeed being looked at, the original post where glass was added even links back to here saying that they are aware and while not in active development they are assessing the request. This isn’t the only case of it but it’s the first one that comes into my mind, I recall someone else replying to a bug report saying something along the lines of “there’s a feature request for this already and we’re tracking it but not actively working on it” but I can’t find it at the current moment.
Do I think it’ll change in the near future? Certainly not, because in order to do it they’ll have to add 3D masking first to not hurt the people who presently use it to mask objects. But anyone who is under the impression that this won’t change is sorely mistaken and it is quite literally guaranteed to happen at some point. (Roblox can’t keep unintuitive, broken behavior forever, and per the developer roadmap, 2025 is going to be changing a lot of outdated behaviors, they even added a whole new category for it.)
The last online api was removed for privacy reasons, and code is more often deprecated than visual rendering techniques are. And this wasn’t as popular and so widely used by majority of games (unlike visual graphics which every game uses).
You also didn’t provide examples of what other times they were “correct” about this, probably because there isn’t one.
os.clock will still function just the same, it breaks nothing, it still counts time, it doesn’t count seconds wrong or anything. I think you mean tick() instead, which was deprecated but still functions. People who reported something breaking are clearly wrong about what was actually being broken.
And this was not a feature removal, it was an upgrade to sub microsecond precision unlike the others which caused time to jump forward or backward.
It is not proof of anything, code deprecations still leave the code working, take a look at what they did to raycastfiltertype enum “blacklist”, they created a new raycastfiltertype named “exclude” but still left the other one functioning but hidden.
Also something “not intended to remain as it was” is not a bug, it is called an “implementation” and calling it a “bug” would have to imply “unintentional mistakes made by developers during the coding process”
He’s simply quoting the original post to the glass material.
They were using a hacky method with it to fingerprint players and ban them, which got patched and broke games. They relied on behavior they were not intended to use to base a fundamental system on, and it got changed.
This will happen for glass too.
As stated above, staff are aware of the request, however, as also stated, if this feature request is added there will most likely be an alternative to mask transparent–or even all–types of objects, which should make sure both sides are happy, unless this behavior wouldn’t benefit you?
It will not happen to glass, I doubt they want to anger so many more people than one simple change can to how os.clock() handles time.
Phantom Forces, imagine their players coming here flooding the forums knowing well it’s because Roblox removed this feature that they have to see this:
Instead of this:
They do this for each one of their scopes.
And even if they remove it ( which they won’t ), they’ll introduce a better feature for doing this exact thing just like how they did it with Compatability lighting.
Phantom Forces, imagine their players coming here flooding the forums knowing well it’s because Roblox removed this feature that they have to see this:
Phantom Forces can find a workaround. They shouldn’t be relying on a bug to make their scopes. Whether glass is meant to render transparent objects or not, you still can’t see water, billboard GUIs, beams, text, decals and a lot more.
That’s the whole point of this feature request:
Most of us are held back by glass. Like in my game I want glass’s refraction for creating realistic windows in my restaurant. However, with the windows all decals in the store disappear when viewed from outside. So what we need is a solution that works in favor of everyone, not just the 2% who are happy with the way it is now
If you want refraction so much, don’t use transparent objects inside the restaurant, you’re not the only game to use glass, so it’s safe to say Roblox will not take the chances in configuring the glass material but rather hopefully give us other techniques to do similar things to what we want to achieve.
You can yourself also find a work around, it’s selfish of you to want to take features from existing games just so you won’t have to do the work in yours. Very hypocritical.
And no, there is no work around, if there were then all games using the glass material would have taken it by now.
Again, you keep calling it a bug when I’ve debunked it is not a bug. Something intentional is not a “bug”, correct your mistake.
I don’t have translucent parts in the restaurants—I have decals in the restaurant. Glass purges image visibility as well
…
This thread has made it clear that glass is problematic for most developers with the whole decal-disappearing and translucent-part-disappearing behavior. What’s wrong with the idea of presenting a solution where you and Phantom Forces still get to have your scope behavior AND the rest of us get to have glass that doesn’t poof images into nothing?
Decals inside the restaurant can be applied to a meshpart as a textureid instead of a part without much overhead in peformance and it will not get hidden by glass. That’s one way to solve your problem.
Thanks for the workaround, but it’s not applicable in many different scenarios, like when using SurfaceGuis or BillboardGuis. Also it won’t work for Unions(which have been optimized heavily recently) which don’t use TextureIDs. So anyone using Unions or Parts are stuck.
This is why having the option to not experience glass’s current X-Ray behavior is useful. But again, it shouldn’t be completely removed, because as the OP said, I’m aware that some devs, like yourself,
A workaround for SurfaceGuis and BillboardGuis is fire a raycast, detect if the material is transparent and is glass, and if it is then enable AlwaysOnTop property.
That unfortunately removes all light influence, removes any tainting from translucent parts and also doesn’t take into account the fact that the decal may only be partially visible.
Why does a surfacegui need to be visible through glass anyway, can you show me any use case examples.
