This is definitely something that will be useful in the future for a more immersive gaming experience! What a nice addition!
You’ll probably be loading the mesh & texture eventually anyways. Using an ImageLabel actually just increases download size in that case.
1 Like
Something to be aware of wrt ViewportFrame is that even though the image doesn’t get re-rendered unless it needs to be, it has to be stored in memory and the memory impact is larger than that of static images on mobile, because for static images we’re able to use efficient texture compression.
For example, a 128x128 frame on mobile will take ~64KB as a ViewportFrame and ~20KB as a static image, assuming it has alpha. If you have 300 images like this, you’re looking at 19MB → 6MB reduction, which is helpful for low-end devices.
17 Likes
This would work well with inventory systems. But, I can’t script the part / model to spin which is annoying. (Well I’m positive that’s the case)
It’s faster to spin the camera itself anyway. This works especially well when you want to make multiple, similarly-sized items spin since you can make it so that they share the same camera. Try doing that, instead.
1 Like
I find it weird that ViewportFrames can only render stuff that is placed inside them. Instead, they should have a Subject value, which is set to itself by default. This would allow us to render objects already present in the workspace without having to clone them every time.
21 Likes
This would make a lot more sense and would certainly improve performance, and may also allow much quicker creation of TV screens & the like, like the BreenCast in Half Life 2.
4 Likes
Currently I have to clone things to them and then update the cframes every frame, so a subject option would be much much better lol
3 Likes
I have a mirror module. It works alright for intermediate sized maps with 5 mirrors, but anything beyond is just a horror to witness (below 30FPS without other scripts).
1 Like
This also means that you’d need to have every single object you want to render as a single model since this subject value can only hold one instance. This would over complicate things. Right now it works like a isolated workspace which is really good IMO. Why complicate things?
1 Like
Then a userdata of some sort? The current implementation limits this extremely useful feature to nothing but minimaps and model previews. The “Viewport” in the name itself implies that it’s supposed to project a 3D space onto a 2D rectangle, basically acting as a second camera, which it practically can’t do without extremely memory and performance expensive hacks.
Also, you saying that a “Subject” property would limit the usability to objects that have the same parent, but the way it is right now we can’t even have that without copying the thing for each ViewportFrame.
4 Likes
In that case what you’re asking for is Render Texture. Not a Viewport Frame. Either way tho, the more cameras you add in a game engine the higher the cost will be for performance.
Especially when they’re trying to maintain the current workflow of development especially when it comes to the API. Having objects inside of the Viewport Frame itself keeps the objects from being rendered in the world.
I mean they could’ve just had the subject property like you wanted, and you simply put the objects off screen in some obscure location away from the origin so the player can never find it. And then have that show up on the viewport.
But they opted for an isolated workspace (not the game.workspace, but I’m refereing to an actual workspace where you work.). Personally If they ever decide to instance the smooth terrain I can see us eventually being able to add a terrain instance to the viewport frame in order to get a rather low poly view of terrain on the Viewport Frame.
Anywho. The Viewport Frame does have its pros and cons. But at the end of the day it was built to solve a specific problem. It’s not perfect. It could be better. But you can’t really complain about something not working the way you wanted it to when what you’re wanting to do is beyond the use case this feature was built to cater to. Mirrors for instance… is one of those.
Personally I’m still hoping for render texture.
3 Likes
A viewport is a “region of the screen used to display a portion of the total image to be shown”. That is the definition of a viewport in 3D graphics and it clearly explains that a viewport is just simply a rasterisation of your 3D scene from the viewpoint of a rectangle, or put it simply, just one of your cameras.
A “RenderTexture” is just a feature present in Unity which should rather be called a “ViewportTexture”, since that is exactly what it does. It takes an image generated by a viewport and wraps it around a mesh of your choice.
My solution will still allow you to isolate a specific object by parenting it to the ViewportFrame itself just like we can right now. What I’m saying is that you should be able to select models already present in the Workspace as well, especially since what most stuff people are trying to use it for is already present in the game, so there is no need to clone it. This way, you have a double use for the same class: being able to show a specific model on the screen without having to clone it, as well as being able to add a 2nd camera to your screen.
As for the performance issues almost everyone is screaming about. What stops the developers from creating an insanely over-complicated and laggy implementation by constantly updating the CFrame of the wanted model, especially characters? Nothing! I did it and I might use it in my games just for the sake of being able to do this without any alternatives.
3 Likes
Wow, that open up a lot of new possibilities. So, is it possible to take a “CCTV” system that can get uploaded to a third-party website and viewed online since it creates texture for rendering?
The problem is that the “textures” are still objects, but if you manage to store data for each frame, then yes. I recommend setting up when objects appear and tweening them using a set of values it tables of some sort.
You can’t access texture data (as in, the colors of the pixels themselves), so no.
How exactly do you make it “take a photo”? And also I seem to be the only one who can’t make SurfaceGui and BillboardGui ViewportFrames render anything at all
You have to place the SurfaceGui in the PlayerGui/StarterGui and set its adornee to the Part you want to render it on.
2 Likes
Wow thanks a lot! I don’t think I would have found that out on my own. Would you also know how to “take a picture” like in the post?
The way ViewportFrames work is that they render whatever is parented to them. To take a picture, just clone whatever you want to be static and it will stay that way, unless you move it with a script.
Also, forgot to add that you have to create a new Camera and copy your current camera’s CFrame to it. Set the ViewportFrame’s CurrentCamera value to the new camera and then you’re done.
1 Like