Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to make the Size Limit import processing work correctly on repeating textures #9126

Open
RatDotRaw opened this issue Feb 18, 2024 · 2 comments

Comments

@RatDotRaw
Copy link

Describe the project you are working on

A 3D game with a low poly and low texture resolution art style.

Describe the problem or limitation you are having in your project

When I import a high-resolution seamless texture and set the size limit to a very low value (e.g. from 1024 to 256) in the import settings, the texture does not scale down properly and creates a visible seam along the edges. This is especially noticeable with normal maps, where the seam affects the lighting and shading of the object.

Visible normal map seams
image

Describe the feature / enhancement and how it helps to overcome the problem or limitation

A new option in the import settings that allows resizing textures without creating seams. This option would ensure that the edges of the texture match the opposite edges, preserving the seamless quality of the original texture.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This feature could be implemented by matching the opposite edge pixels.
(I don't know how else to explain or how that would work)

If this enhancement will not be used often, can it be worked around with a few lines of script?

A workaround is to resize the textures outside Godot and importing them after.

Is there a reason why this should be core and not an add-on in the asset library?

This feature would speed up the (re)import workflow by allowing users to resize their textures automatically and seamlessly, without having to manually scale them or worry about the resolution. This would save time and effort, as well as improve the visual quality and performance of their projects.

@Calinou
Copy link
Member

Calinou commented Feb 18, 2024

The Import dock doesn't define whether a texture is repeatable anymore since 4.0, and this information is required for proper downsizing on import. However, a single texture can be used in different materials (some of which may enable repeating). You don't want to make the downsized texture seamless if it's not repeating, as this will introduce artifacts on borders. This is most noticeable on transparent textures like sprites.

However, I'd expect a majority of downsized textures to be repeatable1, so perhaps always doing this is a better option – at least on opaque images. (I would prefer not exposing an extra Repeatable option just for this as it has a high potential of creating confusion, and Size Limit is already a niche option in itself.)

In the long run, we'll need a dedicated solution for different export targets to use differently-sized textures, as is commonly done for mobile/console ports of PC games. This would be coupled with texture streaming to reduce memory usage on systems with low amounts of VRAM (you can limit the maximum mip level that is loaded at any time).

PS: Is the artifact still there if you set the compress mode to Lossless instead of VRAM Compressed?

Footnotes

  1. Limiting size on import is mostly about limiting file size and memory usage, which are regularly bottlenecks in 3D games but rarely in 2D.

@Calinou Calinou changed the title Better importing for seamless textures Add an option to make the Size Limit import processing work correctly on repeating textures Feb 18, 2024
@RatDotRaw
Copy link
Author

PS: Is the artifact still there if you set the compress mode to Lossless instead of VRAM Compressed?
The artifact remains, no mater what settings I changed in the compress section of the import tab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants