Make glass work with transparent objects

This is a bug.

A better solution would be to add “occluder” (for lack of a better word) parts or an occluderglass material, and occluded parts so you can choose custom parts that are invisible behind occluderparts no matter what. Ideally you’d be able to select basic options for occluders such as occlude transparent parts, and even unanchored parts for cool game concepts.

Is there anything stating this was intentional?

3 Likes

While it is intended, the staff member @Judgy_Oreo quoted specifically said not to rely on it, so Crazed was right about that. Plus even if it’s not a bug per-se it’s still buggy, as it’s completely non-intuitive…

Although you were right about it being intentional, the reason you provided was wrong and led to you believing this behavior is ‘safe’. It’s not, and can be removed at any moment

To be fair, I don’t think most of us had seen the staff post, but now that we have we know that we’ll have a fix for this weirdness at some point. Let’s hope they prioritize this

1 Like

The fact it was stated in the release post as intended to reduce performance issues.

Not at all. Here is sufficient evidence that I acknowledged your points:

I’ve made it abundantly clear that I understand that it isn’t a bug. Unless you want me to say it a fourth time.

I’ve pointed out what you got right, but you’ve chosen to ignore that as well as my one critique of your reasoning:

This wasn’t the reason why it was added, this is just a random byproduct of the feature

And above all

Even though Crazed was wrong about it being a bug, he was completely correct that you should NOT rely on this for your games. It will be removed when Roblox optimizes glass. So I completely disagree with your statement:

2 Likes

I’m not saying I don’t believe you, but are there any images of staff responses to back up what you’re saying? (or the name/link of the release post)

This is the quote, it was intentionally added to prevent what I just stated. Although it also states we shouldn’t rely on it. It’s still not a “bug” as he calls it nor are they likely to remove it because many games have already adopted this as a feature. E.g. Phantom Forces being a big one.

1 Like

That is not the reason you were using before. You said it

There was absolutely no problem with SmoothPlastic You thought it was for aesthetic reasons. It was for performance reasons. You can accept your mistakes you know. Even @Judgy_Oreo could see you didn’t understand why translucent parts weren’t rendered behind glass:

Please just accept responsibility for things you say and move on

Let’s fix his sentence then; Don’t rely on temporary features

Can you respond to the above quote @InsanityFE4R, it seems you’re trying SO hard to avoid it. According to Roblox staff, you aren’t supposed to rely on it because Roblox only adopted it as a temporary feature for being able to roll out glass.

1 Like

Could’ve addressed my points before deciding you’re done, but instead you’ve taken the low hanging-fruit of throwing a meaningless epithet. No matter.

I’m not saying you should stop using it, do whatever you want. Just keep in mind that this is not supposed to be. It was a temporary fix, not a permanent thing.

Remember how this all started?

My point stands:

Crazed was right that you shouldn’t rely on this behavior as it can be removed at any time(though he was wrong about it being a bug)

You were right that the feature was no bug(but were wrong about why it was a feature and in saying it was here to stay)

In your focusing on Crazed you’ve been unable to look at yourself. I encourage you to start doing that as it will have a positive impact in your life

Chill out, just drop it.

They’re doing the opposite of what Roblox staff recommends and you’re saying this is a good practice. They already stated that this behavior may change at any time and is not to be relied on, so this should not be the reason why you oppose this suggestion. A better idea is to provide an alternative you see as fair to please both sides.

1 Like

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:

  1. Make a new object that when parented under translucent parts gives them glass’s old “X-ray” behavior
  2. Add a property in MaterialService that allows you to choose glass’s behavior
  3. Add a new material without glass refraction but with the old X-ray capabilities

Option 3 seems best to me

1 Like

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.

1 Like

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

1 Like

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

  1. It’s not deprecated, from what I remember.
  2. It’s proof that they will change the behavior of things regardless of what game is impacted, so you probably not take that warning from years ago for granted. Feel free to use it, but don’t be surprised if the behavior for it changes, and try to have a backup.

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.

1 Like

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.)

1 Like

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?

1 Like

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:

image

Instead of this:

image
image

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.

1 Like

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.

MORE examples of commonly used features that glass hides.

4 Likes