Output texture should be packed to save on memory about godot-aseprite-wizard HOT 3 CLOSED

Thanks for the suggestion. I did test trimming before and it didn't bring any real benefit when it comes to file size.

It happens that transparent pixels do not take much space and the extra bytes required to define the regions ended generating resources with same and sometimes even bigger sizes.

It also doesn't work well with AnimatedSprites, as there is no way for defining regions there and the resulting animation aligns all frames by the center.

Even though trimming could mitigate the problem with big files, it doesn't really solve it, so the trade-off didn't seem worth it.

from godot-aseprite-wizard.

The main benefits I see are texture dimensions and VRAM usage. I know that this is an ongoing issue with #32, and given that a lot of GPUs don't support 16k textures, and many (particularly integrated ones) have a performance penalty when using 4k or larger, it makes sense to try and keep the dimensions low.

It also doesn't work well with AnimatedSprites, as there is no way for defining regions there and the resulting animation aligns all frames by the center.

In such a scenario, the AnimatedSprite can be animated over region_rect and offset. This would be a departure from the current method of animating over frame, hence why I think it should be offered as a separate mode/option from the existing row/column grid.

from godot-aseprite-wizard.

I think you are referring to AnimationPlayers and not AnimatedSprites, as an AnimatedSprite always rely on setting the frame in a SpriteFrames resouce. Having said that, there is also a region property in the frame resource which is already currently used by the plugin. It's just not considering the padding, which is why trimming currently doesn´t work.

I'm not against this contribution as long it's well tested for regressions, but I honestly don´t see much value on this change as of now. As we are talking about pixel art, which is generally way smaller than regular high res art, this feels an edge case and maybe a premature optimisation.

Also, this doesn't really solve cases like the one on #32, as trimming has little effect on that due to the naturally large art. The proper solution for that is giving the option for splitting the frames in multiple textures, which I think is a better time investment.

By the way, I'm not trying to discourage you from contributing or giving suggestions. It just that as of now I don´t see it as high priority so it's likely something I won´t be focusing in the near future. Thanks for the suggestion and for bringing these issues to my attention. I hope this is not a deal breaker for your projects. Cheers.

from godot-aseprite-wizard.