As a Roblox developer, there are frequent use-cases where I need to have the same Viewport Frame contents across multiple Viewport Frames. While I can easily achieve this by just duplicating the contents to create the same image, it will not only require duplicating all of its contents (instances), but also having an entirely new texture stored in memory that looks exactly the same.
If there was a method of creating a master Viewport Frame or Canvas Group Texture and let any Image Frame read from it instead of creating its own texture (similar to some adornee system), it would make it a lot easier to create duplicates and modify all the contents of every chained Texture on a whim without wasting memory making tons of duplicate instances.
Some example use cases:
Imposter system: where far away objects are replaced with billboard gui versions of themselves to avoid rendering themselves. Re-using the same texture on similar objects (e.g. trees and rocks)
Large crowds made of Humanoids in Viewport Frames
Inventory system that shows lots of images of similar items that are made up of complex pieces.
Simple Billboard Gui Decorations in environments that are placed everywhere (such as light fixtures, bushes, clouds
TV Screens / Posters with complex designs that are created from GUI pieces, parts, models, humanoids, etc…
Yep! We absolutely should be able to use Viewportframes and canvasgroup textures as input textures for other things.
Some extra thoughts:
A canvasgroup fed into the diffuse texture slot on a surfaceAppearance would almost be the equivalent of surface shaders.
Decals, stickers, user customization on objects. Imagine a racecar textured with a canvasgroup: you could put sponsor stickers all over it, mud, and other damage.
Lava and other flowing materials could be simulated just by scrolling a texture inside a canvasgroup
Any way to achieve this functionality would be greatly appreciated.
If ViewportFrames had a property that acted like how Adornee does, where a BillboardGui’s Adornee property defines where in the 3D world a BillboardGui will render, the ViewportFrame’s Adornee property could define what in the 3D world it will render.
Some pros:
We get to treat PVInstances as the source of truth for what renders, and we don’t have to do any cloning, re-parenting, tracking of instances, properties, attributes; any of the fun replication stuff that comes with that. This will alleviate lots of major headaches, and keeps the heaviest Instances to a minimum.
The example that comes to my mind is a boss tracker. We can track the real in-game boss at the same time it’s animating and fighting players, and can see the bosses model on my screen.
We get to forego WorldModel, and can simply create new ViewportFrames & Cameras whose position and orientation can vary regardless of the PVInstance (multiple perspectives).
An example here could be a camera system that tracks a Character through different CFrames in a prison game.
Some cons:
We don’t get to parent PVInstances to ViewportFrames, and lose that “just works” functionality that we’re used to, potentially making a breaking change across many games.
If multiple, unrelated objects need to be rendered in a ViewportFrame, it’s much easier to parent them to a PVInstance than to go through the cloning & replication process that I noted above. I don’t see this issue as particularly problematic to force migration with, although I wouldn’t be surprised if it required a new class and deprecation of ViewportFrame, since current behavior is so widespread.
I think the benefits outweigh the negatives for how many use cases this change could mean for developers using ViewportFrames in experiences, and welcome any criticism/questions that stem from what I could have missed. I don’t have much to comment on reusing CanvasGroup’s textures, but doing much of anything complex with ViewportFrames increases difficulty exponentially.
I hope what I’ve written can help point things in the right direction!