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
Currently, exported textures are non-power-of-two. With today's GPUs this isn't a compatibility concern per se, but having NPOT sizes can cause floating point accuracy issues when slicing the texture, and there might also be a slight performance impact as well. It would be nice if there were an option to automatically pad the output texture to be the nearest POT size.
The text was updated successfully, but these errors were encountered:
Interesting. Could you provide an example project with the issue?
I honestly hadn't thought about these issues you mentioned and solving it is not quite straight forward as the Aseprite CLI does not provide anything like that.
We would have to export the regular image first, identify if the size is correct and them re-export it with padding if necessary.
I'd like to see the issue in a real project before committing to this complexity.
Not an example project, but Godot has a known bug involving bleeding pixels on Sprite2D's: godotengine/godot#67164
I'm currently having that problem, and went to see if Aseprite Wizard had the ability to output to a a power of two texture to see if that mitigated the issue. I don't know if it would work or not, though.
Currently, exported textures are non-power-of-two. With today's GPUs this isn't a compatibility concern per se, but having NPOT sizes can cause floating point accuracy issues when slicing the texture, and there might also be a slight performance impact as well. It would be nice if there were an option to automatically pad the output texture to be the nearest POT size.
The text was updated successfully, but these errors were encountered: