Currently, due to the nature of how the engine generates gui content, it is unwise to use Guis to create runtime generated image content that may be used in high quantities. Each Gui allocates image space for its content via the graphics API (if my understanding of the implementation is correct). So for example, if you wish to render the same SurfaceGui over multiple parts it results in oversubscription of memory resources to make space for the gui content.
The workaround we must use if we are to save on performance (via instancing) is to render the image we want ourselves outside of the engine and upload it to ROBLOX as an image asset and apply it as a texture. Doing this is quite inconvenient, especially for devs who are unfamiliar with applications used to create these renders. Not only is it inconvenient, but it demands additional network resources to download the texture asset when it could just be generated on the user’s own system faster and using less resources.
Overall this setup seems a bit contrary to the lightweight but powerful design philosophy that the engine is trying to fulfill. If this was addressed it would improve the workflow and efficiency of using runtime generated resources. Integrations could also be made with the AI assistant to train it to be able use SurfaceGuis in this way to save on ROBLOX storage resources for AI generated assets.
A potential solution could be to allow Guis to be linked to Texture objects via the Texture property as an alternative to a string assetid, the different object type specified could direct the engine to try to link the texture object to the content of the Gui specified (should be as simple as linking to a different image object on the graphics API, at least in vulkan thats how it works). Additionally it would be nice if we could specify Guis to be used as the albedo on SurfaceAppearance instances as well to invoke the same functionality. It shouldn’t be super difficult to implement depending on how the engine abstracts (or doesn’t abstract, in which case this would probably be a pain to implement) image objects internally.
I understand that this is kind of a niche situation for professional devs on the platform as we have workarounds. I just randomly thought of this while writing a script that duplicates the same SurfaceGui on all 6 sides of a rectangular part and thought “there’s gotta be a better way to do this.”
I think this would improve the engine’s ability to enable developers to produce content using the engine independantly. You may also find additional capabilities for visual effects from increasing ways for developers to access/use to image memory.
Anyway thanks for reading my ramblings, hopefully my grammar/spelling doesn’t suck too much I am terrible at proofreading. Please let me know if my vague understanding of how the engine works is accurate and if this is an easy feature to add (or if you’re already working on it).
Thanks!