Are these results I should be seeing on an isometric tile Sprite (1024x768) with alpha all around? This is scene view with Wireframe rendering with single gameobject of that tile.
It appears to be generating hundreds of verts in order to pack it tightly, instead of what should be about 4. 
Any way I can make this better, without disabling the tight mesh entirely?
No, although it will work better with smaller texture sizes. Does it really need to be that big?
–Eric
Sure, if I zoom it could take half the screen on a retina display. Even cutting it to 512 generates a ton of verts, and at 256 the mesh begins to look reasonable.
Seems like an inefficiency/bug in the convex hull generation. This is the same triangular sprite, flipped two ways
Reviving this thread because I also am running into question marks about the efficiency of the packing algorithm.
This is a 677x2047 texture. When it is packed, it gets 500 triangles and 600 vertices.
I use an LOD system with sprites though so the smaller trees have less triangles and verts.
I’ve created an experimental map with around 400000 trees of different resolution resulting in 4 million triangles and 4 million vertices when sprite mesh type = Tight. This is the profiler for this scene.
When I use sprite mesh type = Full rect instead, I get
The full rect is actually more efficient than the tight packing, which is both unintuitive and bad. It’s bad considering that most of the texture is actually transparent. This is the tree sprite.
I also tried this with smaller trees, those that have less than 50 tris and 50 verts. Still full rect was more efficient.
Anyone knows any more about this? Any assets that might be able to do this for you?
This assertion is entirely dependent on the relative cost of transforming vertices vs considering and rejecting blank texels at the rasterization step.
Those numbers WILL be different on different hardware.
Why not try your hand at cutting out that sprite yourself, put it on a custom piece of geometry, see how that performs?
If that performs no better (or not significantly better) then you will have invested ten minutes of time to realize that perhaps how the sprite chopper chops things up might be irrelevant to your performance bottleneck.
It’s a general purpose algorithm designed to suit 99% of use cases.
When you get into big numbers like this:
… you often need to reconsider what you are even doing.
Perhaps you need far more aggressive LOD solutions?
Perhaps you need to make tree impostors beyond a certain distance?
Perhaps you need to do a full world impostor where distant objects get replaced by a geometry with multiple tree textures stamped on it?
etc.
I am on Windows desktop developing a singleplayer game for PCs. I guess on mobile the tight packing might do better.
How can I cut the sprite out myself? I don’t know how to write a sprite packing algorithm let alone how to hook it up into the whole texture/sprite rend pipeline.
Right now we’re doing exactly that. have an LOD system for these trees where the trees are swapped out to much smaller trees (aka sprites with lower width x height) when further away. But I’m questioning whether this LOD system really has any purpose because it looks like full rects are doing better at every resolution, so a combination of full-rects and an appropriate mipmap system (manually set the mipmaps because Unity mipmaps give low quality sprites) might just be better than our LOD system (perhaps any LOD system for sprites).
In fact I just tested the above sea of trees (400000) but with gigantic textures (5000 x 15000) and it has virtually the same FPS as with the smallest (64 x 193), unless I use Tight sprite packing. The game was unplayable with Tight packing. Had pretty much 1 FPS. So it looks like doing tight sprite packing on a Windows PC, in this case, has no benefits whatsoever.
This is how the sea of trees looks like (sorry everything is so black, the world is very debuggy atm.
Throw the image in Blender3D and use it as a guide to make a card… ctrl-right-click to add dots going around the tree limbs, as accurately as you want, select-all - make face (F), then UV project view onto the texture, drop that card in as your tree.
Edit: like this pixel art wizard I chopped out loosely:
There are a few ways you can tweak the generated mesh:
Could you improve the default outline generation algorithm even just like 30%? People have been asking for another iteration on this for some time.
If it’s just a little better, it’ll also help with manually adjusting special custom outlines too, from a UI/UX perspective. Many times I click the Generate button only to wish I hadn’t bothered.
The highest quality commercial solution is SpriteUV from what I can tell but I haven’t used it and it seems to operate outside of Unity which isn’t the best for workflow.
We are aware of the less-than-optimal output from the outline generation, and it is something we would like to look into. However, I do not have any timeframe to share with you on when this might happen.
Just to give a follow-up to this thread from my point of view. There seems to be two ways of using outlines for big textures.
I’m currently exploring 2. In my case, I’m getting good outlines with their algorithm. Doing it manually is also not as bad as it sounds. You might be able to go through a 100 sprites in a few hours as long as you aren’t too perfectionistic about it and as long as you know you won’t do it again. But I prefer an automated solution.
Lastly, 3. is too much work for me.
