Official SpriteShape Preview Package

Can we render the edited shapes down to PNG?

2.)Can I somehow use sprite masks with them? Wanting layered shapes, and when I change alpha in Sprite Shape Renderer color settings, I can see the background layers through the foregrounds. [pic attached]

 

Tested in Unity 2018.2.8f1

I just added all my ideas about the feature that could be improving. There may be some that not relevant already.

- Point Mode should be independent from corner generation behavior
Currently only Tangent mirrored created corner mesh if I can understand well.
- Click Edit Spline moved the scene camera into not center of mesh, rather some other position
- Selected more nodes can not change Point Mode for multiple nodes
- Adjusting node height corners randomly disappear
- There could be node tangent adjuster parameters like angle and strength also maybe some presets like on animation curves
- ShapeProfile:
- It would be much better to show result on shapes like in the material view circle, box, ...

- Adjustable angle rage for corners to be used
- It would be nice if not only the outer circle is part of the angle rage rather it could be a pizza slice, and also if a sprites could be dragged on a slice to add it.

- This UI element is annoying to use. For every AngleRange I have to click + then add a sprite.
It could work like arrays if you drop a sprite on it it will be added. It could be the same for all similar UI elements that want an asset.

The feature is great keep up the amazing work!


- Also found that the collider is not properly created on the ends if use sprite borders is on.

- If there is a tiny-tiny edge between 2 Sprite Shape colliders than the physics engine randomly pushes away the ball or other object if it was calculated at the sensitive position. This is maybe off topic.
- Node snapping have to be re enabled all the time.

 

So I was giving this package a try as it will probably save me many many many hours in generating smooth colliders from a platform game that I am prototyping howrever one weird thing I noticed is that I get a weird icon in the scene view even though I selected no icon for the sprite shape:



If I selected an icon, that shows up fine:



I assume the first screenshot is not the expected behaviour.

I am using this with the latest beta of 2018.3

 

Hi,
I'm wondering if you have planned to integrate a Width parameter on points, just like you did the Height. Variation on width would give more control on visual variety.

For now, I'm duplicating points to work around this (this force insertion of a full sprite between two points) but it makes it very tedious to maintain or to make changes.

 

Could the auto-generated collider update itself in proportion to the "Height" value of the control points as well as the "Offset" value so that the collider matches the sprite shape as it appears with different widths?

Also, can the "Offset" values range be increased above 1 as this doesn't seem to fit the entire sprite shape sometimes, I had to write another script to get around it since the files are read-only.

Other than that I think the tool is really cool so far.

 

I'm looking to be able to move a sprite along the spline that a sprite shape is using. Any ideas on how I could go about something like this?

Also, if I have a shape with a collider and am changing the shape during the game, is this something that would be considered too expensive?

 

Thanks, @Venkify! The sprinkler example is interesting but, if I'm not mistaken, only places objects at the curve points of the spline. I was looking (and managed to figure using bezier tools) placing along the spline as well.

Good to know about the colliders. Do I need to rebake the colliders if I manipulate the spline programmatically?

Also wondering if the is a way that I can calculate the normal for a point along the curve. Is this something that is part of the BezierUtilities?

 

I have the issue that my point mode settings are greyed out on the shape controller and the edit spline button isn't triggering the point edit mode in the editor window, am I missing somewhat obvious? I have created some spriteshape prefabs a few days ago and now I can't edit them anymore, but my collab colleagues can. Seems like my UnityEditor is broken in that regard. I'm using 2018.2.14f1 and have reinstalled the package. In the next step I will reinstall Unity and report after that again.

Unity reinstall fixed that

 

Hey,
since I've been asked, I did my assert support for SpriteShape.
Small bonus is that SmartDestruction2D exports SpriteShape into traditional SpriteRenderer, so it is being drawn way more efficient in real time.

SmartDestruction2D Thread

Destructible SpriteShape Terrain:

 

I have a question, is there any efficient way of getting bounds from SpriteShapeRenderer?
At the moment I'm using generated edge/polygon collider boundaries, but I believe that's not the most efficient way, therefore it works only when there is collider attached.

 

@Venkify, I was trying out the same field, perhaps I had outdated preview version.
After re-importing SpriteShape from Built-In packages, it worked out.

 

Thanks, Venkify! That's precisely what I did!

 

I have a question regarding the ConformingSpline script included in the examples files. It looks like the code that does the actual conforming is all wrapped in a UnityEditor conditional. Does this mean that conforming won't happen at runtime, for example, if used in an actual game?

 

Thanks again, Venkify!

One more question. I am adding to points to a spline in a script and sometimes get an error that the point is too close to a neighbor. I wrote some code to compensate for that, but I am now encountering that same error when creating a spline in the editor. Is this something to be concerned with?

 

I found what I think is a SpriteShapeRenderer bug. *_texelSize.zw is a random (uninitialized?) value when read in a shader, or as displayed by the frame debugger.

Bug report here:
https://fogbugz.unity3d.com/default.asp?1099636_s2i45t0rg5ngl6vg

Additional information here:
https://forum.unity.com/threads/ret...ixel-art-and-voxel-games.412287/#post-3876631

 

Pressing W so your move tool is selected should fix it as well

 

I noticed that Spriteshape forces each side to be the same length, and the depth order of the corners can't be changed. You can't do something like this:
https://ferrlib.com/demos/Ferr2DTRuntimeEdit2/index.html

Here the top side and the corners go over the left and ride side of the terrain, but in Spriteshape the corner is forced to align to adjacent sides and thus gets deformed and looks weird.
For now i have only found it to work well for simpler stuff that uses the Strip profile with only one sprite for all the angle ranges.

 

Has anyone been able to use this with a drawing tablet? I tried it with a wacom and it's not working...

 

If Sprite Shape had these features, it would instantly be better than Ferr2D:

1. An option to fit the collider to the fill mesh. This lets the generated polygoncollider be much less complex and have perfect accuracy unlike the way it is now which understandably is specifically for fitting the collider to the edges rather than the fill. However, this feature requires #2.
2. More control of the edges themselves:
--a. Vertical offset of the edge sprites (similar to the current offset of the fill, which itself seems pointless to me). This is necessary for #1
--b. Pixels Per Unit affecting edges as well as fill (or an option to)
-- c. Maybe a sceneview handle to swap which edge sprite segment to use, rather than having to set the index in the inspector
3. An algorithm that guesses what a corner would look like based on the adjacent edge sprites. This is specifically for two adjacent edges that use identical sprites, because I understand it's not physically possible to be able to accurately merge 2 completely different edge sprites together and have it look good. Ferr2D has it working though for adjacent edges set to the same texture, and it manages to generate a great corner that is much more functional and dynamic than manually set SpriteShape corners.
4. An option to have the ability to snap points of the shape to the x or y coordinate of the nearest point on the shape itself, rather than the Unity Grid. This for my project is crucial due to the need for pixel perfect collider angles in very obscure shapes that can't possibly match the grids.
5. The ability to select and move multiple points at once.

SpriteShape has much better mesh triangulator than Ferr2D and takes up so much less space. A single Ferr2D scene object can increase scene size by over 200KB depending on its shape/complexity/PPU, which is absolutely ridiculous. Whereas a single SpriteShape object only takes 3-8KB regardless of how complex it is, which is awesome. And it can use sprites rather than texture + material, which is very convenient. Also the ability to easily make the shape path points scriptable is a huge advantage.
Until the above changes happen, I'm still going to use it for non-terrain foreground/close-middleground and for decorations over Ferr2D, since they don't require a collider, because the tool now is still incredibly useful.

 

Thanks for the response, I had a feeling you could move multiple points at once since you could select multiple at once, but couldn't figure out how to do it.

Regarding the Pixels Per unit for edges, by relying on the PPU setting from the textureimporter it means you can't change the PPU per spriteshape instance like you can with the fill unless I'm missing something.

So if you have 2 spriteshapes with the same fill texture, you can set one to 100 PPU and the other to 200 PPU, but you can't do the same for edges. You'd need to duplicate the edge sprite with 100 PPU, set the PPU of the duplicated sprite to 200, and then assign it to the new spriteshape. Which isn't very convenient. And I'd imagine easily modifying PPU per SpriteShape instance on the fly would be very useful in 2D especially for parallaxing foregrounds where the texture becomes slightly smaller the 'further' away it is or bigger the closer it is.

I really have no idea what I'm talking about, but is it possible to make the sprite containing the edges/corners a Texture2D on the spriteshape just like the fill, and then use the textureRects of each sprite defined in the sprite editor to grab the right edges/corners? This way you can set the PPU for the Texture2D of the edges per spriteshape instance rather than the textureImporter, just like the fill? I don't know enough about it to know if what I just said was nonsense or not.

If it's not possible I completely understand, it's just inconvenient to not be able to change the PPU of the edges per spriteshape instance, since often times the edge sprites are created to match the default PPU of the fill, and changing the PPU of the fill on the spriteshape instance will cause the edge sprites to no longer match it.

 

@Venkify
I'm falling through the floor

My character is using a RigidBody2d and CircleCollider2D to detect the ground. You can see the character "kind of detect\ clip" the Sprite Shader edge collider before he plummets to his death.

Would making the Edge Collider2D "thicker" give the colliders more space to detect the edges? I'm just speculating here.

01:18 is when you see the rigidbody fall through the floor.

Any idea why this is happening?
Thanks!

 

Is there a reason why for each spriteshape visible to camera, SpriteShapeController.NeedUpdateSpriteArrays() gets called every frame? Because it's calling CornerSprite.Equals() and generates 320 bytes of garbage every frame per spriteshape object.
Unity 2018.2.15

 

Sorry so does that mean it's normal for static spriteshapes generate 320 bytes of garbage every frame or is it something I'm doing wrong? If it helps, after a little more testing I found that an empty spriteshape profile with no fill texture assigned yet (which means the 8 object fields under Corners in the inspector haven't even appeared yet), no garbage is being created. But once I assign a fill, the 8 object fields under Corners appear and the 320 bytes of garbage start appearing, even if I then remove the fill texture I just added. So it must have something to do with the corners check when it checks if anything in the spriteshape has changed every frame. I thought maybe it was because none were assigned (similar to how a failed GetComponent generates garbage in the editor but not build), but I tried both assigning the corners and tested in build and it was still creating garbage.

If there's a way to make the corners fields disappear like they are in a completely new empty spriteshape profile, that would work too. Or a possibility to be able to set a flag on a spriteshapecontroller telling it that it is static so it will opt out of haschanged checks?

Is it possible to view any part of the source code for the spriteshapecontroller or the spriteshape itself or at least the editor scripts for them?

 

First of all, I love this new feature.
But I'm afraid I'm having a problem accessing the scripting part of it.


It tells me that the SpriteShapeController class doesn't exist, even when I say "using UnityEngine.U2D".
Did I import it wrong or use the wrong version of SpriteShape?

I'm using Unity 2018.2.17f1 and Sprite Shape 1.0.12



EDIT: I copied the install folder for SpriteShape in the AppData folder into my project's install folder for SpriteShape and it worked.

 

[ edit nov 27 ]
The solution is not good. Other game objects with smaller colliders still fall through the sprite shape collider. May I ask how I can send a project repo directly to your team? Thanks.


Poor workaround....

@Venkify Ok I found out the problem this weekend. It had to do with the physics overlap radius size. If I was using something lower than 0.5, the edge collider or the sprite shape wasn't able to 100% of the time detect the circle collider 2d on my hero character.

Code (CSharp):

1.  
2. //Smaller radius values with a smaller circle collider 2D shape has inconsistent sprite shape collision detection rate
3. checkGrounded = Physics2D.OverlapCircle(gameObject.transform.position, 0.5f, whatIsTheGround);
4.  

Code (CSharp):

1.  
2. //Larger radius size with increased circle collider 2D shape, so far, has a 100% sprite shape collision detection rate
3. checkGrounded = Physics2D.OverlapCircle(gameObject.transform.position, 1, whatIsTheGround);
4.  

There is the inconvenience of the Circle Collider 2D being larger with potential collision issues of other kinds, but for now it works for me.

I'll keep you posted as I further play around with Sprite Shape. So far I'm loving the potential, keep up the great work.

 

Bug: Shape without Profile with FillTexture is not rendered in build

 

About not being able to access the classes, it turns out the Sprite Shape package install for my project was completely empty, and Unity was using the package files from the AppData folder, which Visual Studio didn't know about.

I copied the files from AppData into my project's package folder and it worked.

 

Here's my feedback from using SpriteShape:

1. alt+LMB should move camera, not box select (just LMB for box select is good tho)
2. ctrl+LMB or someother quick way to delete a vertex without having to select then press DEL
3. Copy+Past Vertices between sprite shapes, or even the same shape but on different parts of it
4. Someway of programmatically getting and setting all the points at once like you can with PolygonCollider.GetPath(0)
5. SpriteShapeRenderer.color = Color.blue; I need someway to programmatically set the color property that shows up in the editor

 

@Venkify I uploaded a bug report via Unity, did you guys get it? I submitted a scene with 7-9 rocks that had rigid bodies attached to them. You can see that maybe 40% of them fall through the edge collider.

Pls let me know if you need anything else. Would love to hear progress updates.

 

Is there a way to change the color of the Sprite Shape Renderer? As shieldgenerator7 already pointed out, we need a way to set the color property.

 

About setting the color of the renderer, it would be even better if we could set a color property for each control points of the spline in the same way that we are allowed to set a sprite for a specific index (with something in the API for it). Something like multiplying the color of the renderer with the color of the control point for the actual shown color would be perfect.

On another note, for the generated colliders, there seem to be an unnecessary amount of points generated even on low quality. It generates multiple points on a straight line if there are multiple control points on that line and there's always a pair of points that are super close to each other at control points

 

Also, It would be awesome to have the option to choose a separate color for fill texture.

 

@Venkify

1104919 <- it should be this one? The title is [ SpriteShape Preview Package ]

Please let me know if you found it or not. I'm not sure if that's the ID.

Thanks!

 

Great! Hope you guys can figure out what I'm doing wrong. I'd love to use sprite shapes!

 

I'm pretty sure the devs are no longer working on this https://polycount.com/discussion/154447/2d-terrain-platform-toolkit-for-unity-5, but they have some pretty rad stuff. Their shape editor and edge mesh manipulation look pretty sweet. Just wanted to post it in case it inspires any ideas for spriteshape.

 

I'm running the latest preview and my handles aren't showing. Am I the only one getting this?

Running 2018.3f1.

 

Not sure what changes 2018.3 made that affected SpriteShape, but here's an issue that occurred:

In my fragment shader I have a color array. If I have an object at transform z = 0, the shader will blend with ColorArray[0]. If the object is at z = 1, it will blend it with ColorArray[1], etc.
Example calculation:
blendResult = lerp(texcolor, _BlendColorArray[z], _BlendAmountArray[z]);

This worked great in 2018.2, but now it seems in 2018.3 the edges of spriteshape are positioned slightly in front of the fill in the Z direction. So a Z of 1 will blend the fill with the array[1] color, but the edges still use the array[0] color. So for this object, if Z=0 blends with black and Z=1 blends with nothing, and it's positioned at Z=1, this is the result in 2018.3.


Whereas in 2018.2, both the edge and the fill seemed to share the same Z because they both picked the proper color. If I set the Z to 1.01, it picked the appropriate color, so it must be a Z-related issue based on the edges needing to render over the fill. I'm just not sure why it exists in 2018.3 and didn't in 2018.2 despite the SpriteShape package being the same.


I can theoretically work around it by just adding .01f in the shader to the z value before it's used to access the array, but I'd rather know the exact cause behind it.

I'm retrieving the Z through:
vert function:
OUT.world = mul(unity_ObjectToWorld, IN.vertex).xyz;

frag function
z = IN.world.z;