Texture compression artefacts

Hi,

I have a grid of several 2048x2048 textures. I want to display them in good quality, without seams and use progressive loading. But it seems compression won’t let me.

All textures are set to clamp. Otherwise there are wrapping artefacts at the seams.

All textures are 2048x2048 and I verified their highest LOD is actually being used by using the debugprogressive param.

I created a texture override asset and tested several combinations.

  • Generate texture LODs

    • Using “None” as texture format gives me an uncompressed texture which looks good but is fat and slow to load. No seams.
    • WebP, UASTC, ETC1S all give me the same blocky look.

      Diffing them in a graphics editing app actually only shows very minor differences. E.g. UASTC vs WebP (minor diffs, look closely):
  • Generate texture LODs :

    • “None” creates a seamless texure
    • WebP: Some compression artifacts but no blocky-blurriness as with LODs, no seams
    • UASTC: Some compression artifacts but not blocky-bluriness as with LODs, visible seams

Maybe you could help me figuring out what’s going on here. I don’t get why LOD0 is basically the same blocky mess in every compression format as soon as I enable LOD generation.

It sounds like you’re encountering issues with texture compression affecting the visual quality and seamlessness of your high-resolution textures. Based on the information provided in the context, here are some points to consider:

  1. Compression Formats: UASTC and WebP both produce noticeable compression artifacts, especially when compared to an uncompressed texture. ETC1S does not appear to be significantly better in this scenario.

  2. LOD Generation: Enabling LOD generation for large textures can lead to inconsistencies. The textures you mentioned are 2048x2048, which might require careful handling to avoid seams.

  3. Clamp vs. Wrap Modes: Given that you want to avoid seams and wrapping artifacts, setting textures to clamp mode makes sense. However, this might interact unpredictably with LOD processing.

To diagnose and potentially resolve the issue:

  1. Verify LOD Settings: Ensure that the LOD settings are appropriate for your specific use case. For a grid of textures, you might need to fine-tune the LOD distances and biases.

  2. Check LOD Generation: Disabling automatic LOD generation and manually configuring LODs might provide more control over the texture quality and seamlessness.

  3. Experiment with Compression: Try experimenting with different compression formats and settings. While UASTC and WebP introduced artifacts, ETC1S is worth revisiting, especially if you prioritize smaller file sizes.

  4. Debugging: Use tools like debugprogressive to monitor which LOD levels are being used and ensure they match your expectations.

  5. Alternative Solutions: Consider optimizing the textures for progressive loading without LODs initially and progressively increase detail based on viewport size.

Would you like to try any of these suggestions? Or do you have any more details about your setup that might help further?

Sources: Needle Engine Docs (71%), Needle Engine Docs (71%), Needle Engine Docs (65%)

1 replies left - Become PRO for more replies.
Reply to this post directly if you need further help (bottom right button)

  • Do you have a link to a demo to see the issue?
  • Can you share the “None” version for comparison?

Can’t share a demo, but I have screenshotted most of them for the purpose of diffing.

Here’s roughly the same area with “None” with LODs generated:

And here with WebP without LODs:

Can you create a minimal example that reproduces the issue and send that? It sounds like just an object with the problematic texture would reproduce the issue right?

Oh also: which version of Needle Engine are you using here?

4.16.6

I’m hesitant to upgrade to 5 right now because release is soon. But I could update the build pipeline using the exporter’s package.json if you tell me which version to use.

The build pipeline didnt change texture compression besides compression for EXR - it would not work with 4.16.6, do not update these independently.

If you could provide the bugreport we can look at it (probably not before next week tho)