You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on a Bullet Hell style game targeting Steam Deck.
Describe the problem or limitation you are having in your project
While my project is targeting the 1280x800 60hz panel of the Steam Deck, I aim to optimize for this platform while having the option to scale to 4k. Right now, I limit most materials between 128x128 and 512x512 resolution. This is fine for my target resolution, but not ideal for a 4k panel.
I attempted to solve this via a mipmap bias however the full textures are still loading, the quality is lower than desired, and doesn't work the same once FXAA/TAA/FSR are used.
This proposal is likely related to the following: #23739 and #2683
Describe the feature / enhancement and how it helps to overcome the problem or limitation
A feature in engine to import textures at a lower mipmap level as the base resolution. This would conserve VRAM capacity and bandwidth while allowing the mipmap bias to behave as normal while maintaining the lower mipmap levels to behave as normal. This feature would also allow an easy to access member for a settings menu for all Godot users.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
An option added to the rendering/textures/default_filters/ settings to trim off the top level mipmaps.
If set to 0, it behaves as is. If set to 1, then it would trim the highest resolution image and use the second tier mipmap as the highest resolution. The bottom resolution could be either the lowest tier mipmap,or an additional "minimal_trim_resolution" (if set to 64, the trim would not go lower than 64x64).
If this enhancement will not be used often, can it be worked around with a few lines of script?
This would only impact textures with mipmaps and only if it is changed from default. As such, sprites and UI elements should be safe. Additionally, if the setting remains to the default of 0, there would be no impact to anyone who does not use the setting. Lastly, if the feature is used, these feature could be worked around by one of two ways:
Disable mipmaps on the affected texture.
Add a final import setting for a local minimal trim resolution.
Is there a reason why this should be core and not an add-on in the asset library?
I am unsure how mipmaps are loaded, though if we can load the mipmap levels respecting the trim setting, there is no downside to implementing this feature to core. I am not sure if an add-on would have access to these lower level mipmaps without loading the higher resolution images, costing memory and storage bandwidth.
The text was updated successfully, but these errors were encountered:
Duplicate of #3177. This needs to be implemented as a streaming solution, with a project setting to choose the highest mip that can be loaded.
Godot 3.x has a method you can call to shrink all textures by a 2× factor (resulting in 1/4 pixel count), but it lacks any granularity and seems to be uneffective on VRAM-compressed textures. This method is also not implemented in 4.x yet. That said, once texture streaming is implemented, this shrink-on-load may not be worth reimplementing in 4.x, as it suffers from issues such as godotengine/godot#39058. It would also slow down loading times, as resizing needs to be performed on the CPU for every texture. Texture streaming doesn't require any resizing to be performed on the CPU.
In the meantime, you can limit texture size in the Import dock to make Godot resize textures upon importing. This won't allow users to increase texture resolution, but it allows you to keep the original size textures available, so that you can switch to them once texture streaming is implemented.
Describe the project you are working on
I am working on a Bullet Hell style game targeting Steam Deck.
Describe the problem or limitation you are having in your project
While my project is targeting the 1280x800 60hz panel of the Steam Deck, I aim to optimize for this platform while having the option to scale to 4k. Right now, I limit most materials between 128x128 and 512x512 resolution. This is fine for my target resolution, but not ideal for a 4k panel.
I attempted to solve this via a mipmap bias however the full textures are still loading, the quality is lower than desired, and doesn't work the same once FXAA/TAA/FSR are used.
This proposal is likely related to the following: #23739 and #2683
Describe the feature / enhancement and how it helps to overcome the problem or limitation
A feature in engine to import textures at a lower mipmap level as the base resolution. This would conserve VRAM capacity and bandwidth while allowing the mipmap bias to behave as normal while maintaining the lower mipmap levels to behave as normal. This feature would also allow an easy to access member for a settings menu for all Godot users.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
An option added to the rendering/textures/default_filters/ settings to trim off the top level mipmaps.
If set to 0, it behaves as is. If set to 1, then it would trim the highest resolution image and use the second tier mipmap as the highest resolution. The bottom resolution could be either the lowest tier mipmap,or an additional "minimal_trim_resolution" (if set to 64, the trim would not go lower than 64x64).
If this enhancement will not be used often, can it be worked around with a few lines of script?
This would only impact textures with mipmaps and only if it is changed from default. As such, sprites and UI elements should be safe. Additionally, if the setting remains to the default of 0, there would be no impact to anyone who does not use the setting. Lastly, if the feature is used, these feature could be worked around by one of two ways:
Is there a reason why this should be core and not an add-on in the asset library?
I am unsure how mipmaps are loaded, though if we can load the mipmap levels respecting the trim setting, there is no downside to implementing this feature to core. I am not sure if an add-on would have access to these lower level mipmaps without loading the higher resolution images, costing memory and storage bandwidth.
The text was updated successfully, but these errors were encountered: