exporting data (en)
The plugin exports data from each source to its own common internal format. It consists of an image that contains all the animation frames (atlas of sprite sheet), a list of sprites (the coordinates and sizes of the regions of this image) and a list of animations consisting of frames, where each frame is a sprite and its duration.
There are only two main layout options: grid-based and packed. But the grid-based layout is still divided into row-based (horizontal strips) and column-based (vertical strips).
The grid-based sprite sheet layout is convenient if:
- it is important for you that the sprite does not change its size during the animation;
- you are going to import the data just as a Sprite sheet (a sprite sheet atlas image and JSON resource without stored text but with full sprite sheet information in
dataproperty), which you will use to create animations yourself based on it. For example, to animate theframeorframe_coordsproperty of theSprite2Dnode because the plugin does not support them.
The packed layout is beneficial in terms of memory savings, because the sprites in it are cut off and arranged compactly.
Artifacts sometimes appear on texture boundaries during rendering - noticeable boundaries, which can be of two types:
-
The consequences of inaccurate scaling and positioning of sprites relative to each other, which leads to the appearance of flickering gaps, for example, between tiles on tilemaps. Because of this, even the nearest pixels adjacent to the sprite region can get into the frame. This can be observed even when filtering textures using the "Nearest Neighbor" method. The setting "Project Settings -> General -> Rendering -> 2D -> Snapping -> Use GPU Pixel Snap" helps partly with this. But even it will not help with non-integer scaling.
-
Consequences of the mutual influence of the outermost pixels of the sprite and the outer pixels of the atlas adjacent to them with the linear ("Linear") texture filtering method. They appear due to the fact that the GPU does not filter the atlas, and not the sprite, but the screen pixels. And for each of them, it mixes the colors of the nearest atlas pixels in proportions of distance. Thus, the color of a screen pixel near the edge of the sprite is affected by the color of the atlas pixels that are outside the edge of the sprite. This gives rise to 2 problems:
- Sharp edges on the borders of the sprite with its overall smoothness.
- Leaking of the color of the atlas pixels adjacent to the sprite into the region of the sprite.
There is no "silver bullet" that will solve all problems, but there are several ways, each of which is good for a certain kind of application of the sprite.
The sprites on the atlas are close to each other. This method is suitable in the following cases:
- Textures are filtered by the nearest neighbor method, and fractional object scaling is not used;
- Textures are filtered by a linear method, but, the layout of the atlas is grid-based, the sprites are not cut off, and in the original animation the drawing never touches the image borders.
In other cases, this method will generate artifacts.
This method is compatible with animating a Sprite2D node using the frame and frame_coord properties when using grid-based sprite sheet layout.
The transparent spacing adds a 1 pixel gap filled with a transparent color between all the atlas sprites. This method removes the leaking of the colors of pixels of neighbor sprites through sprite edges. But at the same time, a sharp edge of the sprite remains with linear filtering. This method is suitable if:
- Textures are filtered with "Nearest Neighbor" method and fractional scaling is applied. In this case, the color of neighboring pixels will not leak into the sprite. But this will not protect against gaps between tiles that sometimes occur if the mapping of the atlas region to the canvas is inaccurate (the consequences of calculations on floating point numbers).
- Textures are filtered with "Linear" method and this generates a sharp edge. But sometimes a sharp edge is needed for a clear connection between tiles and some other visual objects.
This adds a gap of 1 pixel, filled with the specified color between all the sprites of the atlas as well as between the sprites and the edges of the atlas. This method can help if linear texture filtering is used, the atlas layout is grid-based, and the animation should fit into a rectangular cell around which everything is filled with the specified color. This will create a smooth transition from the hard edges of the cell to your image.
This method well protects against flickering gaps between tiles during fractional scaling, when filtering by the nearest neighbor method, since when the rendered region of the atlas is shifted by a very small number, exactly the same color as the outermost pixels of the sprite will leak into it from the outer region. Not an adjacent sprite, and not a transparent stroke.
However, this method is not suitable for linear filtering, because it creates jagged sharp edges at the edges.
With this method, each sprite expands in all directions by 1 pixel of transparent color. This protects against sharp edges in linear filtering.
This method is compatible with animating a Sprite2D node using the frame and frame_coord properties when using grid-based sprite sheet layout.