Deleted

[qklxtlx]

Deleted

[Tef]

Sorry for this stupid question. But what is the general application for this? The only think I can think of is to get a more compact texture atlas. Is that the thing?

[Andreas_Loew]

@Tef : Using polygon meshes instead of quads has 2 advantages:

1. You can pack the sprite much tighter => reduced memory usage for the textures
2. Reducing overdraw => increases the performance of your game

The reason for 2) is that transparent pixels are not “nothing”. The GPU processes them as it does with every other pixel. Using polygon meshes decreases the number of pixels. In the example above I would estimate that the polygon mesh uses only about 70% GPU compared to the rectangular image.

@qklxtlx
This is awesome!

[Tef]

@Andreas Loew

@Tef : Using polygon meshes instead of quads has 2 advantages:

1. You can pack the sprite much tighter => reduced memory usage for the textures
2. Reducing overdraw => increases the performance of your game

The reason for 2) is that transparent pixels are not “nothing”. The GPU processes them as it does with every other pixel. Using polygon meshes decreases the number of pixels. In the example above I would estimate that the polygon mesh uses only about 70% GPU compared to the rectangular image.

@qklxtlx
This is awesome!

Cool, but doesn’t a polygon mesh lead to more triangles compared to the 2 triangles used by a rectangle? Maybe that doesn’t lead to any performance loss, I remember when games had a limit of 100 tris on a character But then GPU’s weren’t as good as they are today either.

[Tef]

@""

The most important reason I implement this because I want less textures packed. For UI part in my project, I had 3 textures of size 2048 at first, and compressed to 2 textures with polygon mode.

Also I want to reduce fill rate (as Andreas Loew said “overdraw”). Here in my another blog post 填充率!填充率!填充率! | Loading & Learning (Sorry for Chinese again, but you can only refer to the profiler image)
With profiling, scene A ( Verts 26.3k, Tris 15.2k, Batches 86) is about 50fps; scene B (Verts 15.0k, Tris 8.9k, Batches 138) is about 30fps. The difference is scene B has a lot of overdraw (simple quads, but BIGGER size)

After using Polygon mode, I have about <1k verts added (Because most of UI sprites have a rectangle size, remaining the same) But saves a lot more.

Conclusion: You need to find the hotspot of your game: verts/tris, or batches, or fill-rate? It doesn’t matter for me having these more vertices, but saves more

Thanks for the information!

[Andreas_Loew]

@Tef
The transformation of the vertices is usually done by CPU. Adding more vertices adds to the CPU time - that’s right. But the mesh reduces the number of pixels drawn. So what you get is a way to control the distribution of the workload between GPU and CPU.

TexturePacker has a slider called Tracer Tolerance (default is 200) - it’s the amount of pixels that are accepted for adding a new vertex. If TexturePacker decides to add a new vertex it checks if it will gain more pixels. E.g. if it’s possible to add a vertex and reduce the area by 200px it’s done.

Here’s an example what you get from different settings:

The right most frame uses +3 vertices while reducing the number of pixels by 52% compared to the rectangle. This is really improving things.

You also see that if you take it to the extreme (left example) you add more and more vertices, with only small reductions in size.

As @qklxtlx : You now have the control over the optimization.

[Tef]

@Andreas Loew

@Tef
The transformation of the vertices is usually done by CPU. Adding more vertices adds to the CPU time - that’s right. But the mesh reduces the number of pixels drawn. So what you get is a way to control the distribution of the workload between GPU and CPU.

TexturePacker has a slider called Tracer Tolerance (default is 200) - it’s the amount of pixels that are accepted for adding a new vertex. If TexturePacker decides to add a new vertex it checks if it will gain more pixels. E.g. if it’s possible to add a vertex and reduce the area by 200px it’s done.

Here’s an example what you get from different settings:

The right most frame uses +3 vertices while reducing the number of pixels by 52% compared to the rectangle. This is really improving things.

You also see that if you take it to the extreme (left example) you add more and more vertices, with only small reductions in size.

As @qklxtlx : You now have the control over the optimization.

I forgot you’re the creator of TexturePacker, we actually use that for our old mmo, Astroflux. http://www.astroflux.net

Thanks again for explaining, this is actually really awesome!

[Tef]

@Andreas Loew

@Tef
The transformation of the vertices is usually done by CPU. Adding more vertices adds to the CPU time - that’s right. But the mesh reduces the number of pixels drawn. So what you get is a way to control the distribution of the workload between GPU and CPU.

TexturePacker has a slider called Tracer Tolerance (default is 200) - it’s the amount of pixels that are accepted for adding a new vertex. If TexturePacker decides to add a new vertex it checks if it will gain more pixels. E.g. if it’s possible to add a vertex and reduce the area by 200px it’s done.

Here’s an example what you get from different settings:

The right most frame uses +3 vertices while reducing the number of pixels by 52% compared to the rectangle. This is really improving things.

You also see that if you take it to the extreme (left example) you add more and more vertices, with only small reductions in size.

As @qklxtlx : You now have the control over the optimization.

Does this also work for old flash games in Starling? That would be very interesting for our old game.

[chenxr]

How about the slice model ，I have studied for a long time， but it’s so complex

[guzzo]

This looks amazing!

Thank you!

[TheValar]

I’ve been using this and notice that the generated vertex positions are incorrect if the source image has transparent padding along the borders. I guess it’s assuming the original Image mesh is going from UV (0,0) to UV (1,1).

[TheValar]

@""

would you mind provide a simple example project?

Just put this image in a scene, set it to native size and then add the PolygonImage Component to see the issue. In the meantime I’ve solved it (with clues from your comments) by using “GetDrawingDimensions” rather than vertex positions and slightly modify the method to ignore the Sprite Padding

[Aymeric1]

Hey @qklxtlx , thanks for the code!

I spotted an issue: using a texture Compressed it works fine, but with a Truecolor it seems the script doesn’t work… any ideas?

[Aymeric1]

My bad, I changed again and it works fine in fact. From the script I don’t see any reasons why the texture format would change its behavior. So I suppose that Unity had an issue when I changed my sprites

[Deankovitch]

Hi all,

I’d like to share with you my plugin to create 2D Primitives.
You can create these primitives

• Circle
• Star
• Rounded square
• Arrow
• Spiral
• N-Sides Polygon
• Gradient Quad
• 4 Corner Gradient Quad

All primitives types are inherited from default Graphic class so it’s behave as any canvas element.
The main pros to use those primitives are:

• They are resolution independent;
• Fully animable;
• Lightweight;
• Fully configurable;
• Source code included;
• You can use the shapes included in the pack (as a static class Shape2DHelper) for many implementations: spawn objects, emit particles, draw, animation etc.
• Fast and easy to prototype or create UI / UX;

To next version I’m adding support to create 2D Sprite Primitives as well.

Here is the link to the plugin on Asset Store
2D Primitives

[dookeybre]

@qklxtlx Thank you so much for this code! It works well!!

[anthony_q]

Hi! Thank you for your great work of the code. We use this tool for UI part and we’ve implemented a PolyImage to add support Image in UGUI. This helps a lot with both memory and performance.

If you are interested, you can find more info here PolyImage - Support Polygon Sprite in UGUI Image