Godot 4: Wrong Enum used for Sprite3D and AnimatedSprite3D texture filters

[IPDramon]

Hi everyone,

I tried out the current Godot 4 branch of AsepriteImporter in my project and I really enjoy it. The only problem I faced was that the filter for my Sprite3D was always resetted to Linear from my wanted Nearest after importing the texture again. After looking at the sprite_frames_creator and animation_creator i found that the wrong Enum was used for the 3D sprite nodes.

(Animated)Sprite2D is a subclass of CanvasItem while (Animated)Sprite3D is a subclass of SpriteBase3D. Both have a property texture_filter but use different enums. CanvasItem.TEXTURE_FILTER_NEAREST has an internal value of 1 while BaseMaterial3D.TEXTURE_FILTER_NEAREST has a value of 0. By using CanvasItem.TEXTURE_FILTER_NEAREST for (Animated)Sprite3D you actually get BaseMaterial3D.TEXTURE_FILTER_LINEAR as this has an internal value of 1 as well.

Therefore I propose to check whether the node in question is a CanvasItem and use CanvasItems enum in that case. BaseMaterial3D will be used in every other case.

I have tried that out locally and it worked fine for my use case. I will provide a branch after finalizing this issue.

If there are any questions or misunderstandings on my part feel free to comment below this issue. Maybe I just used the tool wrongly :D

EDIT: Unfortunately I am not allowed to create a branch and I don't think that a fork for this minimal change would be the correct way. Therefore I will just post the changes I did here instead:

animation_creator.gd line 75ff:

    if target_node is CanvasItem:
        target_node.texture_filter = CanvasItem.TEXTURE_FILTER_NEAREST
    else:
        target_node.texture_filter = BaseMaterial3D.TEXTURE_FILTER_NEAREST

sprite_frames_creator.gd line 66ff:

    if animated_sprite is CanvasItem:
        animated_sprite.texture_filter = CanvasItem.TEXTURE_FILTER_NEAREST
    else:
        animated_sprite.texture_filter = BaseMaterial3D.TEXTURE_FILTER_NEAREST

[viniciusgerevini]

Thanks @IPDramon . That makes sense. Thanks for spending the time on this.

Usually the forks are the way to go here on Github, but not worries I'll move this to a PR and mark you. Thank you!

[IPDramon]

ah, good to know. I always thought that forks are for creating a new project based on another, not for preparing feature/fix proposals. Then I will do this for my next proposal.