We are having a bit of a weird issue with materials when initially loading into the world on our main character.
Every single time we fresh load into the world partition map the character has some sort of glow on it but it goes away after like half a second as if some shader variation as completed compiling.
We never had this issue in 5.4 and 5.5 but starting with 5.6 and 5.7 the issue has not gone away.
[Image Removed]
[Image Removed]
I can only reproduce this in the editor on a clean launch with no cache.
Is this a known issue somewhere with a potential fix?
Does this glowing effect only happen with certain specific materials? Would you be able to provide a small scene or a material asset to reproduce the issue? If that’s not possible, a short video (screencast) may help as it’s difficult to assess from the screenshots what the expected appearance should be.
I took a look at the material just now and the *only* possible way for this to happen is that *somehow* the virtual texture value *before* a virtual texture is streaming in is not coming in correctly.
The material has this node inside of it:
[Image Removed]
and the only possible way for this to make it glow that color as above as if this texture was to return 1.0 for the default value of the texture, so maybe in 5.6 the default value of a non-streaming in virtual texture is being returned incorrectly on level loads?
thanks for the update. It’s possible that the virtual texture’s default value in 5.6 differs from 5.5. In case you haven’t tried it already, you could confirm your observations is to change the color from orange to something else and to replace the virtual texture with a non-virtual version.
I could help debug this further, but unfortunately I haven’t been able to create a material containing the nodes shown in your setup with which I can easily repro the issue on my side. Would it be possible to share just the material (or a simplified version of it), which I can send to Epic for further investigation? This would also be needed to file an actionable bug report.
I have only seen this in the editor once or twice, and only with a fully clean shader cache aka not using the DDC cache at all, but inside a package game, I get it every single time loading into a world partitioned world from the main menu
Also I’m assigning this to a skeletal mesh FYI, so I dont know if its some sort of shader permutation issue where this only happens if its on a skeletal mesh. We havent observed this issue anywhere else except on our main character
Thanks for the additional information. I have assigned the material to a skeletal mesh in a world partitioned level with streaming enabled, packaged it and delted the DDC and DirectX shader cache, but unfortunately still have not been able to see the glow when starting the game.
Would you be able to provide a minimal project (starting from one of the game templates) where the issue can be reproduced? There might be something specific to your project which is missing on my side.
I don’t have any real way to test this inside a sample project but really it sounds like to me the virtual texture mask is being set to all white during loading first few frame
I’m pretty positive that someone changed the default behaviour that the default texture is white instead of black somewhere. I also noticed that when I make chunked packages, and a chunk is missing i would see *white* textures instead of black, so Im guessing that is indeed the issue.
We do need this issue fixed, do I need to make a confidential issue if you are not going to submit it to them?
I understand that you want this issue fixed, but this will be difficult without a way to reproduce it on our side. Making a confidential case does not change that fact, unless you can provide your project for debugging.
If you think this is a regression that occurred from 5.5 to 5.6 that you can easily reproduce the issue on your side, and you are comfortable with building from source, I would suggest trying to narrow down the range of commits/CLs that may be responsible for the regression using git bisection: first you pick a commit in 5.5 where the issue is not present (“good commit”) and another further in time (in 5.6) which has the issue (“bad commit”), then pick a commit halfway between the good and bad commit and test again, and discard one half of the range based on the test result. You can keep repeating this process until you have only a few suspicious commits to choose from (at that point it can be passed to Epic for further investigation). I have used this process before in another case to pinpoint the exact commit when a regression in Unreal was introduced, but in that case I was able to easily reproduce the issue. Reducing the range of commits can be quite quick since you can discard half the commits at every step.
I hope that makes sense. If you have more questions, please let me know.
Do you think you can point me to where the default textures are set for materials for virtual textures? It’s going to be almost impossible to do binary search on the epic commits to find the break point like that
from what I can tell, there is a line in VirtualTexturing.h which sets the fallback color for texture layers which are not ready yet to black, but I don’t think this is causing the issue:
However, I checked the commit history looking for related changes based on your description of the issue and found a commit that was introduced with 5.6 which changes the default Virtual Texture behavior in cooked builds to not wait on the render thread for root pages to be mapped. Instead the engine reads from an average fallback color generated during texture compilation which should remove render thread hitches.
If this change is indeed the cause of your issue, you should be able to revert to the old VT behavior by setting “r.VT.SyncProduceLockedTiles” to 1. This should wait for the VT’s root page to be mapped.
There is a bit more info in the comment inside ShouldSyncProduceLockedTiles() in VirtualTextureSystem.cpp which reads:
"If we return false then we may render with a VT before the root pages are mapped. When that happens the shader switches to using the single color fallback value instead of sampling the VT. When the root page is finally mapped we will return to normal high quality VT sampling.
todo[VT]: Make root pages always resident so that we never need to load sync the root pages."
Hopefully this helps. Please let me know if this works.
Thanks, I’ve created a simple project with this material. You mentioned that you can only reproduce this issue in the editor on a clean launch with no cache. I started the editor with the -clearPSODriverCache command line argument, but unfortunately I have not been able to reproduce the temporary glow. Are there any steps I’m missing?
thanks for the additional info. That sounds like a regression, but I have not been able to find similar reports. Unfortunately I cannot file an actionable bug report for this issue with Epic if I can’t reliably reproduce it on my end. Please let us know if you find out anything more about the issue or have a reliable repro case.
I think the part that is confusing for me that where its getting the average color from might not be working correctly because the issue we are having is on the emissive mask textures. The emissive mask texture is basically black with a few spots of white but its somehow averaging to fully white is quite odd which makes the entire thing glow.
Is it possible to set this color somewhere manually?