Ability to apply SurfaceGui as texture

Feature Requests Engine Features
#1

I’d like the ability for a SurfaceGui to be applied as a texture (e.g. a Decal) with the dimensions of the CanvasSize. Instead of rendering the SurfaceGui as, well, a ROBLOX GUI, it would be rendered as a decal, and thus play nice with lighting. It shouldn’t be a pain to get the color data from a GUI every frame, considering that, you know, it’s already done, so instead of rendering it on top as a GUI, it’d be great if it could be rendered as a surface texture.

This would allow for a few things aside from just playing with lighting right:

  1. Decals wrap around meshes. SurfaceGuis don’t. This would let you use SurfaceGuis on things like Head meshes and CSG objects.
  2. If the support to render as a Texture (the object) and not just a Decal is added, you could apply one SurfaceGui many times to an object.
  3. SurfaceGuis could show up in thumbnails, as they’re applied like a decal. yay!

The way I think the API could be implemented is adding either a new property to both the Decal and Texture object (or adding a superclass to them and adding it there), called something like “TextureGui”, which takes precedence if it is set and is set to an Instance, or, adding a property called “ApplyAsDecal” (or ApplyAsTexture) or an enum “ApplyType” with Default or Decal. I think the first is the more powerful solution, but it’s also a bit less intuitive.

10 Likes
#2

support. i’d really like to be able to skin objects.

there’s already a thread for this, or something similar.

http://developer.roblox.com/forum/feature-requests/8968-texturewrap#151192

2 Likes
#3

[quote] support. i’d really like to be able to skin objects.

there’s already a thread for this, or something similar.

http://developer.roblox.com/forum/feature-requests/8968-texturewrap#151192 [/quote]

That’s… not what this is, at all.

1 Like
#4

oh, my bad. i read it too fast and didn’t take in the details. i don’t get what you’re saying though. can you explain differently? it just went straight over my head. if it’s a useful idea, i want to support it.

1 Like
#5

I’m not sure what Roblox’s system looks like, but usually you load a texture into the GPU’s RAM, a very slow and painful process, and as gui objects can move around a lot, you would be taxing the bandwidth to the GPU quite a bit, the reason it has to be in the GPU ram is that operations like calculating lighting, fog, and other rendering effects require fast and immediate access, otherwise it will compute slowly, and not be able to keep up with the 60fps rendering, at least that’s why I assume it’s as it is.

1 Like
#6

Maybe instead we can take a ‘snapshot’ of the current layout of the GUIs and then use that instead?

1 Like
#7

Would this make it possible to easily bypass moderation? Loads of frames are impractical, but not if they could be converted into an image

1 Like
#8

not any more so than they already do

1 Like
#9

Any word on this? I got the Edit of Review but nothing else; I’d love to know if this idea has been shot down, postponed, put on some sort of future “to do” list, etc…

1 Like
#10

Gonna bump this post to elaborate the limitation of SurfaceGuis. I feel this recommendation fits the post epicly.

Animating a rigged mesh with UV mapping. We should have the ability to deform the SurfaceGui with the rig!

image
image1144×429 127 KB

3 Likes
#11

I wonder why this isn’t already the case considering I’m pretty sure SurfaceGuis get baked down into a texture before being rendered?

If thats too expensive, it could also be useful to have an API to convert a LayerCollector object into an EditableImage

6 Likes