Currently, to have a part appear in a ViewportFrame, it must be a descendant of the ViewportFrame itself. This is very limiting, for instance to have the entire Workspace in the ViewportFrame, you must clone everything into the ViewportFrame, and sync all changes made to Workspace to the ViewportFrame. It would be much easier to achieve this if you could set a property to tell the ViewportFrame to render all parts in Workspace rather than itself.
Even in a more normal case, it would still be beneficial. For example, when having a shop item appear in a ViewportFrame, you have to clone the item into the ViewportFrame. It would be simpler to set a property to tell the ViewportFrame to render all parts in the model rather than itself. This would save memory as the ViewportFrame no longer needs a copy of the model to render it.
This would also be useful to have two ViewportFrames render the same parts, without having to constantly sync parts and properties.
Example:
ViewportFrame.Adornee = workspace
-- now renders parts inside workspace rather than ViewportFrame
I actually proposed this back when it was released and I still find that it is a really limiting factor.
The main excuse was that they were meant or static models, but people don’t seem to understand that half of examples use them for some kind of a dynamic scenery, often already present in Workspace. Now we are forced to use even less efficient methods to achieve this.
This is still needed and for my case I cannot use ViewportFrames until a solution is found for this.
My games heavily rely on terrain, something that by itself is hard to deal with for ViewportFrames, but they are also massive open worlds some times.
Copying and syncing a game that by itself already requires streaming and a lot of optimization techniques to run into ViewportFrames for each ViewportFrame is absurd and causes any lower spec device to simply not run it well. It does not matter how well optimized the synching process is. Memory will always go up no matter what is done and the implications of constantly updating properties in a multiplication factor of how many ViewportFrames there are make it impossible to use ViewportFrames.
This is a very basic (albeit probably difficult to implement) problem, and ViewportFrames really need this if Roblox expects them to be used in larger games any time soon.
I store thumbnail models for viewport frames in replicated storage. To put them into UI I have to clone them out into the viewport frame. These models never change and can be made of many parts, so the lack of this property leads me to wasting memory and CPU time cloning models that already exist. Workaround is for the client to generate these viewport frames and cache them forever, but this is still a waste of memory.
I’m looking to make some overview CCTV cameras. Because they will be displayed as multiple at once, I cannot use the default camera for this. If I use ViewportFrames, I’m going to have to write a complicated wrapper that duplicates the workspace inside each of the ViewportFrame camera views.
This will take far more memory and Lua script usage than if I could simply set the ViewportFrame to render the contents of the workspace directly with the provided camera settings.
I want to be able to achieve something like this (see the video at the bottom) on Roblox without having to deal with having to clone everything into a ViewportFrame. There’s so many crazy neat things I could do with a feature like this.
Another related feature I would like to see is the ability to toggle on and off the renderer in a ViewportFrame.
When the renderer is on, it would act as it currently does: updates the image any time the camera or model inside changes. When the renderer is off, the image would be “frozen” as the last frame generated by the ViewportFrame, and would not change even if the Camera or model is changed.
For example, say I want to show 500 variations at once of a model where the only difference is color. I want them all in an intuitive ScrollingFrame.
Right now, I would need 500 copies of the model, one in each ViewportFrame. With the current Roblox engine, this is impossible: it takes about a gigabyte of memory, making the game unplayable on mobile.
But if I could toggle the renderer on a ViewportFrame…
What I’d do is place the model inside of a ViewportFrame, (or it’s Adornee if OP’s request is implemented) have it render, turn off rendering for the ViewportFrame, then change the model’s color and move it to the next viewport frame. Then repeat this process for the rest of the variations. That way, only 1 copy of the model ever exists in memory but I can create a thumbnail shot of many variations of it.
In this way, the memory cost is 1 copy of the model + 500 thumbnails. Contrast that with the current limitations of the Roblox engine, where the memory cost is 500 copies of the model + 500 thumbnails.
If this feature were implemented, it would find use in many other scenarios besides the one I’ve just described (which is a very common scenario as it is.) This could be useful any time you need to show a ton of images of instances - even if they’re all completely different models. This is because you could delete the model after getting a render of it, thus freeing the memory.
4 years later, this is still a very much needed feature.
ViewportFrames are currently useful mostly for UI applications, but anything regarding SurfaceGui usage becomes almost obsolete the moment you realize there is no easy nor performant way to render parts of the map.
Besides SurfaceGui, there are so many possible applications for this feature if it were added.
Security cameras, screen splitting (e.g. multiplayer games), weapon scopes, mirrors, (…)
It’s a shame how underwhelming ViewportFrames still are now that we’re in 2024. I understand this may not be a priority at the moment, but all I really ask is to at least consider this, as this would make ViewportFrames so much more usable.
Features like cameras are currently nearly impossible to achieve if your world has terrain or a large amount of parts, specially if you need to display avatars and NPCs on them as well as the world’s reaction to player actions.
The new Audio API has come to reveal this massive limitation in ViewportFrames even further. We will soon be able to transmit audio from parts of the world anywhere, but not display those parts visually.