ViewportFrames with a Sky instance take an incredibly long time to render the reflections

Using a Sky inside of a ViewportFrame takes a long period of time for the reflections to render. Changing the visibility of the frame or updating the viewports restart this time. It loads them one after another, which makes them not very usable in any quantity higher than one.

At first I figured maybe it was due to the texture being too high resolution, so I uploaded a 1x1 black dot as the texture, and that didn’t change anything.

This happens in Studio (play test & edit mode) & in the live build.

PC Specs

Processor Intel(R) Core™ i7-14700K
Video Card NVIDIA GeForce RTX 3060
Operating System Windows 11
RAM 32 GB

Expected behavior

I’d expect the viewports to load near instantly, and to properly cache the reflections image (or something similar) so that it doesn’t need to reload unless the model itself is changed.

Viewports look so much better with these reflections, and it’ll benefit me a lot to be able to use them properly.

A private message is associated with this bug report

1 Like

I wasn’t gonna originally post anything about this, but some folks at RDC who work on engine stuff said I should, so here we are.

Could I please get the .rbxl file associated to this post?

1 Like

I included one in the private message, but I can just post it here too.

ammotest.rbxl (102.7 KB)

1 Like

You can really see how much of a difference it makes to have it. I think this feature is absolutely critical for viewport frames, and having that delay is a real bummer.

Without reflections
RobloxStudioBeta_g7eXpSQlWD

With reflections
RobloxStudioBeta_pxJEHxEJcD

Any word on the status of this?

1 Like

This rbxl file seems like it really pushes the viewport frame envmap system by having more than a dozen active at a time.

A recommendation on fixing your issue specifically would primarily be to subdivide a single sky and viewportframe (vpf) somehow instead of having a grid of them. You can likely achieve the grid look through other means and by scripting items in and out of the viewportframe instead of hiding the vpf itself.

Fixing this would involve a much bigger change. This seems to be more of a feature request to me. My team will take a look and triage this still.

2 Likes

I don’t think it’d be possible in my case to do that method, but I appreciate your response. It’s a disappointing answer, but I hope in time it can be improved upon.

Ill still work on this. I’m of the opinion that people generally want reflections in vpfs and dont really need different or high quality envmaps for that matter to have it in there.

Id imagine a fair number of people just have the same small envmap faces across many vpfs in order to generate something like what you did here. @LeBoogle

1 Like

Hi! Very coincidental timing for me, as I had just come across the same issue.
I would like to denote, though, that even without such a high-stress scenario like above, it still takes a significant amount of time for the skyboxes to load. Our game has just four viewportframes with skyboxes in them, and yet it nevertheless takes a significant amount of time to load. Here is a demonstration:

There’s no way to tell when the viewport has fully loaded in, either.

Regarding the above conversation of only using one vpf, I’d like to mention that I had actually tested out this exact scenario a few weeks prior; though not because of trying to fix the skyboxes, but rather in an attempt to improve viewport render performance. I had thought that using one viewportframe over six smaller ones would make it perform better, however that was not the case – it actually performed worse! As such, it’s unfortunately also unrealistic to try to temporarily fix this issue by using one big viewportframe.

If anyone’s interested, I detailed a twitter thread on my exploration on this: twitter.com

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.