Reproduction Steps
Create a part with a SurfaceAppearance inside of a ViewportFrame. Only the ColorMap is shown, not the Metallness or Normal maps.
Expected Behavior
It should appear as it does in the game.
Actual Behavior
It shows only the ColorMap, as if a Texture was applied.
ViewportFrame appearance:
World appearance:
Issue Area: Engine
Issue Type: Display
Impact: High
Frequency: Constantly
This is expected behaviour, ViewportFrames have no PBR/Shadow/Effects capacity and are not apart of the same pipeline. Even materials like glass and Neon get displayed at the lowest quality.
Thanks for the report. NormalMaps should already have an effect in ViewportFrames (I think I see it subtly in your video?), but metal objects look very different. This is because ViewportFrames don’t have the full set of lighting features the 3D view does - mainly they don’t reflect an environment map. They only reflect a uniform ambient color for the environment, which makes metals look like plastic.
We have some ideas to improve this, but VF improvements are currently on the backlog in favor of other projects.
We are working on adding EnvMap reflection contributions and more environmental contributions to ViewportFrame lighting. SurfaceAppearance is officially not supported currently in ViewportFrames at the moment.
I will change the status of this bug report to a feature request. Roblox will continue improving ViewportFrames in the future, so this will be considered moving forward as something people are asking for 
[Edit: Correction, SurfaceAppearance textures are supported to some degree.]
As you guys plan on improving viewportframes I would appreciate the ability to add multiple lights to one viewportframe and to be able to put baked lighting on to objects in them(each light has an id and each object can have some sort of texture with a lights id associated with it to bake shadows into viewportframes including coloured shadows the fact they are instances means they could be changed dynamically with an editableimage).
EDIT: Also a toggle to the new lighting contributions to improve performance on viewportframes that don’t need advanced lighting.
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.
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.
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.
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!
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
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]
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.
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
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
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.
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?
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.
