Hi,
I’ve been looking at decal rendering and the issue with textures being blurry when Never Stream is disabled. Memory is tight for us so having loads of decals permanently loaded isn’t possible.
I’ve come across similar issues on the forum with some broad information on workarounds:
[Content removed]
[Content removed]
<br>
I’ve looked at implementing a custom UPrimitiveComponent with GetStreamingRenderAssetInfo/ShouldCreateRenderState implemented as per the latter link information.
I have a Blueprint with a Decal and DecalStreamingHelper (new UPrimitiveComponent).
The DecalStreamingHelper contains implementations of GetStreamingRenderAssetInfo and ShouldCreateRenderState functions.
The problems I’m hitting seem to be timing based, for example: setting the Decal to track (on the DecalStreamingHelper ) during EventBeginPlay is too late so we never hit GetStreamingRenderAssetInfo. I’ve tried numerous workarounds but none have been successful. The latest is to drop the BeginPlay and use a FComponentReference to allow the new UPrimitiveComponent to reference the Decal from within the BP (I can’t see any other way this can be done?). I setup the FComponentReference during the GetStreamingRenderAssetInfo Constructor and the PostLoad(). I’ve had to hack in a call to Register the component during PostLoad, which seems hacky and only seems to work on some levels (they’re all WP levels).
Is there any reliable way to get the BP or DecalStreamingHelper to set a reference to the Decal to be tracked? Or should I drop this line of development and try something else? Is there any prospect of Epic fixing this issue? (seems unlikely at this stage as it has been around since 4.x).
Thanks,
Lee
Hi,
I’ve looked at the links and have been trying to reproduce your issue on my end (using UE5.5.4) but without success. Would you mind sharing a minimal project that shows decals being blurry when closeby? That way I can investigate it easier and potentially raise a bug with Epic.
Thanks,
Sam
Not the OP, but we have seen this issue before and for us it was caused by the same texture being used in both a decal material as well as a normal static mesh material within the same level.
The streaming information for the static mesh takes precedence over the decal’s texture streaming through the fallback path for “unknown” textures, which means the mips for that texture will always be based on the distance to the static mesh only.
So if the static mesh using the texture is far away, but the decal is close, the higher mips are not streamed in correctly.
Hi,
thanks for the reply. I noticed having the decal texture used on geometry seems to cause the issue to happen, especially in simple test level cases. When used in a very large complex level, I’m seeing the same issue and using the reference viewer I can see the decal texture being used on anything but decal actors. The level isn’t hitting the texture pool limit I’ve set so it’s not that. At the moment I’ve got a workaround that forces all the mips to load but allows device profile settings to allow stripping of mips at cook time (something that NoStream doesn’t seem to honour).
Thanks,
Lee
Thanks a lot for finding that out. I would like to file a bug report for that with Epic, but unfortunately I haven’t been able to reproduce it: starting from the blank landscape scene, having a decal actor on one end and a cube with a material using the same texture at the other end, the decal doesn’t appear blurry (the texture has Never Stream disabled). Would you mind providing some repro steps?
Thanks,
Sam
Good to hear you found a workaround for this issue. I would still like to know how to replicate it on my end. If it’s a reproducible bug, it can be reported to Epic and increase the chance of being fixed.
Thank you,
Sam