Tight Sprite Mesh generating terrible meshes

Have those of you using Unity Pro with 2D sprites looked at your wireframe view? Simple isometric sprites are generating meshes like this for me.



Go to the Scene view and select Wireframe while your game is running to see if it is as bad for you.

If you are affected by this, please vote on the issue here

http://issuetracker.unity3d.com/issues/triangle-and-quad-sprites-can-generate-far-too-many-vertices

 

Hi,

It's a known issue and we're trying to reduce the number of polygons in Sprite shapes in 4.5.1 release.

Curious: how large is this sprite? We have an adaptive algorithm to figure out the max no of vertices for a sprite based on its visible area size in pixels - gpu vertex pipe vs fill rate balance as measured on iPhone 3.

 

That shot was taken at an image size of 1024x768. I've since reduced to 512x384, but it isn't significantly better. 256x192 is decent, but looks blurry in game.

The issue is that it is a repeated tile, and can be zoomed in quite close by the user, or visible from quite far. When you zoom out, obviously you get a ton of verts, even though you're taking up a much smaller portion of the screen. Is there a concept of LODs for sprite meshes?

I've tried Full Rect, but as you can imagine this shape causes way too much overdraw in that mode.

Is there anything I can do on my end to tune the algorithm? I've played with the extrude, but it doesn't have much positive effect. It would be great if I could draw my own mesh, as all I need is 4 verts.

 

There's no real LODing for sprite meshes. And currently no way to override the mesh manually. It's a requested feature therefore we're considering implementing it.

Unfortunately there's nothing you can do to influence how the mesh is generated. Please send me the texture you used, I'd like to check it against 4.5.1.

 

I've sent you a private message with the image. If you prefer I can email.

Thanks.

 

Hi,

I'm getting an issue that looks extremely similar to this one when importing sprites with transparency in Unity Pro, I get insane amounts of geometry on them. Using version 4.5.2f1. The bug did not happen when I imported sprites before upgrading to Unity Pro though. Any fixes or workarounds would be extremely appreciated, especially since the issue tracker says this was fixed in 4.5.1.

 

Yeah they said it was fixes but there was no real change. Honestly though for your sprite it probably can't do much better than that with the level of "tightness" they use. It'd be nice if they exposed some tuning variables though.

The reason you're seeing a difference is because in Free there is no tight mesh generation, so you were using rectangular. For that particular shape you could use switch it back to "Full Rect" Mesh Type if you set the sprite mode to advanced.

 

Ah, thank you very much, setting the mesh back to full rect is exactly what I needed. Is this intended behaviour then, is the tight mesh generated as planned? When is a tight mesh useful? All it was doing for me was killing performance, as I used many of these tiles to generate the map.

 

Tight mesh is useful to limit overdraw when using irregular shapes. Many mobile processors are very slow when overdrawing lots of alpha pixels

 

It would be nice to have an import setting slider for Sprites (or at least property that can be se in AssetPostprocessor) that controls how tight the mesh will be. Zero would be a very simple convex poly), 1 would the full tight mesh and the rest interpolated between.

 

The generated mesh has a specific vertex limit automatically calculated to not cause any performance issues when rendering sprites unscaled (pixel perfect) in relation to how much fill rate costs (on iPad 2 level hardware, taking into account GPU pipeline parallelizm). If you're making a map out of such sprites and get performance issues, then you're probably also downscaling them quite a bit OR the issue is on the CPU?

Anyway in 5.0 we will probably not expose a UI control, however we did add API to modify that mesh and an OnPostprocessSprites callback where you can implement your own meshification logic if you so desire.
Internally we do control mesh quality with a [0;1] range and I'll see if that can be provided to the SpriteMetaData type.

 

That would be a nice addition, for sure.

(EDIT: Along with the 16-bit dithering I've already requested on Twitter! =)

 

The issue for me is having a zoomable map. The assets are quite high res so that you can zoom in quite close. When zoomed in the verts per pixel is fine as per your algorithm, but when you zoom out the number of verts on the screen drastically increases.

 

Hi, does anyone know if there's any news on this? I'm having the issue in Unity 5.2.4. This game is targeting a desktop platform and the high vertex counts are preventing large numbers of sprites from being batched.


Since there are 233 vertices in this ground texture, it really cuts down on the number of these that are dynamically batched together.

 

In 5.4 there was supposed to be a way to control the generated mesh quality, but it seems it's not going to be in 5.4 after all.. Think I saw a message saying it will be removed in further 5.4 betas.

EDIT: Oops, meant 5.4!

 

After much effort, I found you can disable this behavior by writing something like this:

Code (CSharp):

1.  
2.     void OnPostprocessSprites(Texture t, Sprite[] sprites){
3.         foreach (Sprite s in sprites) {
4.             Rect r = s.rect;
5.             Vector2[] arr = new Vector2[] {
6.                 new Vector2 (0, 0),
7.                 new Vector2 (0, r.height),
8.                 new Vector2 (r.width, r.height),
9.                 new Vector2 (r.width, 0),
10.             };
11.             s.OverrideGeometry (arr, new ushort[]{ 0, 1, 2, 0, 2, 3 });
12.         }
13.     }

In an asset postprocessor. You may wish to only do this for assets that you know aren't dynamically batching properly. Use the frame debugger and look how Unity is batching your objects. Before this change, my pebble sprites were only batched in groups of two (<500 verts per patch). Now it draws them all in a single draw call. Be sure to measure your performance gain, since different hardware will have different costs for draw calls vs. the lost fillrate. Don't use tight packing or you'll get other sprites drawn.

Also remember that if you're getting really really bad geometry, there's a fillrate cost for drawing very narrow lines. Pixels that contain those lines end up having a cost for both triangles being drawn to that pixel. So in the worst case situations, this fix might improve your total geometry numbers, the total fillrate, and reduce the draw calls. But if you can't evaluate your worst case vs. the average case, it's probably not worth messing with this.

 

If you are having troubles with tight sprite meshes generated by Unity, you might try SpriteSharp:
https://www.assetstore.unity3d.com/en/#!/content/37599
SpriteSharp is an editor extension that allows to tune the parameters of tight meshes, allowing to adapt them to your exact project, and maintain low vertices count while still avoiding fillrate issues. It also comes with some additional features to reduce overdraw even more. Check it out!

 

This does look very useful, you might get yourself a new customer soon!