protonscr

Portal 2 has the wrong textures confirmed on Nvidia and AMD

steamclosed reviewedMOVED: Portal2Need Retest
ValveSoftware/steam-for-linux#4414 · opened 2016-04-21 by LiamDawe · updated 2017-01-25 · 8 comments · github
LLiamDawe 2016-04-21 github

I have been livestreaming my playthrough of Portal 2, and it seems levels near the end have the wrong textures, or shadows are somehow messed up.

See some screenies:
http://steamcommunity.com/sharedfiles/filedetails/?id=669855563
http://steamcommunity.com/sharedfiles/filedetails/?id=669855520

It seems setting "mat_specular 0" does indeed fix it.

Someone tested it on AMD while I was livestreaming to confirm, they also have the issue.

Computer Information:
    Manufacturer:  Unknown
    Model:  Unknown
    Form Factor: Desktop
    No Touch Input Detected

Processor Information:
    CPU Vendor:  GenuineIntel
    CPU Family:  0x6
    CPU Model:  0x3f
    CPU Stepping:  0x2
    CPU Type:  0x0
    Speed:  3500 Mhz
    16 logical processors
    8 physical processors
    HyperThreading:  Supported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Supported
    SSE42:  Supported
    AES:  Supported
    AVX:  Supported
    CMPXCHG16B:  Supported
    LAHF/SAHF:  Supported
    PrefetchW:  Unsupported

Network Information:
    Network Speed:  

Operating System Version:
    Ubuntu 16.04 LTS (64 bit)
    Kernel Name:  Linux
    Kernel Version:  4.4.0-18-generic
    X Server Vendor:  The X.Org Foundation
    X Server Release:  11803000
    X Window Manager:  Compiz
    Steam Runtime Version:  steam-runtime-release_2016-02-23

Video Card:
    Driver:  NVIDIA Corporation GeForce GTX 980 Ti/PCIe/SSE2

    Driver Version:  4.5.0 NVIDIA 364.16
    OpenGL Version: 4.5
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x10de
    DeviceID:  0x17c8
    Number of Monitors:  2
    Number of Logical Video Cards:  1
    Primary Display Resolution:  3840 x 2160
    Desktop Resolution: 5760 x 2160
    Primary Display Size: 24.45" x 13.43"  (27.87" diag)
                                            62.1cm x 34.1cm  (70.8cm diag)
    Primary Bus: PCI Express 16x
    Primary VRAM: 6144 MB
    Supported MSAA Modes:  2x 4x 8x 16x 

Sound card:
    Audio device: Realtek ALC1150

Memory:
    RAM:  15946 Mb

Miscellaneous:
    UI Language:  English
    LANG:  en_GB.UTF-8
    Microphone:  Not set
    Total Hard Disk Space Available:  204289 Mb
    Largest Free Hard Disk Block:  155032 Mb
    VR Headset: None detected
Llibcg 2016-11-08 github

Hitting this issue on Mesa with radeonsi and llvmpipe drivers. https://bugs.freedesktop.org/show_bug.cgi?id=98002

Mmtmkls 2017-01-11 github

Is there an ETA on the fix for this?

Sstevethepocket 2017-01-15 github

This isn't a Linux thing; I've been seeing this exact thing in Windows too, as of some time last summer when I fired it up to try out my new Steam Controller. To further elaborate, because static screenshots don't make it clear, this is caused by overly-bright cubemap reflections. Two material files seem to be at fault, nature/blendrockdirt_tunnel03a and nature/blendrockdirt_tunnel03b. Here's a screenshot of the latter in action in the following map:

portal2shiny

And incidentally, here's what it looks like with mat_specular 0, which is much closer to how it's supposed to look:

portal2unshiny

Anyway, I think I know exactly what's happening, although I'm at a loss as to why. See, both these materials reference an envmap called cubemap/cubemap_cave01.vtf. This is what it looks like:

cubemap_cave01

There also happens to be, for some reason, another file in the same folder called cubemap_cave01.hdr.vtf that doesn't appear to be referenced anywhere. Here it is:

cubemap_cave01 hdr

That's way brighter, isn't it. What's interesting is that I've found other "HDR" cubemaps, and they all use an underscore rather than a period to separate the "hdr" part.

Here's my hypothesis: Something changed sometime in the last year or so that made the engine look for the first period rather than the last one to split a filename from its extension. So instead of a VTF file called cubemap_cave01.hdr, it thinks it's seeing an HDR.VTF file called cubemap_cave01. And because HDR comes first alphabetically, it ends up pulling the wrong file. Does that make sense? I tried testing this by manually copying all the files involved into my materials folder, renaming the cubemap texture, editing the materials to reference the renamed version, and running mat_reloadallmaterials, but nothing changed. I don't know if the game is just blocked from overriding materials or what. I think the only way to know for sure is to just rename the offending file in the VPK. I don't have the tools to modify VPK files on the fly, so it's all up to you now, @davidw-valve .

...Ugh, I stayed up way too late figuring this all out.

Sstevethepocket 2017-01-19 github

OK, confirming that this has the same problem on my Linux setup, which hasn't seen any changes in months aside from updating to the latest Steam client. Recommending moving this issue to the Source 1 section so it can be looked at by the appropriate individuals.

Kkisak-valve maintainer 2017-01-24 github

Per "- Fixed a full-bright material in cavern areas." in the 2017-01-24 Portal 2 update, please retest.

Sstevethepocket 2017-01-25 github

Well, it's fixed for me, even though none of the files I mentioned appear to be changed. So out of curiosity — and so I can be more effective diagnosing stuff like this in the future — did it turn out it actually was indexing the wrong file, and you fixed whatever engine bug was causing that?

Llibcg 2017-01-25 github

I can confirm the game is rendering correctly now. Thanks for fixing it!

Kkisak-valve maintainer 2017-01-25 github

I've passed the question on @stevethepocket. Thanks for retesting, closing.

Nothing extracted yet.