Official 2D Sprite Shape is out of preview for 2019.3

I came here to ask the same thing, I'm also seeing this GC Alloc from SpriteShapeController.OnGUI() and as it's the only IMGUI thing used in my project it's causing the whole overhead of IMGUI to be added as well (cpu time and GC Alloc).

I've removed that code locally from the package. I could be wrong but it doesn't look like it's doing anything useful. BakeMesh is already called in OnWillRenderObject so that shouldn't be needed and the rest of the code in OnGUI seems like it's just doing another render of the sprite shape to a temporary render texture and then discarding it, which seems super odd.

It would be nice if this was removed officially as then I don't need to maintain a local modified version of the sprite shape package

For reference I'm on Unity 2020.1.0b5 and SpriteShape package version 4.1.0.

 

Looks great. Will that be available in the 2020.1 beta or is it only in the 2020.2 alpha? Tools to automate precise curve types and a solution for the edge mesh funkiness where the texture gets lines at curves and SpriteShape will be an unstoppable force. Speaking of that edge mesh funkiness issue, in another attempt to fix it I tried using this tessellation shader https://catlikecoding.com/unity/tutorials/advanced-rendering/tessellation/ to see if it would help as seen below with a well-tessellated mesh from the spriteshape samples, but it doesn't seem to affect the issue:

I could be missing a step though, because it seems like it should be different. The texcoords are being interpolated in the function and it appears to work for the vertices, but I have no idea how it really works so I can't say much about it. The texture stretching part I understand is unavoidable, but the mismatching of the vertex positions and the uvs to cause those long lines I'm sure is fixable, I just don't know how.

 

setting SpriteShapeRenderer.color doesn't work for me... not in the editor and also not at runtime. something Im missing here? Using version 3.0.10

 

Hi, are there any plans on an option to overlap/blend the pixels between 2 edge sprites in the same spriteshape? Right now it leaves a glitchy looking gap that can be quite visible at certain distances/angles, ideally it should blend well like between two nodes of the same edge sprite. Best I can do at the moment is adjust the angle between the two nodes to reduce how visible it is, but I'm unable to get it to disappear completely it's also a bit limiting design wise as I can't have it bend anywhere near as much as 2 nodes with the same edge sprite or the gap will be absolutely massive between the two nodes, rendering it unusuable.

 

Changes are not saved.

 

I'd love a way to get a reference to the mesh that SpriteShape generates. Is there a way to do this? I can't find any.

 

Thanks for the answer!
Most likely I will do so - I will place the package locally.
I’m just waiting for these small corrections in the URP for 4 months now.
I hope we get these corrections to the URP.

 

Seems it was my fault, there was a little bit of transparency on the edge of the sprite which was causing it. Thanks!

 

Hi, I'm on 2020.1.0b10 and Sprite Shape 4.1.1.

SpriteShapeController.cs still has a OnGUI function. Merely using this legacy IMGUI function in a built player causes large GC allocations every frame as it triggers the IMGUI repaint (see screen shot). I know I've complained about it before, but OnGUI really shouldn't be used here. If the code in there needs to be done every frame it should be done in Update or depending on other context then somewhere else, but really not OnGUI

 

That's good to hear it's been removed for the next update also thanks for replying so quickly!

For reference, and in case anyone else comes across this, using OnGUI for a on scene load callback seems super hacky. Instead Awake(), OnEnable(), Start(), or even adding a delegate to SceneManager.sceneLoaded should all be better alternatives for a on scene load callback and will avoid the overheads that come with having any OnGUI functions present in a build.

 

Hello here,

I think I have a pretty advanced question and I have not been able to check if it has already been asked here (or in the previous thread)

My question is:
When I programatically add a polygon collider 2d to my sprite shape object, I found out that it is not "generated" right away, it takes some time.
What will be a good way to find that the collider is ready?

Right now I'm using a pretty shady trick, see by yourself:

Code (csharp):

1. var terrainCollider = terrain.gameObject.AddComponent<PolygonCollider2D>();
2. // Here the polygon collider does not reflect the shape of the sprite shape (yet)
3. yield return new WaitUntil(() => terrainCollider.GetPath(0).Length > 5);
4. // From here the polygon collider if ready and we can do stuff...

but even that trick does not work reliably

Any idea how I'm supposed to do?

 

am having issues with the spriteshapes not displaying in the editor, even the ones from the samples

 

Hey. Great tool. I was wondering if anyone knows how many spriteshapes I can put in a scene, say, for a mobile game. Thanks

 

@Venkify I noticed that when SpriteShape objects are visible in SceneView, even just one, my CPU usage goes through the roof.

I reproduced it in a new project with nothing but the sprite shape samples installed. Add any number of sprite shape to the scene, and whether they're selected or not, my cpu usage spikes up to 40%+ when in sceneview, and drops back to 0% immediately after there are no spriteshape objects on screen, even if it's still in scene and i just pan the sceneview camera off them or switch to gameview even if they're still being rendered in gameview.

The number of spriteshape objects doesn't affect it, so whether it's just 1 or 500 shapes, the same amount of CPU is being used.

Using 2020.1.1 and SpriteShape 4.1.2

Based on profiler I'm guessing it's all from SpriteShapeController.OnWillRenderObject() every frame in sceneview, though I don't know for sure.

 

Hi! When a control point on a spline is created, it's Height parameter is always 1. So if I want all points to be at a specific Height, every single time I have to manually adjust a newly created point. Is there a way to make it easier? If not, would be great if new points got assigned an average of their neighbors' Height, for example.

 

And one more thing: is it possible to assign a shortcut key to the Edit Spline button? I find myself doing tons of unnecessary mouse movements to turn the edit mode on and off. I have a lot of sprite shapes, and It becomes annoying really quick to click that little button in another window, twice per edit.

 

Hello, would it be possible to have some sort of smooth alpha blending between edges and the fill? Would open up a lot of possibilities and simplify the sprite creation process for sprite shapes greatly, and also give it a major feature that none of its competing third party solutions offer. Otherwise my experience with spriteshape is pretty good at the moment, keep it up guys

 

A couple of feature requests.

Ability to randomise the edges and the fill
Ability to extrude some depth on the Z axis to the the edges
Function to get any position along the spline edge (not just the points)
​

Thanks for the hard work so far!

 

I've discovered a rendering issue: It appears that the shape stops rendering as soon as none of the vertices are within the view frustum. This would be fine, but if the path is thick or sharp corners are used, there will still be a significant portion visible on the screen when it disappears. Could the culling range be relaxed a bit? Thanks.

 

Hello, I'm looking for an old version that had isDirty exposed:

Code (CSharp):

1. public bool isDirty
2.         {
3.             set
4.             {
5.                 this.m_isDirty = value;
6.             }
7.         }

https://forum.unity.com/threads/spriteshape-preview-package.522575/page-1

Does anyone know where can I find it? I have my reasons trust me.


Also, where is SpriteShapeRenderer? It was part of SpriteShapeModule/UnityEngine.U2D

 

@Venkify Afaik it's still not possible to set the Offset of a fill-texture seperately in Y or X and is there also a reason we only can go +-0.5 and not overshoot as we like

 

Not sure where I'm supposed to submit the bug, but here's a repro in an empty project: https://www.dropbox.com/s/tnp8r75duwpjqfc/SpriteShapeRepro.zip?dl=0

 

I dont need old documentation, I have a project that depends on older version of SpriteShape and I need to old version to work with the project.

 

Fair enough, what about the other question: it's still not possible to set the Offset of a fill-texture seperately in Y or X, will this ever be the case?

 

2019.4.2 but the SpriteShape package was older. The only thing I know if that it has exposed property isDirty, see my first message here above.
Later versions removed it. I'm looking for the versions that had it.

 

Hello,
I have the same problem i had some months ago.
I had a project with URP and 2D renderer, using Sprite-Lit-Default material in a SpriteShape object i was not able to change color from the inspector, i had to create a new material and change the color from it.

I build an apk but if i use the 2D renderer i get an "the hardware does not support this application" error. If i don't use the 2D universal render pipeline it works just fine. So i removed the 2D renderer and created a URP Forward renderer. The app works but I have the same problem as before, i can't change the color of the sprite from the inspector, only from the material.

How can i fix this?

Thanks

 

Since edges and fills use different materials now, is it possible to make two separate Colors on the SpriteShapeRenderer component to affect each individually? I understand now with custom shaders in order for the Color on SpriteShapeRenderer to affect the material the shader's variable has to specifically be named _RendererColor and I can make a custom script that exposes an inspector Color value to change it, but it'd be nice for the official SSR component to expose the Renderer color of both the edge and fill materials individually.

 

It would be great if SSR supported SRP batching.

 

Hello everyone
I would like to ask you guys, if you have any clue why spriteshape is not rendered in
inspector preview window, as shown on pictures attached.
Thanks in advance !


Edit: Unity 2020.1.6f

 

Hi! This might have been asked before, but could you please fix so that editing a sprite shape has the same interface as editing polygon colliders? At least I'd like a mouse/keyboard shortcut to delete a point.
CMD+Click doesn't seem to do anything, and it would be a lot easier than click and then CMD+backspace
(Or CTRL for Windows users of course..

 

What decides what sprite to use per angle range? I want a different sprite when facing downwards in the shape. I illustrated it with a darker color, and it appears to show the sprite which has an angle range of -135 to -225 (90 degrees down) even it the shape doesn't seem like it does.

I tried fiddling with "Enable tangents" and switching tangent modes. I like the continuous mode most for the shapes it gives, but depending on what mode i choose for each point, it uses different sprites, and sometimes seems to default to the "up" sprite.

My ultimate goal here is to make a shadow below the shape, but I'm considering testing out making a shader instead. Is that possible?

Thank you!

 

I tried to make an outline shader to have shadows below the sprite shape, but it feels like it always goes in all direction, no matter if the outline shader only goes downwards.. Is it applied to each sprite before it's bent?

Is there any way to apply a shader to the entire object, without using a render texture?
Or should I clone the object and make it black and lower opacity? Seems kind of wasteful.

 

You guys added the request for letting you stretch edges to make auto corners, which is absolutely great, but it does cause some issues with the edge texture being stretched, and depending on the type of texture it can be a big deal. Ferr2D manages to set up the verts/uvs in a way to minimize the stretching to a very small part of the corner and maintain the integrity of the edge texture.

As seen here: left is SpriteShape with one of its package sample sprites, right is Ferr2D with the same texture.



I do understand that creating code to automate this type of mesh generation to work almost flawlessly is incredibly difficult, but I think it'd be worth attempting in order for the tool to be used to create professional looking scene assets.

Also it's kind of hard to see in the above image, but Ferr2D has 1 extra slice in the middle of their edge meshes to help prevent texture uv warp. This is really important. In the image below, I have another spriteshape package sample sprite on a SpriteShape on the left, and the same texture on a Ferr2D on the right.



As you can see, just that one slice in the middle of the mesh alone is enough to significantly reduce that texture warp around sharp curves. It's not perfect, but it's clearly a very big improvement because the left is in my opinion not something that's viable to ship in a final product, and there's no way to improve it with the current SpriteShape.

And I'm also almost positive that doing this wouldn't break any functionality at all, which you alluded to in my previous request for this feature. I can't imagine what it could break, since it would be virtually identical both visually and functionally for 99.999% of people using spriteshape, but I might not be accounting for something and I would be interested to know if there's a case I'm missing.

Also you had mentioned 2 years ago an interest in creating more accessible curve-creating features, since bezier handles, while nice, are very limited for creating pixel precise curves like a sonic halfpipe for example. It's still possible, but in my experience incredibly time consuming and unreliable. Features for nodes to automate the creation of specific angled curves would still be a great QoL addition.

Also this is a low priority request since it would require a rework of spriteshape using vector2s into using vector3s, but adding a Z-slant feature to edges would be nice for creating a slight parallax effect for thick edge textures, so if indoors, the back wall can be slightly further in the Z to be at the same Z-distance as the back of the edge vertices (assuming perspective camera, which most if not all the big non-mobile Unity 2D games use, like Ori, Hollow Knight and Rogue Legacy 2) to allow for a slight parallax which in my opinion greatly increases a subtle depthy immersion.

I truly think these changes are worth making in order to make SpriteShape usable for a much larger amount of 2D developers, because I think in its current state the vast majority of serious 2D developers instantly reject it because of its amount of flaws that make it almost impossible to use spriteshape to make something professional-looking that also has flexibility.