ViewportFrame Release


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…?

1 Like


That’s just an optical illusion - Mind you, a non orthographic camera will show depth rather obviously when used like this.



Another issue i’ve run into is tweening models inside of a ViewportFrame…

I tried using Motor6D objects to tween a model yet only one part moves. In the workspace, this method works fine… Is there another method for tweening objects inside of a ViewportFrame?


split this topic #298

A post was merged into an existing topic: Featuring early adopters of Roblox technology

1 Like


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 :thinking:



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)

1 Like


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 :confused: 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.

1 Like


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 themimage



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:

1 Like


Two things:

  • that doesn’t really tell us much about how the actual object works! I’m guessing it would be like a mini Lighting service, but it would be nice to elaborate on the functionality so we can discuss it further!
  • am I going mad or is the entire image slightly desaturated?
1 Like


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.

1 Like


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.



Unfortunately I’m not allowed to make posts in suggestions, I think it’s because I haven’t made any new topics yet since I’m still trying to grasp how the devforum works.

Also if you enlarge the image you will see that there is an Adornee for any LightingObject (also yeah, it’ll probably just be that you can insert multiple Lightings vs a unique object for it)

(The only reason I thought of making them separate objects was because of the new “Future is Bright” which I believe shouldn’t really be used for ViewportFrames since like previously stated, weren’t really intended for massive HD projects.)