After messing around with ViewportFrames I came to a very important conclusion: You can get around rotated images not being clipped by GUIs.
In practice:
Let’s say there’s a minimap/radar/etc. that rotates with the player. Normally you can’t use images like this with rotation because it doesn’t get clipped. With ViewportFrames, this is no longer a problem, and you can make proper minimap images that rotate with the player.
Whilst working on a game, i’ve noticed a very minor yet annoying white outline around any model placed inside of a ViewportFrame.
Not sure if this has been addressed already, but if there is any kind of workaround, i’d love to know!
Yet again, this is a very minor flaw but I find it slightly degrades the quality of my game.
That outline is due to antialiasing. It’s always the same color as the BackgroudColor3 property of the ViewportFrame. There’s no workaround.
Try your best to match the BackgroundColor3 property of the ViewportFrame with the color of its background or to the color of its contents to hide the outline.
Try getting around this with an extremely low field of view camera at a distance. This seems to compress out or totally remove a large majority of the antialiasing. You’ll also want to make sure that the viewportframe isn’t too big, IIRC the maximum resolution was something like 1024x1024…?
That’s just an optical illusion - Mind you, a non orthographic camera will show depth rather obviously when used like this.
This is a well needed feature and can open up new opportunities for developers to use in their games.
I wonder if you could use ViewportFrame to make a Camera/Screenshot system and use datastores or something to store the environment and camera data 
Yes, you can. However, you’d need to save positions and object data in order to recreate them when loading. I’m excited to see someone do it.
I was thinking of trying it, you’d enter “camera mode” by pressing a key or GUI button that would duplicate everything in Workspace into a ViewportFrame (but only one time, not every frame so it wouldn’t be that intensive) and you’d basically be in first person, you take your screenshot (in the paused environment) and it will save it to a datastore.
Then whenever you need to view it, it would bring up a loading screen and generate a ViewportFrame with the datastore previously.
I think it could work.
EDIT: If you wanted to clean it up you could use that camera function (I forgot which one I think it’s WorldToViewportPoint something) and remove parts not in your view. (and maybe use magnitude and remove parts too far away)
The problem at the moment is that, although this idea is good, when you capture a frame, the render is limited graphically.
To store this effectively you’d need to compress the world data into a string that you could encode and decode.
Like converting a table with Json, but with a lot more information.
Dang that sucks 
surely there must be an efficient way?
Yeah, write a compression algorithm for converting part data to string.
You could also try the Json method, I haven’t tested it yet.
Assuming this is a bug but please correct me if I’m wrong.
It seems that viewport frames don’t display surface gui’s?
Seen here is a screenshot of a train I’ve built, being viewed in a viewport frame. The headboard and number at both blank but in game they indeed have text on them
It’s not supported intentionally for now:
I don’t know if anyone has suggested this but I spent like 5 minutes making a mock-up of how Lighting could work with ViewportFrames:
Two things:
Thanks, and I don’t believe it is desaturated? But I have weird monitor applications that alter the colours and stuff so it might be some software doing that, I do know I made the LightingObject’s icon black and white though, I was going to make a new icon but I ran out of time.
And basically it would be identical to the Lighting object. It’d allow you to have a splitscreen with one part of the screen day, and the other night with a different skybox for example. But it’d mainly be useful for ambience.
I also made the image for when PointLights, SpotLights, Neon etc are implemented.
Edit: In hindsight, it is a little bit unnecessary when it could be properties under the ViewportFrame itself, but I think it’d be more simplified if a developer simply wants to make icons vs someone who knows their stuff and is trying to make portals.
I’m all for an object like this for organisation purposes! Thing that I might want to suggest tho is the ability to point at any LightingObject instance from within a ViewportFrame, similar to how an Adornee property works, to be able to specify how the lighting should look using common objects, or maybe even the Lighting service itself if Lighting were to extend this object.
In any case this should probably be made into a separate suggestion thread.
