viniciusgerevini/godot-aseprite-wizard

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

IPDramon opened this issue · 2 comments

IPDramon commented

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 commented

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 commented

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.

  • 🚀1