ViewportFrame.Adornee

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
84 Likes

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.

17 Likes

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.

15 Likes

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.

2 Likes

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.

4 Likes

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.

2 Likes