Hitting this issue on Mesa with radeonsi and llvmpipe drivers. https://bugs.freedesktop.org/show_bug.cgi?id=98002
Is there an ETA on the fix for this?
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:
And incidentally, here's what it looks like with mat_specular 0, which is much closer to how it's supposed to look:
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:
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:
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.
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.
Per "- Fixed a full-bright material in cavern areas." in the 2017-01-24 Portal 2 update, please retest.
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?
I can confirm the game is rendering correctly now. Thanks for fixing it!
I've passed the question on @stevethepocket. Thanks for retesting, closing.
Nothing extracted yet.
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.