2D Toolkit Forum
2D Toolkit => Support => Topic started by: habitoti on December 08, 2013, 03:03:29 pm
-
Hi,
one great feature I used to use with TexturePacker on iOS in the past was the ability to configure an additional transparent border (2-3px) around sprites of the atlas w/o having to explicitly add it to the artwork itself. This was completely transparent to the usage of sprites otherwise, but it allowed for perfect antialiasing of sprite borders on rotation.
With tk2d now, the sprite borders can get very ugly when rotating sprites. Wouldn't that be a great feature for tk2d as well to introduce such a feature for the atlas?
Best, habitoti
-
assuming I understand this correctly, wouldn't adding padding on the sprite in the sprite collection editor fix this?
-
No, the atlas padding is just to avoid artifacts from color bleeding. You need additional space around the sprite to allow for placing of antialiasing pixels. See the following sample: both sprites are slightly rotated by the same amount. The left has no transparent border, while the right is the exact same sprite, but has an additional transparent border of 2 px on each side. The right border appears very jagged, since no antialiasing can be produced oustide of the sprite area, while the right is extremely smooth…the additional empty space can be used by the GPU to produce the necessary antialiasing pixels:
(http://rombos.s3.amazonaws.com/share/rotation.png)
In TexturePacker, this option is called "Inner Padding", since it produces an additional padding to the inner portion of the sprite (and thus effectively also extends its net size). This basically leaves a corresponding space around the sprite within the atlas and fixes the metadata accordingly, so the sprite will be used including the additional transparent border. That way, you don't need to fix the artwork itself (which can be extremely tedious otherwise).
(http://rombos.s3.amazonaws.com/share/TexturePacker.png)
This would be an extremely valuable option for the tk2d sprite collections!
Regards, habitoti
-
I'll have to look at what that texture packer thing does, but that sounds like edge dilation? Unity should do that when the texture type is set to "Alpha is transparency". Try setting that on the atlas and see if that helps?
-
No, color dilation artifacts is what you actually also solve with the atlas padding that exists already today. The "inner padding" is no real magic, it just provides the missing space around the sprite to do proper antialiasing by adding an explicit 2px transparent border.
This is actually very easy to achieve -- it is basically an additional padding that also goes into the sprite metadata. So assume you have a 50x50 px sprite, anchor at (25,25). In the atlas, it would be placed now at e.g. a rect (2,2,52,52), but the metadata would denote it as a rect (0,0,54,54) and anchor now at (27,27). So the finally used sprite would effectively be 4px larger in width and height, now having a 2px wide transparent border all around.
All you would need to do is add the inner padding to the existing padding parameter on atlas creation, and then consider it for the sprite metadata accordingly. Implementation-wise, this should be a no-brainer, since you have already padding implemented.
-
If I read this correctly, it does exactly what the padding does, but increases the size of the polygon to include the padding to avoid geometric aliasing?
-
Exactly
-
I'll see if I can fit something in to the next version. Not sure though - it depends on a few different things. If you wanna hack it in its pretty straightforward.
-
Hi,
I was having issue with the same lack of filtering at the edges of sprites, and I was wondering if this has been already fixed/improved. Simply adding one pixel worth of extension to the polygon (and the UV's of course) should to the trick - assuming there's enough padding in the texture.
The amount of padding needs to be at least 2 (pixels of different sprites need to have at least 2 empty pixels between them), otherwise you might get small glitches when the sprites are being rotated as fragments of neighbor sprites might be sampled by the bilinear filtering...
If nothing was done to this yet, what is the hack to implement it?
Cheers,
Sampsa
-
No, not got around to that yet...
Regarding the hack -
tk2dSpriteCollectionBuilder.ProcessTexture, add something to fake the bounds.
and line 1832 or so -
Vector3 dpos0 = new Vector3(Mathf.Lerp(pos0.x, pos1.x, x0), 0.0f, Mathf.Lerp(pos0.z, pos1.z, y0));
Vector3 dpos1 = new Vector3(Mathf.Lerp(pos0.x, pos1.x, x1), 0.0f, Mathf.Lerp(pos0.z, pos1.z, y1));
This is how it generates the positions followed by UVs. You'll need to add an additional pixels worth of extension there and the uvs that follow immediately after.
I wouldn't bother trying to make this work for all the rest of the scenarios (its the same reason I haven't got around to doing that, there are a lot of other cases that will need to be handled in an official solution), but it should be straightforward enough for this one case.
Or, I suppose if your source image had the extra padding you can just use custom render geometry and be done with it...
-
missing this feature as well here, it would be great if tk2d next version have this in mind
i finally made my own hack, but i still have to create the image with extra pixels, what my hack does is to trim each sprite leaving 1 extra pixel on each border, not sure if that is what unicorn proposed to do for hacking it.
-
+1 vote for this!
-
Sorry for kicking this old topic, but is there a solution within the tk2d anno 2015 for this? I've tried adding alphaspace in my PNG, but I still get jagged edges unfortunately.
I'm using a simple white square of 128x128 with 64px of padding on all sides (so the PNG is now 256x256), but it's still as jagged as the original 128x128 when rotating.
-
i ended up modified tk2d code , the part where it trims the sprite sheets to add a transparent pixel (or did i add 2? i can't remember), i can't even find where i did the hack now.
i still have to add extra transparent pixels for each cell in the sprite sheet so the hack works properly but at least it works, it can trim the collection now the same as before but with an extra transparent border of 1 pixel
-
Thank you for your response. I've decided to use a more pragmatic solution by editing my sprite.
As tk2d crops the added alphaspace from the PNG for the spritesheet (so a 128x128 square with a 64 padding on all sides (PNG is 256x256) still remains 128x128 in tk2d), I've added a small border of 1 px on the edge of the 256x256. This border has a opacity of 1% (so it's not visible in game, but there is still data so tk2d won't crop it off). This makes sure that the PNG stays 256x256 within the tk2d environment.
The aliasing on the original 128x128 square (within the 256x256) is now gone. I can rotate it as i please.
It's still a hack, but a more clean one I guess. I don't have to edit any code :)
-
yeah , the 1% opacity trick makes a lot of sense, the problem is you have to add that extra pixel for each sprite in photoshop which is a lot of work
unless... now that you i read again , you say you add 1 pixel at the border of the sheet document? that will make the tk2d trimming useless and you will waste a lot of space in the atlas, if you want that better go to collection settings and click "Disable Triming"
-
That makes much more sense. I'll switch between the two, see which works best.
I've used an exaggerated example btw (to see if it would work). My real PNG only has 2px of useless alpha space on top and bottom (the PNG is 128x128, so I think it will be fine. But adding only 1px of alpha space and set the trimming to false might be better.
Anyway, thanks!
-
i have found where i made the hack!, its on tk2dSpriteCollectionBuilder search for
int w1 = x1 - x0 + 1;
int h1 = y1 - y0 + 1;
that should be in line 377 (latests tk2d version), leave that untouched, and right after those two lines write these
x0 --;
y0 --;
w1 = w1 + 2;
h1 = h1 + 2;
those 4 new lines will make the sprite trimmer to include one more line of transparent pixels on each side, up, down , left and right so you can make your sprite sheets with enough free space on each cell, don't you worry about wasted memory cause the trimming will cut that away but now leaving one pixel on each side.
ISSUE: if you make a sprite which it's border touches the limit of the document or the cell (in a sprite sheet), meaning you don't leave any transparent pixels on its sides, you will not only get the usual stupid rotation artifacts but also the sprite won't show correctly sized by one pixel all of it.