good to know that CVar change caused the issue. The code that creates the fallback color for virtual textures that have not streamed in fully yet is in two places in FVirtualTextureDataBuilder::BuildLayerBlocks() in VirtualTextureDataBuilder.cpp. Look for the following code which appears twice in the file:
// Extract fallback color from last mip.
{
// this actually just samples one pixel ; it comes from last mip so it's often small already
// @todo Oodle : just use a "get average color" function
FImage OnePixelImage(1, 1, 1, ERawImageFormat::RGBA32F);
BlockData.Mips.Last().ResizeTo(OnePixelImage, 1, 1, ERawImageFormat::RGBA32F, EGammaSpace::Linear);
OutData.LayerFallbackColors[LayerIndex] = OnePixelImage.AsRGBA32F()[0];
}
As you can see from the comments, the code is actually just sampling the texture’s smallest mip instead of calculating an average. You could implement some logic here that averages the pixels of the smallest mip and replace the fallback color (OnePixelImage.AsRGBA32F()[0]).
This makes sense, I think knowing this now we can probably adjust the shader to be more correct, we are *multiplying* the output of the texture sample by an emmisive color thats like (4.678502, 0.5, 0) which means that even if this pixel value is 0.01 it will make the entire thing glow.
I dont think changing the engine to do the average color will solve this issue for us because of what I said above for the shader.
Thanks for the help, I will try fixing the shader tomorrow
I just wanted to add one comment here is that it would be amazing *if* we could set the fallback color in the virtual texture settings. Now that this is enabled by default, most people will not understand what is going on and is going to cause a lot of visual artifacts for people when loading into maps, but if a user can set it to fall back to black, that would probably solve a lot of these issues.
