Polygon packing

[ivanpopelyshev]

Im slowpoke but it TexturePacker supports polygons. Now we need new SpriteRenderer. Please tag that thing for v4.

Format

{"frames": {
"animal_extractor.png":
{
    "frame": {"x":2,"y":326,"w":164,"h":136},
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": {"x":0,"y":0,"w":164,"h":136},
    "sourceSize": {"w":164,"h":136},
    "pivot": {"x":0.5,"y":0.5},
    "vertices": [ [140,34], [164,76], [164,88], [95,127], [74,136], [50,136], [0,108], [0,62], [32,19], [86,15], [101,0], [106,0] ],
    "verticesUV": [ [142,360], [166,402], [166,414], [97,453], [76,462], [52,462], [2,434], [2,388], [34,345], [88,341], [103,326], [108,326] ],
    "triangles": [ [9,10,11], [3,8,9], [7,3,5], [3,0,1], [5,6,7], [5,3,4], [3,7,8], [3,9,0], [3,1,2], [0,9,11] ]
}
}

[ivanpopelyshev]

People say that it was added in unity 1 year ago

[SeminYun]

awesome.
mobile is always not enough memory.
so need that..
how do you think about performance by polygon texturepacking

[Friksel]

This is briljant! @SeminYun in case you didn't find the information on performance, here's a test they did on iphone 4s: https://www.codeandweb.com/blog/2015/10/01/cocos2d-x-performance-optimization
the image made 36fps untrimmed, and 60 fps trimmed! Talking about improvement! This texturesupport would be very, very welcome in pixi!! :)

[englercj]

Note: That perf benefit comes at the cost of CPU. Something direly restricted in JS already. I'd love to benchmark this in pixi and see what the difference is like.

[Friksel]

Nice. Next to hopefully this performance benefits, this will definitely make some spritesheets smaller while images can fit inside alpha holes! So a lot of spritesheets will load faster. Good thing!

[ivanpopelyshev]

I'll implement it in WIP branch v4.1 soon :)

[englercj]

Couldn't this be rendered via Mesh instead of creating a new feature?

[GoodBoyDigital]

@englercj 100% correct. New Sprite setup will accommodate this nicely too!

[ivanpopelyshev]

uvs and geometry must be in "texture" or "model" side, not in instance, so Mesh is not a solution.

[nikolayh]

Any update?

[Jorisslagter]

Because the polygon mode is still disabled by default for the PixiJS data format, it looks like that polygons are not supported in Pixi.

As the last couple of comments suggests, it should be somewhere on the release agenda of PixiJs as from version 4.1. Can somebody confirm that this featured made it in to PIXI 4.* already?

And if it is supported, does somebody know how to enable this feature in TexturePacker for PixiJS json format?

[ivanpopelyshev]

It will be added in v5, I'll provide it.

[Jorisslagter]

Wonderful! Thank you so much.

[Friksel]

Great @ivanpopelyshev !

[gle6as]

Any news here?

[ivanpopelyshev]

No news, but no one confirmed that they need it seriously. I can make it as a plugin for v4, but who ever will test it and confirm that it works? And v5 is in alpha stage, so no one will use it for several months if i add it there.

[Friksel]

No news, but no one confirmed that they need it seriously.

Huh? You mean, except for us?

I'm sure for a lot of projects this can optimize 'spreadsheets' with different images-formats on it a lot because every image can be much closer to each other. I already needed it a few times, to be able to create spreadsheets where I put small images in the transparent part of a large image to have a smaller spreadsheet-output image.

Can't speak for others, but I would use this feature a lot

[ivanpopelyshev]

Please write email to @GoodBoyDigital, if he agrees then I'll focus on that thing.

[finscn]

I need this feature .

[finscn]

I think it's time to tag it for v5.

[sudhalucky]

Is it available as a plugin for v4.x? or should I wait for v5 for this feature?

[GoodBoyDigital]

V5 for sure, this will be incredibly easy to implement with new systems! (with batching!)

On Wed, Jun 6, 2018 at 10:05 AM sudhalucky ***@***.***> wrote: Is it available as a plugin for v4.x? or should I wait for v5 for this feature? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2243 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC998nI2I61yvKnAEcwik_-jBCsiGUnvks5t55tigaJpZM4G0VPE> .

-- *Technical Director* Home: www.goodboydigital.com Phone: 020 8533 1177 Address: Unit B1, Matchmakers Wharf, Homerton Road, London, E9 5FF

[jonlepage]

i need this feature

[ivanpopelyshev]

This plugin supports polygon packing: https://github.com/gameofbombs/pixi-heaven

Use PIXI.heaven.Sprite

[Friksel]

@ivanpopelyshev Thanks for the nice tip about pixi-heaven. Definitely take a look at that. But for just polygon packing that plugin seems a bit overload for just polygon packing. The README states it even requires the Spine plugin (eventhough we don't use Spine in a project) and it says it costs performance to use it. I just took a quick look at that repo, so I might be missing something here, but I don't see any reason why polygon packing needs to compromise performance during animation and need Spine.

What I am looking for is a way to keep spritesheets as small and efficient as possible in width and height to have faster loading times. I figured for a lot of projects there are lots of blanks in spritesheets because the images are 100% transparent on large regions. That could be filled with the smaller images that now has to go outside the rectangles of these transparent images.

With polygon packing we could make spritesheets a lot smaller, like this simplified example (every different color is a different sprite):

You can see here the large round shape now allow the small shapes to fill the transparent hole that normally is just large missing space. And on the right you see two triangles can use the same space resulting in 50% decrease in used space.
With normal spritesheets this would result in a very large spritesheet, where all images need full rectangles, eventhough they are transparent for large regions that would result in a much larger spritesheet and takes much more time to load.

This feature will not only make spritesheets much smaller in a lot of cases, like a post of yourself state above, even the drawcalls could be faster, because instead of drawing a large rectangle only the smaller polygons needs to be drawn. But for the latter, you know lot more about that then I am.

There is also an article on the Texturepacker website about large performance increase with polygon packing:
https://www.codeandweb.com/texturepacker/tutorials/cocos2d-x-performance-optimization

And they supply another realworld example where this is very useful and very efficient:

So to conclude; I am not convinced PIXI.heaven.Sprite is a solution for this and I would expect performance to rise, not drop.

[kane-mason]

+1 for this feature

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Friksel]

I see some +1s here and 6th of june 2018 @GoodBoyDigital wrote:
"V5 for sure, this will be incredibly easy to implement with new systems!
(with batching!)"

Now we read 'Resolution: Won't Fix' label has been added by the stale bot and the issue has (automatically) been closed. Earlier we were informed these 'bots' are to be taken with a grain of salt, so I'm not sure:

This feature is still very welcome. Is it still in the pipeline for v5?

[jonlepage]

i think @CodeAndWeb need enable polygon in texturePacker for pixijs framework first.
It seem disable.

[CodeAndWeb]

You can use the "JSON (Hash)" format to try it - it enables the polygon packer but disables some PixiJS specific things (Animation detection). The rest of the format is identical.

Each sprite gets 3 additional entries:

"vertices": [ [147,74], [194,68], [204,200], [153,266], [56,267], [15,220], [1,180], [11,72], [64,70], [66,3], [132,1] ],
"verticesUV": [ [194,901], [200,948], [68,958], [2,907], [1,810], [48,769], [88,755], [196,765], [198,818], [265,820], [267,886] ],
"triangles": [ [8,9,10], [6,7,8], [5,0,2], [6,0,5], [5,3,4], [6,8,0], [0,1,2], [5,2,3], [0,8,10] ]

• vertices are the points in the sprite coordinate system
• verticesUV are the vertices in the texture atlas
• triangles are the triangles built from the vertices

[Friksel]

@djmisterjon It's also not that difficult to change the a template for outputs in texturePacker yourself or to create your own custom template for outputs (which is pretty great actually!):
https://www.codeandweb.com/texturepacker/documentation/custom-exporter

[jonlepage]

@Friksel interesting , thanks for the tips , it can be very useful for many custom system.

[cloudmark]

Hi there, is there any support for this in PixiV5? If there isn't can someone perhaps highlight what feature to use from Pixiv5 to implement it? Might be interested in implementing this for my project.