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

Unity Engine
,
1

I am getting this warning in the editor with Unity 2022.2 and SpriteShape9.0.1. According to the below thread, this was fixed in v.4.0.2 of SpriteShape2D.

Any help is appreciated. Thanks.

2 Likes
2

Any possible help on this from the Unity team? I am concerned about what this would mean to my game. Thanks.

1 Like
3

Got same issue :confused:

1 Like
4

Same here, can’t upgrade to the latest version of Unity because of this issue breaking my levels, so I’m stuck on 2021.

5

same issue

6

Same issue here.
Shocker unity wants to charge you a runtime fee but not answer any questions in the forums like the good ol’ days.

7

I’m also stuck with Unity 2021 and SpriteShape 6.0.2. I’d like to upgrade to one of the newer versions that handle snapping better, but if I upgrade SpriteShape I get “Mesh data has reached Limits.” all over the console.

I don’t think this problem is related to the issue linked to in the first post, because the number values of angle ranges don’t appear to have any effect as far as I can tell. What does have an effect is having a sprite edge, though. No edge sprite, no warnings.

The shapes I use are often very simple, but they can be large. It’s possible to have mesh data reach its limits simply by having three linear control points if the triangular shape covers enough area.

The old SpriteShape 6.0.2. has no problem with shapes of the same size, so it would be nice to know what’s going on. Is this a bug or an intentional change? What exactly is this mesh data and what’s limiting it?

@Venkify , any ideas?

8

I reported the bug officially way back in September, and this was the response I got after waiting 3 weeks.
9509164--1339957--upload_2023-12-3_21-9-54.png

It seems like they do not care. I replied with this immediately after, and have not gotten any responses since:

Hello,
Thank you for the response. I do not believe your decision is a fair and acceptable solution.
In developing my game with a previous Unity version, I heavily utilized Sprite Shapes to construct extensive 2D areas. The non-existent mesh data constraints in that version facilitated this design choice. The new constraints introduced in subsequent Unity versions result in breaking these levels, compelling me to stick with the outdated version, which is inherently unjust. Any official asset should not obstruct upgrading to newer engine versions.
I suggest that, acknowledging this as a predicament stemming from an oversight in earlier versions, developers should be given an option to disable the mesh data limits, albeit with these constraints enabled by default. This alternative ensures new users abide by the mesh data constraints while also not penalizing previous users by enforcing them to either remain on older Unity versions or overhaul all SpriteShape uses in their entire projects.
I highly encourage you to seriously reevaluate your decision. Leaving it be would be destructive change and is unacceptable.

It has now been ~6 weeks since I sent them the above mail, and considering I’ve yet to receive a response, I doubt they’re ever going to change this. Guess I’ll just have to stick with Unity 2021… Phenomenal.

1 Like
9

Ah, so we still don’t know what the constraints actually are and why they’re a problem. And why is using smaller/multiple shapes recommended?

I just tried updating my project to 2022.3.9 and SpriteShape 9.0.2. Level geometry would appear to look ok and I can edit the shapes just fine, the console is just being flooded with warnings.

10

Apologies for the delay.

Could you all please post the warning or better a sample project ? Will take a look asap.

11

Perhaps the easiest way to demonstrate the issue is this:

  • Create a new project using the URP 2D project template and the current Unity LTS version (I used Unity 2022.3.9 when testing this, SpriteShape 9.0.2).
  • When the project opens, add a closed Sprite Shape to the scene. Keep all of its settings at default.
  • Zoom out a bit and edit the shape. Move the shape’s points away from the default starting shape’s midpoint until you start getting stuff in the console. The shapes don’t need to be massive, just… largish.
  • You will see the message “Mesh data has reached Limits. Please try dividing shape into smaller blocks.” repeating in the console, always first as a regular logged line and then as a warning right after that.

If you’re using shapes to represent, say, an area of 2D terrain with curved hills and valleys, it can become very difficult to split that shape into smaller ones without very obvious seams (especially since SpriteShape doesn’t have any functionality for splitting a shape in two). But apparently that should be done anyway to avoid the negative effects of using big shapes? The problem is that the most obvious negative effect I’ve seen so far is the spam in the console.

What is the limit that’s being reached and what does it mean in practice? If it’s a hard limit, why does SpriteShape continue to work when the limits have been reached, only complaining a lot?

It would also appear that when comparing shapes with Detail set to High Quality and Low Quality, shapes with quality set to High can be much larger than shapes set to Low? I find this a bit counter-intuitive, you’d think that a high-quality spline would generate a mesh that reaches mesh data limits sooner?

12

After the four steps I described in the previous post I made the shape much, much larger and more complex. This started appearing in the console at some point:

This would appear to be a more concrete example of hitting mesh data limits? Strangely enough the shape still continues to render and be editable even at this point.

The warning mentioned earlier about reaching mesh data limits appears to be based on an expected count of vertices in the shape, an estimate?

1 Like
13

Presumably it’s related to the Mesh index fomat used:

14

That is my guess also, but it’s very unclear.

Shapes that are ok in older versions of SpriteShape (like 6.0.2) are inexplicably not-ok in newer versions (like 9.0.2), but the only apparent problem is warnings in the console. Any attempt to edit the shapes results in hundreds of identical lines being logged. Despite this the shapes appear to render just fine and also work in (desktop) builds.

The logged warnings appear to be based on an estimated number of vertices in the generated shape? I’d be curious to know if these estimates are correct and mesh data limits are really being reached?

This issue has already been reported as a bug and is apparently “by design”, but that didn’t really explain what’s going on. If things are working as intended, there’s a problem in SpriteShape’s editing UX. There’s no way the flood of vague warnings in the console can be considered an ok level editing experience.

15

If this warning appears, it definitely is due to mesh indices growing beyond the supported 16 bit limit. Mesh should still render with the vertices until that limit.

If the UV is worldspace, multiple parts can be seamlessly rendered but I do understand the complexity to design if its a considerably large level.

There have been changes to tessellation since version 7.0. Could you please post the issue ID or report a bug with a simplified repro ?

16

Midsummer has show the simplified steps to the issue at #11, even if the shape is not large, this problem can still occur on 9.0.2 which result in missing shape’s edge rendering.

Changed the worldSpaceUVs is useless, what effect does this property have on the number of rendered meshes?.

I don’t think this design should be present, or at least provide one ez way to modify the IndexFormat to UInt32. Otherwise, for a continuous horizontal level, each shape is to small.

1 Like
17

Yes, exactly. Also, there is no need for a “simplified repro”. All you have to do is make a SpriteShape2D, then just move one of the spline points a fair distance away. That breaks it - it will start spurting warnings, refuse to render, and the collider won’t generate. This asset is practically useless as long as this issue persists. Such a shame.

@Venkify Is this something you could look into soon? I can’t be the only one getting increasingly more frustrated with being stuck on old Unity versions.

1 Like
18

As geometry is generated on a Job, we pre-allocate memory for geometry data. We evaluate various parameters to approximate the required vertex count and this may still not enough depending on the setup of SpriteShape Profile and the Spline.
We could pre-allocate 65536 at the cost of additional memory.

We have fixed a number of issues related to the above and would request to use the recent version. If the issue still persist, please try the following workaround :

  1. Move the spriteshape package to ProjectFolder/Packages folder to make it editable.
  2. Modify function
    internal int CalculateMaxArrayCount(NativeArray shapePoints)
    in com.unity.2d.spriteshape/Runtime/SpriteShapeController.cs to always return 65535 (max limit)
        internal int CalculateMaxArrayCount(NativeArray<ShapeControlPoint> shapePoints)
        {
            return 65335;
        }

We are considering to update the index format to 32 bit, so there wont be limitations in terms of geometry size. Will keep this thread posted. Sorry for the incovenience caused.

19

Newest version still has the same problem:
5wgy0t

Modifying the CalculateMaxArrayCount function does not fix it. I did this:
9624698--1366787--upload_2024-2-5_12-0-31.png

What does fix it is commenting out this check in SpriteShapeGenerator (which wasn’t there in older versions!):
9624698--1366793--upload_2024-2-5_12-1-29.png

Doing so lets you make SpriteShapes as big as you want - just how it used to be - and no longer does it refuse to render the sprite/mesh while spamming the console like in the above video. This is how it should be and how it used to be.

At the very least, give us the option to turn that check off if you care at all about backwards compatibility. Otherwise, people like me who used the old version are forced to change all of their level design to accommodate this seemingly arbitrary check.

The following demonstrates the asset working as it did originally after commenting out those lines of code:
5znhbl

9624698--1366790--upload_2024-2-5_12-1-18.png

20

Please note that without this check, data will be written beyond the allocated memory and might potentially result in undefined behavior. As mentioned above, if the vertex count goes beyond the maximum supported by 16 bit indices, a better way to fix it is to change to 32 bit. Thanks.