Ability to decrease file size of specific resources for specific exports

[allenwp]

June 2024 Update

I have created two proposals to address the issues in the original discussion:

Add support for import overrides and Texture Scale Factor #10034
Add support for resource remaps based on feature tags #10051

Original discussion

Say I have a game that has been released on PC with high resolution textures and high quality audio. I want to port my game to mobile, but I would like this new mobile export to use lower resolution textures and lower quality audio to decrease the final app size of the game. I also want to keep the same source project for both exports, so that it is easy to ship updates to both PC and mobile platforms, rather than needing to maintain two branches of my project that have different source resources. It is important that I can control the texture resolution for each texture: some textures must be kept at high resolution, while other textures may be reduced to a much lower resolution.

Proposal 1: Change import settings per-export

This first proposed solution is to add the ability to change import settings of individual source assets for each export. This solution works great for textures and WAV audio files, but does not work with OGG and MP3 files:

Texture: the "Size Limit" import setting can be used to reduce the texture resolution.

WAV audio: audio can be reduced from stereo to mono, the bit depth can be reduced, and the sample rate can be reduced.

OGG and MP3 audio: Unfortunately, this proposal falls short when it comes to OGG and MP3 audio, as audio compression is not a function of the Godot Engine.

Proposal 2: Localization-like resource remapping

This second proposal would require the user to duplicate (or triplicate, in the case of three exports, etc.) their source assets, select different import settings, and provide a way of selecting export-specific remaps of resources, similar to the Localization Remaps feature that already exists in Godot.

While this alternative solution addresses all source asset types, including encoded OGG and MP3 audio formats, it has a notable downside of needing to create copies of many resource files, including textures. This duplication of source asset files would introduce a risk of accidentally updating/fixing a resource for one export but not the other export, thus introducing game bugs that are specific to a certain export.

Discussion

From my experience of porting 3D games from PC to mobile, mobile VR, and Nintendo Switch, textures are the most important resource type for reducing file size of the final app and there are often a LOT of textures in a game. Duplicating all of these textures is not a reasonable solution, given the risk described in proposal 2. OGG and MP3 resources are usually fewer than the number of textures in a project, so it would be more reasonable to duplicate these resources for different exports and create some sort of bespoke in-house solution for handling which OGG/MP3 resource is used for each export.

I suppose that implementing both proposals would be "ideal", but it would be strange to have two different approaches to handling resources. I think proposal 1 would be the way to go unless someone has some thoughts on how to go about implementing proposal 2 without duplicating source assets for each texture...

Thoughts?

[lyuma]

Proposal 1: I fully support "Change import settings per-export". In fact, I'm surprised nobody has proposed this before. (The feature to decrease max texture size on mobile is commonly used in Unity, but it does have to reimport the whole project when switching platforms.)

The other related feature I am surprised doesn't yet exist is a way to have runtime graphics options to lower texture size in-game. (Texture Quality: Low/Medium/High)

This has been explored before, but I can't find a proper proposal yet. See here for some related dicussion:
godotengine/godot#23739 (not a proposal)
#511 (too specific to texture atlases)
https://godotengine.org/qa/35751/how-do-i-use-different-texture-resolutions

Note that power-of-two textures can be rescaled trivially / on the fly without recompressing, by removing mipmaps. Godot does allow mipmaps on non-power-of-two, which would require re-encoding if they are to be scaled down. This could become a warning perhaps.

Proposal 2 seems too complicated to do generally. It seems to me better to open it specifically in regards to the OGG/MP3 re-encoding, I think proposal 1 would be simpler to implement: For OGG/MP3, Godot could allow re-encoding at a lower bitrate on export.

[Calinou]

The other related feature I am surprised doesn't yet exist is a way to have runtime graphics options to lower texture size in-game. (Texture Quality: Low/Medium/High)

3.x has an option for this, but it lacks any form of granularity and wasn't reimplemented in master yet.

For this kind of option to be usable in a 3D game, there needs to be a way to exclude specific textures from being downscaled (such as 2D/GUI elements).

For OGG/MP3, Godot could allow re-encoding at a lower bitrate on export.

This would require integrating Ogg Vorbis/MP3 encoders in the editor, which would add bloat for a feature that probably won't be used often. Audio file size is usually much smaller compared to texture file size, so it's usually not worth the trouble to distribute different kinds of audio files to different platforms.

[allenwp]

It’s possible that this PR might be useful in the implementation of this feature(?) godotengine/godot#65135

[allenwp]

I’ve been talking with a few folks about this sort of feature. I plan to put together a proposal based on this topic in June that will include a number of mockups describing how this could work.

[lazyvainglory]

Add option for Max Size similar to Unity on sprite import

I’m aware of the ‘Process Size Limit’ option, but it shrinks the sprite. This means that if I need to export to another platform, I have to adjust the transform again. My suggestion is to implement something similar in Unity. For instance, if you have a 2048 x 2048 sprite, you could set a maximum size of 512 in its import settings without affecting the size(scale) of the rendered sprites in the Inspector. I find this feature very convenient when working with sprites across multiple platforms.

[allenwp]

I also found this feature to be extremely valuable and agree something like this should exist in Godot.

For Godot, it makes more sense to have this per-texture max size setting as an export setting instead of an import setting. Here’s why: there is no way to preview a platform within the editor because the game, even when debugging, runs separately from the editor. For this reason, it makes sense to set up a number of export presets that can emulate each different platform on the platform that you’re running the editor from. The export setting functionally would be effectively the same as the Unity import setting, but would make more sense for Godot.

My reason for having this feature implemented at export time instead of import time was that the downsized textures would not be needed until export time. But, after looking at how efficiently and quickly Godot currently generates multiple texture files using different compression types at import time, it might actually be most efficient and fastest to generate these downsizes textures at the same time during import.

[Calinou]

For instance, if you have a 2048 x 2048 sprite, you could set a maximum size of 512 in its import settings without affecting the size(scale) of the rendered sprites in the Inspector.

This should be feasible by exposing Texture2D's size 2D override in the Import dock. However, I was thinking about exposing it as a factor of the imported size (similar to the font oversampling factor) as opposed to a fixed size. A factor is easier to adjust across multiple images of different sizes (remember that you can adjust import settings on multiple files at once). This is relevant in particular for people using icons in themes, so they can have high-resolution icons in projects with a low base window size.

I've attempted this, but it's not in working form yet: https://github.com/Calinou/godot/tree/texture2d-expose-size-override

[allenwp]

@Calinou As I believe you’ve already seen, I shared some thoughts about how a scale factor could be added to the Texture2D import parameters under the “Part 2: Texture2D Scale Factor” heading of #10034. I’m curious if this is the sort of thing you were working towards with your draft change that exposed Texture2D’s size 2D override…

[allenwp]

I've turned a part of this into a proposal (#10034) and and I plan to make a second companion proposal to address some related things soon.

[allenwp]

I've added a second proposal (#10051) to address the remaining issues of this discussion.

I believe this discussion can be closed now, but I'm not sure if that is normal practice...

[Calinou]

I've closed this discussion as both proposals supersede it entirely.