Are ViewportFrames more/less efficient than images?

Help and Feedback Art Design Support
#1

I see the obvious convenience of ViewportFrames, but I have heard many people talking about lag with them. Would it be more efficient to use plain old images or viewportframes?

1 Like
#2

It would be more efficient to use regular images.

Viewport frames create something similar to a ‘regular image’ every frame. Rather than just downloading the image data and displaying it once.

edit: see @TheGamer101’s reply below

1 Like
#3

ViewportFrames are not necessarily inefficient, it’s just that they are performance heavy in large quantities. Images use less rendering power, which is why they don’t cause as much lag that the ViewportFrames do.

2 Likes
#4

What’s the point of ViewportFrames then? Sacrificing efficiency for convenience?

#5

ViewportFrames are for convenience in terms of development, but performance has to be sacrificed (to an extent). The old method that developers used (attaching models to the camera) was honestly a bit of a pain and I believe is more performance heavy than ViewportFrames.

#6

ViewportFrame is just another “workspace” with low quality rendering, no physics etc. They are just for display some small objects for preview without uploading photos and players can interact with those objects (rotate, zoom etc.)

11 Likes
#8

ViewportFrames unlock a portal to another dimension. whole variety of different uses. You can create split-screen games. You can create on-screen secondary camera systems (think security cameras on your screen or something).

You can create more accurate ADS gun-sights.

Possibilities are (nearly) endless with the addition of ViewportFrames. You just need to use your imagination.

4 Likes
#9

This isn’t true, the ViewportFrame does not need to re-render unless something changes such as the object in the frame or the position of the camera.

20 Likes
Do Viewport Frames render when off Screen?
#10

This is more than a bit of an exaggeration, it’s hugely misleading. I tested a UI with 120 ViewportFrames on screen showing hats and there was no impact on framerate. Microprofiler didn’t even flinch. It’s cheaper than rendering those same 120 hats in world on players, by a lot.

12 Likes
#11

My apologies :face_with_hand_over_mouth:
Post deleted

2 Likes
#12

Notes / Performance

Here are some important considerations for creating viewport frames:

  • Each ViewportFrame will create a texture for rendering. The texture has a max size limit, so if the frame is too big, the contents may look blurry.
  • The viewport will only update when its children (camera or objects within) are changed.
  • Moving a viewport’s physical children is less performant than keeping them static. If you need to update the view, it’s better to move the camera than move the parts/models.
  • ViewportFrame is not designed for rendering a large number of complex objects — it may be slow if you put too many objects inside.
  • Objects inside viewports will be rendered using a fixed lighting setting, although more options may become available in the future. No shadows or post effects are currently available.

These notes suggest that:

  1. ViewportFrames may be comparable to plain old images as far as texture memory goes if VPFs replace images 1 for 1.
    However, if a ViewportFrame overwrites its “texture for rendering” when the view changes, then one or more VPFs in something like a shop gui could potentially use a lot less texture memory (if they are reused to display more than one item) than a comparable setup using just images. This could be very beneficial for devs who routinely create and upload tons of images that are used for display purposes (as opposed to textures).

  2. VPF’s usefulness for things like split screen games or secondary camera system may be limited to a cases where the VPF’s texture size limit, texture overwriting when view changes, lighting limitations, and restrictions to nbr of objects in view aren’t an issue.

  3. The ideal use case would be to have a single VPF that displays static models one at a time (pets, furniture, weapons, etc). The VPF could display (sequentially) a huge number and variety of objects with virtually no impact on texture memory (colors, angle with respect to camera, attachments, and so on could be changed for any given model to allow for exponentially increasing variety).

Does that seem about right?

If so, VPFs are potentially way more efficient as far as memory goes. If the view inside a VPF doesn’t change (the texture for rendering isn’t being updated), then other aspects of performance (lag) may be comparable to regular images for many applications. If your game needs to display only a handful of objects, or if you need better/different lighting for the images being displayed than what a VPF supports, then there are arguments to be made for using plain old images. There are probably a bunch of these cases. Where the VPFs are better, they appear to be way better. How would you capture images of models or players that have been modified in-game with plain old images?

17 Likes
#13

Very well said by @Astr0Derp. ViewportFrames have their own uses, so comparing them isn’t really too important. Astr0Derp did compare beautifully, however. The most important part to remember is that they don’t re-render unless you make a change.

One thing I’d like to add to this thread is that you all seem to think of ViewportFrames as an alternative to ImageLabels. It can be, but that isn’t the main usage.

All the uses I’ve seen (and created) would be impossible/terrible with ImageLabels.

Let’s go through some uses, shown off in this blog post and on the DevForum.

  • A shop GUI that spins the item in a frame

This can be done with spritesheets. That’s a total pain, and not a great use of your time.
ViewportFrames allow you to easily do this. If you keep the object static and only spin the camera around it, it costs about as much as changing the ImageLabel (afaik). Certainly not worth “microoptimizing” and using ImageLabels.

  • A 3D minimap

How could you do this with ImageLabels? You’d have to have an image for every possible angle and situation. Not feasible.
A ViewportFrame makes this both possible and performance friendly if done correctly.

  • Character viewer

ImageLabels can’t really do this, since you’d need sprite for every character option in every single possible position.
ViewportFrames do this quickly and easily, with decent performance.

  • Dual Render Scope

Granted, this is a bad idea for both options, but at least ViewportFrames are capable of doing it.

  • Camera Systems

ImageLabels can’t do this, ViewportFrames can.

  • XRay Highlighting

Yet another one that is only unlocked via ViewportFrames.

I think the point is made.

10 Likes
#15

it could be your pc is just too good
i tried the same thing you did and my frames dropped especially when i made the object spin over and over

#16

As @Astr0Derp and @boatbomber said you should rotate camera instead of object itself. Read carefully next time! :wink:

2 Likes