I’ll take note of this personally, but the way I see it, the best thing to expect is for ViewportFrames to asymptotically achieve the same features as the Lighting class, though nothing is final.
2 Likes
As long as we can use viewports as we can now with no visual difference I will be happy.
EDIT: and most importantly performance impact.
Technically everything I asked for in the first section is doable already but needs multiple viewportframes meaning that it is smeary and low fps.
1 Like
I stand corrected, SurfaceAppearances should be supported to some degree. I’m going to take a look at this again. Stay tuned for updates. @AbstractAlex.
I would appreciate if you had a repro file that you could send in this devforum post or privately if you’d prefer.
This should be made better when we get to ship some improvements in ViewportFrames, but I would wanna keep an eye on this if it gets fixed with the new features in development. I would appreciate this repro case just to see what it looks like if more PBR-adjacent lighting is added.
1 Like
I don’t have a repro on hand right now (I made this post over 2 years ago 
) but if you need one I can try to throw something together!
1 Like
Would be awesome so I can figure out what things look like right now. And thanks for waiting two years.
pbrviewportframerepro.rbxl (59.9 KB)
Here’s a repro file, normal maps and albedo appear to work but the rest of the PBR textures seem to not work
3 Likes
I can confirm roughness maps, among other things, in surface appearance should be making more visual contributions in some new stuff we’re working on in ViewportFrames, so watch out for that when it comes out.
As far as I can tell, the current behaviour is expected, so I’ll move this into a feature request. Thanks for the repro case. Watch out for patch notes mentioning “improvements in environmental lighting contributions in ViewportFrames” in future client/studio releases.
[TLDR: I am changing this to a feature request. The feature should already be in development from what I can gather]
3 Likes
I have models that use surface appearance extensively, it’s definitely very limiting if those meshes would display lower in quality within a Viewport Frame.
So a feature should be rolling out soon that tackles this. Look for the following in patch notes for studio.
- Enables fixed IBL EnvironmentDiffuseScale and EnvironmentAmbientScale when a Sky instance is a child of ViewportFrame. This also sets the Skybox in the child Sky instance for reflections and environmental contributions in the ViewportFrame.
4 Likes
I never remember seeing this as an property of Sky, only EnviormmentSpecularScale. Could you clarify?
Aside from that, these changes look great and they’ll open up a big graphics upgrade in ViewportFrames
1 Like
It does not reference the specific property on Sky. It’s more like the lighting in viewport frame will mimic a specific EnvironmentDiffuseScale and EnvironmentAmbientScale lighting property.
Updated docs should now be out Frames | Documentation - Roblox Creator Hub
3 Likes
Is this behaviour disabled if a sky is not present inside the viewportframe?
A feature I really would like to see for viewport frames is if we can have them output a float buffer instead of an integer buffer so that we can have hdr(IMPORTANT IT SHOULD NOT BE TONEMAPPED) imagery from the viewport frame so if I were to add multiple viewport frames layered ontop of each other to add extra lights to my viewport frames I wouldn’t have each light become dimmer each time I add another light to the setup as i could counter it by making the lights brighter hdr output is required for this to avoid the lights brightness being clipped.
EDIT: Alternatively uncap the colour3 property of canvas groups to allow us to make the contents brighter.
1 Like
Would it be possible to let developers configure the EnvironmentDiffuseScale and EnvironmentAmbientScale values on a per VIewportFrame basis, rather than them being locked to 1?
2 Likes
I found a bug with the skybox support the faces of the skybox are not properly placed to get a correct skybox reflection you need to map your sky textures as so: bk = rt, dn = dn, ft = lf, lf = ft, rt = bk, up = up. This should probably be fixed as it isn’t intuitive to map your textures like this nor does it match up with the behaviour seen with regular lighting.
The way it matches up is correct if you use a camera in the viewport frame to move your object around. The default camera view might make the orientation seem weird.
It follows the same orientation as the world camera view with the skybox faces in the same place relative to wherever your camera is looking.
In the viewport frame they appear rotated the remapping fixed the rotation of the skybox faces I never tested if the objects reflect the correct face on the correct side and I used the studio camera as the current camera in the viewport frame to test it so it isn’t a camera thing. lemme show you what I am on about and it is in your image so I will just use your example with some markings to show what I am on about:
EDIT: Sorry for the late reply.
No worries, I misunderstood at first. Am working on a fix. I used skies with clouds a lot when doing this so I must’ve messed the orientation up.
1 Like
Thanks for confirming, I’ll declare this whole thread officially all handled by EOD.