Official 2D Sprite Shape is out of preview for 2019.3

Great tool. I've already requested a lot of features in the past, but one more thing I think is very crucial but also very doable in a future update is to add or allow for the option to increase the edge mesh slices from 0 to 1 or 2.

The problem that having 0 slices causes can most easily be seen at the curve of a curved edge, and is even seen in one of the sample images on the SpriteShape manual here <https://docs.unity3d.com/Packages/com.unity.2d.spriteshape@3.0/manual/SSController.html>

I think for most projects, a flaw in the mesh this significant makes it unshippable.


I think the problem is due to the long triangles generated for the vertices of a curve causing it to not properly correspond with the uv positions of the texture. One solution is to add slices into the mesh. Even just 1 slice can fix it most of the time or at least make it unnoticeable enough. If it causes too much overhead for mobile, making it an option would allow more flexibility for projects targeting PC where the extra mesh data is negligible.

I've made dynamic ribbon meshes in the past with a similar shape as the spriteshape edge meshes that had the same exact problem at curves, and I fixed it by adding slices. As an example:



I don't know for sure, but I think it should be relatively easy to add.

That's the only solution I'm aware of, but if there's a better solution to the problem then go with whatever works best.

*I have an unrelated question, I'm actually curious how to even achieve the above image with broken-mirrored point mode.
When I tried using the same texture, no matter how many settings I tried changing, I couldn't figure out how you got rid of the caps in the center and combined the meshes. This is what happens when I do it (version 3.0.8) :

 

I've already asked this in the previous thread and I'm sure you're tired of hearing it, but I want to elaborate slightly more.

Dedicated corner sprites are great, but for a high quality edge texture, making each individual corner can be more time consuming than making the edge texture itself. And you have to potentially do it 8 times and most of the time it only works with a single edge texture. And making sure it's perfect and there are no seams can get ridiculous. This is a lot of extra work and depending on the resources an indie dev has, it can be very limiting.

Adding another type of linear tangent mode to autogenerate a corner mesh for points whose adjacent edges share the same texture can speed up art design and level design by tenfold for developers who just want a sharp corner.

Using a sample image from the SpriteShape manual again to showcase my point:


I think for a lot of people the edge caps shown above are a big problem. And I could be mistaken but I don't think there's a way to do it in the current version of SpriteShape.

I quickly made a very rough mesh generation script that shows what an auto-corner tangent mode could do using the same texture:

Here's a video of it for further demonstration:

I'm new to dynamic mesh generation in general and don't know the best way to properly assign verts/triangles and uvs, so I'm sure you guys could make it work even better.

It obviously can't work for all types of edge textures or texture detail, which is where having the current dedicated corner sprites comes in handy, but for I think the majority of textures it can work very well. Here's a quick rocky edge texture I made to show how well it can work for other textures.

I'm sure making it work for the entirety of a spriteshape is an entire challenge of its own that's way out of my league, but I genuinely think it would improve the tool a great deal and save a lot of both art dev time and level design time as well as give designers more options for creating the perfect terrain for their needs.

 

I think Sprite Shape is fantastic, but I have seen a few issues and limitations that are preventing me from using this in a production setting. These all seem to be around setting a custom pivot point, so you can adjust where the sprite sits along the spline. I'm using Unity 2019.3.0f6 and Sprite Shape 3.0.8

1. [Bug] Colliders are not generated correctly when a sprite's pivot point is set to custom. As you can see in the image, the pivot is set so that the spline should align with the top of the image, but the collider is generated as though the pivot is set to 'center'. The 'legacy collider' from the Sprite Shape Extras package does generate correctly, and could be used as a work around for the collider generation, but this conflicts a bit with the second issue...


2. Corners are not rendered when the sprite's pivot point for an edge is set to custom. Even if the corner and the edge have their pivot points perfectly aligned (for example both are the same height and have their Y pivot set to 0.6) no corner is shown. My best guess is that this is related to the first issue, it would seem the corners are not rendered because the alignment is not properly calculated.

3. This is more of a feature request, but I want to set an offset for the sprite borders and corners, relative to the spline and collider. For example I would like to be able to create a sprite shape where the corner extends beyond the spline/collider. As well as one where the corner is within the bounds of the collider. This does not seem possible right now as changing the pivot for these sprites results in some strange stretching.

 

I agree with this 1000 percent and have been bashing my head against a wall trying to find graphic workarounds without code. Please consider both these points for future releases!

 

My main concern with SpriteShape is that it kind of puts developers in an awkward position and would appreciate some more clarity regarding feature requests.

The reasoning is that SpriteShape still lacks a lot of what I consider important features, some features that assets like Ferr2D have. The problem is that SpriteShape is still taking away some of the market share from assets like Ferr2D, which there's nothing inherently wrong with, but it inhibits incentive to produce new or even maintain/upgrade existing assets like Ferr2D (the developer doesn't seem interested in supporting it anymore (partially because of SpriteShape's existence).

I have no desire to sound rude or overbearing, but it has been almost 2 years now since SpriteShape released and there haven't been many if any big feature additions since the original SpriteShape version. Is it possible to provide a bit more transparency about feature requests you're actively investigating, intending to implement, and or have already deemed undoable/unfeasible? Because it would help developers looking for specific features to make the decision to invest the time into making their own version of spriteshape if you have no intention of adding them. Although the mere existence of SpriteShape makes that decision even tougher to make because any aspiration to turn that invested time into making it into an asset is lessened by the already divided market share and the possibility of SpriteShape potentially having those features added to it later that would make the 3rd party asset obsolete because in-house support is always better.

So I'm just looking for a bit more clarity so I know if I'm wasting my time waiting, because I know Unity devs are busy doing a thousand different things besides SpriteShape and I've said this before but allocating a bit more dev time to SpriteShape to add a lot more key features would make SpriteShape the one-stop shop for non-tilemap 2D terrain and would put Unity on the map for high quality 2D terrain development and pave the way for developers without the ability to make their own tool to have the ability to make very interesting platformers and metroidvanias and new and original 2D genres.

Thanks and I genuinely do not intend to sound ungrateful of the work you've already put into SpriteShape.

 

Thanks for the reply! It is good to hear that the bug report was received. If this is being addressed than I would prefer to use the normal collider functionality, as this simpler, and more consistent to setup.

Until this is addressed I have been using the Legacy Collider from Sprite Shape Extras, which does produce a cleaner collider overall. I suspect this is related to the issue I've already logged, but the normal collider tends to generate small edges that do not match the spline. Whereas the legacy collider is always pretty clean. Hopefully by addressing the sprite pivot issue with normal colliders, these small anomalies will also improve.



Having worked with the corners a bit more I was able to get a better result (and makes sense how the corners are meant to align).
Also, I can see how sprite variants could serve as corners without distortion... but seems to require quite a bit of manual adjustment for every corner, and forces you to alter your collider shape.

Again thanks for the update, any other info about progress, roadmap, timing or any other development details are greatly appreciated!

 

I'm trying out SpriteShape for the first time, it looks really good and intuitive.

However i'd like the edge collider to follow the edges too, is that in any way possible?


This is the collision generated, i can increase the Offset to generally include the edges more, but is it possible to really follow the outlines of the textures?



When i compare the polygon collider with what is generated its much more detailed.

I just tried the GeometryCollider as well, which promptly runs out of memory.


Thanks in advance!

 

I have a game that for various reasons needs 3d physics but would really benefit from this capability- is there any way to extend to work for 2.5d/3d? Ideally it should use box colliders similar to how ragespline used to do it, so that even though it's appearing in 2d, it supports collision with 3d objects.

It's such an amazing package.

 

Hey, I’ve been using Sprite Shape quite a lot recently and really enjoying it. One small pain point for me is how snapping works when editing the spline, having it be toggled via a checkbox in the inspector is quite annoying and against the standard UX of how other transform handles work with snapping (hold ctrl) in unity. I switch between snapping on/off quite a lot during editing a level.

I understand this is a pretty small issue but are there any plans to address this in a future release perhaps? (I’m on 2019.3 and latest package)

To me it seems pretty odd to have it as a check box but maybe there’s a reason for it or maybe I’m missing something.

 

Could we please get corners for open-ended shapes (just edges without fill basically)? None of the current corners work for them at the moment, regardless of the corner threshold, leaving open-ended shapes with cropped-off ends, which can't be used in any scenario unless you hide the ends behind other objects :\

EDIT: Realised we can do this already, by adding in the ends of the edge as sprite variations for the edge, nevermind!

 

Aside from the snapping issue already mentioned (you have to turn it on every time you select a different sprite shape), I've noticed that the snapping is not affected by the snap settings 2019.3.
It seems like unity has switched to new snap setting preferences, and spriteshape is using the old preferences (which are no longer directly accessible through the editor).

I had to write a small custom editor in order to modify the snap settings that do affect the sprite shape points.

Code (CSharp):

1. using UnityEngine;
2. using UnityEditor;
3.  
4. public class EditSnap : EditorWindow {
5.  
6.     public static float snapX {
7.         get { return EditorPrefs.GetFloat("MoveSnapX"); }
8.         set { EditorPrefs.SetFloat("MoveSnapX", value); }
9.     }
10.  
11.     public static float snapY {
12.         get { return EditorPrefs.GetFloat("MoveSnapY"); }
13.         set { EditorPrefs.SetFloat("MoveSnapY", value); }
14.     }
15.  
16.     public static float snapZ {
17.         get { return EditorPrefs.GetFloat("MoveSnapZ"); }
18.         set { EditorPrefs.SetFloat("MoveSnapZ", value); }
19.     }
20.  
21.  
22.     [MenuItem("Tools/Set Snap", false, 120)]
23.     static void Init() {
24.         EditorWindow.GetWindow(typeof(EditSnap));
25.     }
26.  
27.     void OnGUI() {
28.         GUILayout.Label("Old Snap Settings?", EditorStyles.boldLabel);
29.         snapX = EditorGUILayout.FloatField("Snap X", snapX);
30.         snapY = EditorGUILayout.FloatField("Snap Y", snapY);
31.         snapZ = EditorGUILayout.FloatField("Snap Z", snapZ);
32.     }
33. }
34.  

 

Hello!
What this red warning means:
"Dimensions of color surface does not match dimensions of depth surface
UnityEngine.GUIUtility: ProcessEvent (Int32, IntPtr)"?
It looks like it appears when working with Sprite Shapes, but I'm not sure.

 

I'm currently doing some optimization with my game and currently, the item causing the highest "Time ms" in the profiler is the following:

Is there anything I can do to reduce this number?

 

Yes, I saw that the problem is resolved. Thanks.
I do not know how anyone, but I decided after SpriteShape_3.0.9 update.
Thanks again!

 

I just updated my project from Sprite Shape 3.0.8 to 3.0.9 and now I get this:
Any ideas? Really don't want to go edit all my sprite shapes.

 

I can't easily submit my project, but I do know how to make the issue happen now.

It has to do with setting angles on the Shape Profile:





Is there a better way to use a single texture for all angles? I guess I could use the same texture multiple times and use smaller angles.

 

Ok, here's the bug I reported regarding this error. Along with sample project.

https://fogbugz.unity3d.com/default.asp?1227402_d1vfqjhmljri3urc

 

Getting severe performance hits in the editor when many SpriteShapeControllers are on screen. Is there some flag I can set that will reduce the work being done? Does it need to be doing all that work for each object every tick? I would like to keep using this, but the 51 here only represent one scene, and there are many more to go, so the performance issues present a challenge.



With Deep Profile enabled:

 

Regarding your suggestion to #3 specifically, it comes with a relatively large drawback that I think I mentioned in the original spriteshape thread over 2 years ago. Many if not most 2D games (those using orthographic camera instead of perspective) use transform position offsets for their midground/background objects to create a parallax effect . Like you suggested, in order to composite smaller spriteshape pieces together you need to use worldspace UVs in order to sync their fill textures. Which is great, but the big problem is that it only works for static objects because it becomes permanently synced with worldspace UVs. This makes it so the fill texture doesn't move with the transforms, which makes moving composited spriteshapes impossible with worldspace UVs enabled.

From what I understand, and I could be wrong, the solution is incredibly simple: when worldspace UV is turned on, just have it keep that value when it's turned off. That way you can move the objects you synced locally again and the fills still match.

I apologize for the implication of the bold lettering.

 

1) No, they're only being used for greyboxing the world at the moment. I wanted to see if that worked before using it with final art. Play mode is not enabled when the performance issues surface. The previous images were while profiling the editor.

Here is another example:


2) Tried it. Burst did not help improve performance in the editor.
3) They are fairly large, but why would this help? Again, the profiler shows this work is being done every tick, when play mode is not active. Other areas of the project have thousands of sprites being rendered on screen without this performance hit.

It will take some time to get a repro project put together.

 

This is what the profiler graph looks like when I'm not pointing the scene camera at the Sprite Shape Controllers. You can see it went from over 66ms to under 5ms.


Another example, this time starting with the Sprite Shape Controllers in view, and panning away from them:

 

Here you go @Venkify . Drop this into an empty scene and you should immediately see the latency in the Scene view.

I tested this in a new, empty project, with only 2D Common, 2D Path, 2D Sprite and 2D SpriteShape imported from the package manager, and it was still happening.

 

@Venkify
That was the root cause, thank you. I had a profile set in one, but must have overlooked the others. Thank you for helping address this. I'll pay more attention to that if this comes up again.

 

Unity 2019.3.7f1 with SpriteShape2D 3.0.10 - I'm getting hundreds of the following errors only in a built project - everything is fine in the editor.

NullReferenceException: Object reference not set to an instance of an object
at Unity.Collections.NativeSlice`1[T].get_Item (System.Int32 index) [0x00001] in <73b499366e5241bda47e5da76897738b>:0
at UnityEngine.U2D.SpriteShapeGenerator.TessellateContour () [0x0016b] in <f2e56af3bc4f462baa9031725d650bbe>:0
at UnityEngine.U2D.SpriteShapeGenerator.Prepare (UnityEngine.U2D.SpriteShapeController controller, UnityEngine.U2D.SpriteShapeParameters shapeParams, System.Int32 maxArrayCount, Unity.Collections.NativeArray`1[T] shapePoints, Unity.Collections.NativeArray`1[T] metaData, UnityEngine.U2D.AngleRangeInfo[] angleRanges, UnityEngine.Sprite[] segmentSprites, UnityEngine.Sprite[] cornerSprites) [0x0004b] in <f2e56af3bc4f462baa9031725d650bbe>:0
at UnityEngine.U2D.SpriteShapeController.BakeMesh (System.Boolean needUpdateSpriteArrays) [0x00329] in <f2e56af3bc4f462baa9031725d650bbe>:0
at UnityEngine.U2D.SpriteShapeController.OnWillRenderObject () [0x00028] in <f2e56af3bc4f462baa9031725d650bbe>:0

I was unsuccessful in making a repro project so I decided to report it here.

 

Unity 2019.3.7f1 + 2DSpriteShape 3.0.10 makes my game crash, the crash only occurs on the phone (It runs without any error in the editor) : (

 

Hello Venkify, I can't make the test project at the moment.
But I have more information from my testing.

I also have the problem with Unity 2019.3.7 + 2D Sprite Shape 3.0.9.

Downgrading to Unity 2019.3.6 + 2D Sprite Shape 3.0.8 fixed the problem.

 

Please get the test project here https://drive.google.com/open?id=1XxXZAQFy2NA-vam6oGdxb_NYreDGNJSM.

Cheers!

 

Thank you very much. I'm looking forward to hear the result.

 

I'm seeing a number of issue caused by this lack of a profile shape. Maybe something in the editor to hint more strongly that it is required would be good.... or just require it in editor since it's require at build time anyway. Just a thought.

 

Thank you I'll fill the profile shape and test the game again ^^

 

Hello. We are using SpriteShape 3.0.10 with Unity 2019.3.7 and we have a weird GC Allocation that seems to be coming from SpriteShapeController.OnGUI(). We have this GC Allocation in a full build.



As we can see, SpriteShapeController.OnGUI() is called 32 times and GUIUtility.BeginGUI() produces the GC Allocation. Is this something known? We do not have any GC Allocation when the SpriteShape object is disabled.

The other question I have is why the SpriteShapeController.OnGUI() called in a full build (ie: not in the Editor)?

 

Hello is there an option to split a larger spriteshape into smaller parts? if not is there any consideration to Implement it further down the line?

 

That was the reason - added the profile and the error is gone. Thanks!