SurfaceGUIs don't render properly

Bug Reports Engine Bugs
#1

Hey everybody.

This behavior may be intentional, so I apologize if this is more of a feature request. This is “new” behavior. GUIs used to render normally.

I’m sure plenty of you are aware of this, but I really think it’s worth bringing up. SurfaceGUIs don’t render perfectly. As the center of the GUI approaches the side of your screen, the entire GUI stops rendering. It’s really killing the immersion that some impressive games out there have.

Here’s an example place that uses them as an advantage, for things like atmosphere and build quality: [Unfinished] Star Tours — The Adventures Continue - Roblox

Here’s a video.

Is there any word on if this will be fixed? Shouldn’t at least the people with a High Graphics setting be able to avoid this visual bug?

Thanks

1 Like
#2

I reported it ages ago, one admin did reply (M C G something). My guess it code from regular GUI rendering was copied to SurfaceGUIs on accident.

#3

I feel that’s an inproper use of SurfaceGUI’s, so it shouldn’t be fixed just for this reason of using them as glow-lites, or for any environmental structure. I notice this issue as well with SurfaceGUI’s that are actually screens, it’d be nice for it to get fixed but it’s really not impacting, unless it’s your case where you’re using them for environmental structure since it takes away the immersion, which I don’t think deserves fixing because it’s not a proper use of them.

It seems that what makes them glow is that they ignore lighting properties, I like this behavior, it makes a cool effect that’s needed in cases such as yours which I would like to be a property for bricks so I don’t have to use SurfaceGUIs for every dang point of effect I want. (ie. light unit, crystal) There are also cases where I prefer that the SurfaceGUI does account for lighting, like a calculator or brightness on a laptop screen, so having the “IgnoreLighting” property makes it so the ScreenGUI takes lighting into effect.

It depends on what SurfaceGUIs is meant for though, I assume they’re meant to be animated because they can do so much, if they just sit there and do nothing it’s a waste of what they can offer.

#4

Even if it wasn’t meant to do this, it still should be fixed. It causes problems in general for SurfaceGuis.

#5

While this probably should be fixed, maybe someday here we could get a way to make stuff self-illuminated? It’s probably really costly to use SurfaceGUIs just for pseudo self-illumination, and it outright doesn’t work on anything that isn’t flat.

[size=2]yes I’m trying to use your thread to pitch self-illumination again[/size]

#6

I was seeing this yesterday in a project I’m working on. No big deal to me but it was annoying to find out that my problem wasn’t my fault.

Also, on the topic of GUIs being ignored for weird reasons, will rotated guis disappearing ever be fixed? If you rotate a gui and then place it off screen in a way that its actual dimensions are off the screen, the gui won’t be visible even if the rotation should be causing it to appear.

#7

Would be pleased to have this fixed.

#8

[quote] I was seeing this yesterday in a project I’m working on. No big deal to me but it was annoying to find out that my problem wasn’t my fault.

Also, on the topic of GUIs being ignored for weird reasons, will rotated guis disappearing ever be fixed? If you rotate a gui and then place it off screen in a way that its actual dimensions are off the screen, the gui won’t be visible even if the rotation should be causing it to appear. [/quote]

This is another big problem. I had a bit of frustration with this a couple weeks ago when I had a 180º rotated arrow that faced the opposite direction. Ended up making an entirely separate and flipped image.

1 Like
#9

It doesn’t matter if it’s “proper use.” They can’t be properly used if they are culled incorrectly – the failure of the monitors to work shows that.

It’s not like they have the option to pick and choose when they should be culling correctly vs incorrectly.

Right now it’s always incorrect, and this is suggesting they make it always correct.

#10

[quote] …which I don’t think deserves fixing because it’s not a proper use of them.
[/quote]

This is where you’re wrong. SurfaceGUIs were purely designed to throw GUIs onto bricks. I can even quote ROBLOX on the fact that they were designed for anything. Not just menus in a 3D space, which would be broken with this bug anyway.

Source: http://blog.roblox.com/2013/12/put-a-gui-on-that-surface/

Perhaps ROBLOX didn’t see SurfaceGUIs being used like this, because they didn’t know what to expect. Saying “You’re using them wrong” isn’t a great solution to anybody’s problems.

1 Like
#11

[quote] …which I don’t think deserves fixing because it’s not a proper use of them.
[/quote]

This is where you’re wrong. SurfaceGUIs were purely designed to throw GUIs onto bricks. I can even quote ROBLOX on the fact that they were designed for anything. Not just menus in a 3D space, which would be broken with this bug anyway.

Source: http://blog.roblox.com/2013/12/put-a-gui-on-that-surface/

Perhaps ROBLOX didn’t see SurfaceGUIs being used like this, because they didn’t know what to expect. Saying “You’re using them wrong” isn’t a great solution to anybody’s problems.[/quote]

I’m not dissing your way-of-design, you can get creative with it- however: “It’s probably really costly to use SurfaceGUIs just for pseudo self-illumination” - gkku, it’s laggy to use SurfaceGUIs this way, making it inproper. It’s a big turn off to see SurfaceGUIs as a static object, like seeing a sign with “Drinks” on it and nothing else. it’s costly to have them, they should at least be getting animated in some way.

#12

[quote] [quote=“Dinizterz” post=118029]…which I don’t think deserves fixing because it’s not a proper use of them.
[/quote]

This is where you’re wrong. SurfaceGUIs were purely designed to throw GUIs onto bricks. I can even quote ROBLOX on the fact that they were designed for anything. Not just menus in a 3D space, which would be broken with this bug anyway.

Source: http://blog.roblox.com/2013/12/put-a-gui-on-that-surface/

Perhaps ROBLOX didn’t see SurfaceGUIs being used like this, because they didn’t know what to expect. Saying “You’re using them wrong” isn’t a great solution to anybody’s problems.[/quote]

I’m not dissing your way-of-design, you can get creative with it- however: “It’s probably really costly to use SurfaceGUIs just for pseudo self-illumination” - gkku, it’s laggy to use SurfaceGUIs this way, making it inproper. It’s a big turn off to see SurfaceGUIs as a static object, like seeing a sign with “Drinks” on it and nothing else. it’s costly to have them, they should at least be getting animated in some way.[/quote]

That doesn’t change the fact that this needs to be fixed. It doesn’t matter how you’re using it. And saying the problem is with the user is even crazier. I never disagreed that it’s not costly in performance, and saying this shouldn’t be fixed is nuts too.

Saying what someone may be doing with SurfaceGUIs is honestly a bit off topic from a bug report about rendering issues. Who cares if it’s animated or not? You’re getting the same problem. This isn’t a thread about GUI performance, this is about GUI visibility. Anyone should be able to agree this is an issue.

1 Like
#13

[quote] [quote=“Dinizterz” post=118029]…which I don’t think deserves fixing because it’s not a proper use of them.
[/quote]

This is where you’re wrong. SurfaceGUIs were purely designed to throw GUIs onto bricks. I can even quote ROBLOX on the fact that they were designed for anything. Not just menus in a 3D space, which would be broken with this bug anyway.

Source: http://blog.roblox.com/2013/12/put-a-gui-on-that-surface/

Perhaps ROBLOX didn’t see SurfaceGUIs being used like this, because they didn’t know what to expect. Saying “You’re using them wrong” isn’t a great solution to anybody’s problems.[/quote]

I’m not dissing your way-of-design, you can get creative with it- however: “It’s probably really costly to use SurfaceGUIs just for pseudo self-illumination” - gkku, it’s laggy to use SurfaceGUIs this way, making it inproper. It’s a big turn off to see SurfaceGUIs as a static object, like seeing a sign with “Drinks” on it and nothing else. it’s costly to have them, they should at least be getting animated in some way.[/quote]

This isn’t a thread about how someone uses a feature and If you haven’t noticed yet, some users here aren’t worried about performance. Besides, this bug affects anybody working with any SurfaceGUIs. It doesn’t matter if it’s animated or a solid color.

You’re not even sure if SurfaceGUIs take up much more performance, using quotes with words like “Probably”

You’re also, apparently, saying that the example I linked above is a big turnoff since it’s static and not moving. I’ll have to disagree here. It pulls off the desired effect very well if you’ve ever seen the real amusement park ride that this place is based off of. Bright neon lights that are beyond ROBLOX’s color palette is a great use for SurfaceGUIs.

And I’m not defending my place, it’s not even mine that I have posted above as an example. I don’t even know why you’d bother bringing up opinions much like “This doesn’t look good anyway, don’t bother fixing it” when this problem is persistent for anybody working with SurfaceGUIs.

This is a bug report thread. Treat it as one.

1 Like
#14

It’s not actually as costly as you would think…
Since everything the rendering engine thinks is invisible is culled, there is a dramatically smaller impact on performance than if there were hundreds in one place. GUI lag only becomes a problem when they are more than a couple thousand anyway.

I would, however, consider using “smart” ways of layering bricks and GUIs so that a minimum amount are used.

#15

[quote] [quote=“Dinizterz” post=118029]…which I don’t think deserves fixing because it’s not a proper use of them.
[/quote]

This is where you’re wrong. SurfaceGUIs were purely designed to throw GUIs onto bricks. I can even quote ROBLOX on the fact that they were designed for anything. Not just menus in a 3D space, which would be broken with this bug anyway.

Source: http://blog.roblox.com/2013/12/put-a-gui-on-that-surface/

Perhaps ROBLOX didn’t see SurfaceGUIs being used like this, because they didn’t know what to expect. Saying “You’re using them wrong” isn’t a great solution to anybody’s problems.[/quote]

I’m not dissing your way-of-design, you can get creative with it- however: “It’s probably really costly to use SurfaceGUIs just for pseudo self-illumination” - gkku, it’s laggy to use SurfaceGUIs this way, making it inproper. It’s a big turn off to see SurfaceGUIs as a static object, like seeing a sign with “Drinks” on it and nothing else. it’s costly to have them, they should at least be getting animated in some way.[/quote]

I’m not using this for self illumination, I’m using them to display information and menus.
I have run into the same bug and it’s an issue for my stuff.

Your argument for this to not be fixed applies to literally one scenario.

#16

[quote]

I’m not using this for self illumination, I’m using them to display information and menus.
I have run into the same bug and it’s an issue for my stuff.

Your argument for this to not be fixed applies to literally one scenario. [/quote]

Which scenario exactly? Confused by that, since every argument in existence literally addresses only one scenario/topic?

This bug actually should be fixed since big moving screens, like a cinema screen, disappear if you’re looking away with a significant bit of the SurfaceGUI still in your peripheral, which is a turn off. Asimo’s use of the SurfaceGUIs I deemed to be inproper thus doesn’t deserve to be fixed, but I just thought up of why it should be^. So it doesn’t matter if it’s inproper or not. Honestly though even with the cinema screen scenario it’s not a big deal so I wouldn’t “Top Priority” it.

And due to my PC I probably won’t be able to sustain a visit Asimo’s place :frowning:

#17

I feel like my use of “inproper” is sounding offensive, I mean technically-inproper as in it causes lag. Like everyone’s style of coding when they first started coding, that kind of inproper.

“I don’t even know why you’d bother bringing up opinions much like “This doesn’t look good anyway, don’t bother fixing it”” Not hating on it bro, imo it looks awesome

Just realized: my use of inproper is improper* q

#18

Wow, so much discussion.
This looks like a culling bug that we should fix - I can repro it on a simple GUI for some reason. Thanks for reporting.

#19

It has been a problem since the start, it’s the same, when you drag the surface gui out of the brick xD

#20

Clarification: I’m seeing a bug that happens even if surface gui does not extend past the part boundaries.

The use case where surface gui has elements outside of the part surface is not supported. We don’t auto-clip SG by part bounds only because clipping does not work with all elements.