Still much to be expected, hopefully all of it can be addressed before its released to game servers.
Other than that, this is already so much better than the FFlag release a few weeks ago!
Each ViewportFrame will create a texture that costs 32 bits per pixel.
And it will also need one or two shared framebuffers depending on anti-aliasing level. For example, if a ViewportFrame is 200x200 and 4x MSAA is enabled, it will also use a 64bpp framebuffer and a 4x64bpp MSAA framebuffer with size 256x256. If no MSAA is enabled, only a 64bpp framebuffer will be used. These framebuffers are shared by all ViewportFrames sized from 129 to 256.
So for 10 ViewportFrames with size 200x200 and 4x MSAA, main memory cost will be:
(200x200x32x10 bits = 1.6MB) + (256x256x64x5 bits = 2.6MB) = 4.2MB
Much appreciated, to add to examples of use cases, here is a 3d map on the bottom left of the video, it’s just a flat cylinder and small parts to represent the 3d space relative to the ship
I don’t quite understand problem 1. The rendering order behavior should be the same with other GuiObjects.
What’s your GUI structure?
This is in PlayerGui
Video if it helps:
Currently ViewportFrame doesn’t support rendering GUIs inside. This feature won’t be added rencently. You can make it by moving those lables into ScreenGuis.
The stretching problem should be addressed in next week’s release.
I screwed up the last screen grab,
The attachments model during run time is in the menu gui, the ViewportFrame is in a frame under the menu as well but the attachments model is not in the ViewportFrame. So the issue is still that BillboardGui don’t render over the ViewportFrame, in my instance at least.
The size limit should be higher, like 2048x2048 pixels.
1024x1024 size limit is not enough for in game character customization screen using viewport frames.
1024x1024 is is not enough for those who have 4k computer monitors.
2048x2048 pixels is plenty.
woo! Now we can finally do stuff like this! (Something I’ve always wanted this for)
May be too ambitious lol I should probably just wait for multiple camera support
SWAT 4 for the win!
Might have to wait on that until Roblox adds in camera to screen support. 
The thing that Source games use to render things displayed on a TV.
Fantastic update!
I’m considering using ViewportFrames to avoid guns clipping in first person whenever this feature is live for games & lighting is supported for ViewportFrames (and in general when my Universe isn’t returning a 500 Server Error.) Everything looks great so far though!
Also discovered this by accident: 3D Skyboxes possibly?
I really like the idea behind the ViewportFrame. I think it’s really useful and removes the time of having to take pictures of objects and upload them as a decal. However, one feature I’m really hoping for is the ability to render a camera’s viewport on a UI during runtime. For example, in my theatre group I’d like to be able to display the stage from the audience view for the stage crew on a SurfaceGui. Another example would be security cameras for our security team. Both of these would be really useful, and I hope they get considered.
You explained what I was wanting to say earlier so much better than I could.
If we’re able to see what a camera sees through a SurfaceGui, the first thing I’m recreating is this.
It needs some way of projecting text onto 3D space. Otherwise I don’t have much of a practical application for it, unless I create a bunch of decals for each letter.
I am a day late but Module3D V6 is out. Hopefully, V6 will be the last major version. There may be a V6.1 at some point.
Are we not able to use Welds / Motors in ViewportFrames? Was trying to run animations on an object, however, I wasn’t able to 
I’m pretty certain that physics aren’t run in ViewportFrames, they only update when the Camera is updated so objects within them are frozen, by all means.
Dang, that’s too bad. Hopefully something could be worked on to allow some form of this? (Obviously I have no clue how difficult it really is to make… but still, I hope )
