Automatic generation of texture resolution variants

[lnm95]

I noticed that the documentation recommends using 4K textures with mipmaps for 2D, which sounds extremely inefficient. For FHD users, texture sizes increase sixfold to benefit only a small number of 4K users (~5% according to Steam).

I’ve already seen suggestions to override textures via .pck patches, and I believe the engine already has everything needed to support this. However, there are several issues that make this approach impractical:

1. It forces you to avoid Expand Mode: Keep Size and manually set the minimum size for every single texture.
2. You would need to manually maintain 3+ separate projects with different texture variants, or write a generator to produce those projects from the main project’s resources.

This looks like a headache, but it should work out of the box.

Proposed solution:

Settings

Add Texture Variants to Project Settings / Globals, representing a set of presets, for example:

ui:
  - fhd: 0.5 (native)
  - qhd: 0.75
  - 4k: 1.0
game:
  - lowres: 0.5
  - highres: 1.0 (native)

The resolution marked as native should be used in the editor, and its textures should be included in the main game .pck.
For each other resolution, a corresponding patch (e.g. "res://ui_qhd.pck") should be generated during export a project.

Texture2D import changes

Add a variant option to the Texture2D import settings (disabled by default). When a variant name (e.g. ui / game) is chosen, the following sub-options become available:

• Variant resolution - defaults to native

• Src textures for other resolutions

  • If not specified:

    • for resolutions with a smaller scale, a smaller texture will be generated (similar to Size Limit)

    • for resolutions with a larger scale, the original texture will be used unchanged

A crucial part of the import process should be storing the native texture size in Texture2D, which would be used by Expand Mode: Keep Size.
For example, for a native 4K-variant where the texture is 128×128, nothing changes. However, if an FHD-variant patch is loaded, a 64×64 texture should still be treated by TextureRect as 128×128 in order to preserve the layout.

The only thing left for the developer is to load the required patches manually at game startup.

[Calinou]

I believe #10034 is very similar, although the exact use case is different (it's not specifically designed with HD texture packs in mind). That said, this use case should remain possible with #10034.

I noticed that the documentation recommends using 4K textures with mipmaps for 2D, which sounds extremely inefficient. For FHD users, texture sizes increase sixfold to benefit only a small number of 4K users (~5% according to Steam).

To be fair, most 2D games aren't that large in terms of disk space or VRAM utilization. Also, the number of displays with a resolution above 1080p is expected to increase significantly in the next few years, so shipping 4K-ready textures will pay off in the long term 🙂

Personally, I think this use case makes more sense for 3D games where it can be the difference between a 20 GB installation and a 70+ GB installation.

[lnm95]

For me, this isn’t about build/installation size. I’m working on a 3D game with a procedurally generated world and mod support, so I pay close attention to memory usage. Since I don’t have a fixed scene, the number of resources loaded at the same time is variable and unpredictable, which is why I try to minimize any non-essential memory usage.

I agree that 4K support is forward-looking, but it shouldn’t come at the expense of low-end devices.

I’ve looked into #10034, and it addresses one of the issues I described by introducing a Scale Factor. That alone would already be a good starting point. I’m not sure what stage the resolution scale is at, but it would be great if it were accepted.

However, while #10034 is a good proposal, it does not solve the problem I described on its own. Creating separate builds for each UI resolution would be terrible. So yes, it would be great to see a unified solution that addresses both issues.