Replies: 6 comments 5 replies
-
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: 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. |
Beta Was this translation helpful? Give feedback.
-
It’s possible that this PR might be useful in the implementation of this feature(?) godotengine/godot#65135 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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... |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions