Mesh data has reached Limits. Please try dividing shape into smaller blocks.

So what exactly does this mean? Are you going to update the asset to support 32 bit indices instead?

Yes, we are considering to move to 32 bit indices. Will keep this thread posted. Thanks.

1 Like

Alright, that sounds good. I look forward to it.

Any news on this? It’s been about a month now, still waiting for this so we can update to the latest Unity version.

This is getting ridiculous. No news for over a month, still stuck on a several years old version of Unity.
It would be nice to get an ETA or something. Any kind of communication is appreciated…

Please, this needs to be addressed ASAP, it’s honestly embarrassing.

The changes have been implemented. Please note that,

  1. This is a breaking change and will not be backported to older versions.
  2. All changes go through rigorous QA testing to test on supported platforms etc… before being merged
    This takes time. Hope you understand, Thanks for your patience.
    Will keep this thread posted.
2 Likes

Thanks for the update. I fully understand that this takes time for the listed reasons. But when I hadn’t heard anything for over a month, I got worried whether this was being worked on. I’m glad to hear that it is.

When you say it’s a breaking change, does that mean we will have to redo all of our sprite shapes anyway?
Surely it should be possible to implement backwards compatibility if the only major change is the index sizes, especially considering they can hold more data now? I don’t know, maybe I misunderstand the situation.

  1. New features
  2. Changes that require API breakage.
    are not backported.
    Also please note that we also found a related bug and are fixing it.

What?? Why not backport? That doesn’t solve the problem at all then!
This means developers who used the older versions of SpriteShape2D will be forced to stay on old versions indefinitely!

The entire point of this thread was making it possible for older users of this to migrate to newer Unity versions without breaking their level designs. Changing everything and breaking the asset for everyone doesn’t solve anything!

I can’t be the only person who’s sick and tired of using official, non-experimental, fully released Unity assets only to have them break my entire game when I update the asset or engine.

I’m sorry for the frustrated response, but this is not acceptable. It doesn’t address the core issue of leaving users on older Unity Editor versions forever lest they want to rebuild all their levels manually.

Usage of 16 bit indices was essentially a constraint/limitation of Spriteshape geometry.
Data that are already stored in 16 bits will fail to load when 32 bit indices lands and hence its breaking change. And we only make breaking change on major versions. Hence this cannot be backported.

However please do note that we found a related error and are in the process of fixing it. If the issue was not due to max limit, very likely the fix should resolve the issue. The fix will be backported to older versiobs. Please follow this link to check for updates :

It would be great if you can submit a repro project with a simple scene that causes the bug, so we can help with the issue further. Thanks.

I already provided a repro in post #19 in this thread: https://discussions.unity.com/t/906448/19

I also already submitted a bug report ages ago, but it was just ignored, as per post #8 in this thread: https://discussions.unity.com/t/906448/8

Sorry for the confusion, do you have the Case ID or a link to the Bug report?
Also based on the description in the post above, I believe the fix should resolve the issue. Note: As mentioned above, bugfixes are backported.
Will test against the bug report as soon as receiving the bug report info.
Thanks.

Hi, sorry for the late reply, had quite a lot happening lately.
The case ID is CASE IN-53534. I reported it about 6 - 7 months ago and was dismissed.

Thanks. We have verified that the bugfix mentioned above fixes the case IN-53534.
The fix will be available in 10.0.5 and will be backported to 9.0.* subsequently. Will post an update as soon as they are available. Thanks.

1 Like

If I think i found a solution.

If you edit the spline on the sprite shape controller and set the points very near eachother and scale the gameobject transform to its original size, it looks pretty much the same.

On the little stats button box in the game window the tris and verts are now much less. I have only tried it with a single color

I think the mesh should be optimized when the Spline Points are far from eathother. For me it looks like the mesh atomar units stay the same

I’m in Unity 6000.0.32f1, 2D SpriteShape 10.0.7

According to Unity this was ““fixed”” but my spline with a mere 8 WHOLE points is too much for this tool.
In my opinion it’s literally useless then.

My spriteshapes has lineart, I can’t just use multiple together or I’ll have ugly lines randomly dispersed throughout the level.

How do you suggest I split this one up??

Please note that vertices are generated for both :
Inner Shape.
Outer Edges (Geometry along the edge of the Spriteshape Spline).

If the edge sprites are small this can generate quite a few vertices for the geometry along the outline. (Higher the Spline detail, higher the vertex count).

If this is not the case, please file a bug report. Will take a look asap.

1 Like

They are indeed small, I need outlines around my platforms so I have certain sides that are a fraction of a unit.