From 2019.3 onwards the 2D Sprite Shape package is out of preview and verified. This means that the 2D Sprite Shape package is stable and will receive regular bug fixes. We will continue to add new functionality and this will be clearly marked as experimental to distinguish it from the more stable features.
Overview
Sprite Shape is a layout and world-building tool that provides the ability to tile sprites along the path of a shape based on given angle ranges. Additionally the shape can be filled with a tiling texture.
The main feature of Sprite Shape is the powerful combination of a bezier spline path with the ability to tile Sprites adaptively or continuously while automatically switching Sprites assigned to given angles.
Getting Started
Install latest Unity 2019.3
Open Package Manager by going to Window > Package Manager
Choose 2D Sprite Shape from the list and click on Install at the bottom right of the Package Manager window.
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.
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:
liil5
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.
n3jxk
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
[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ā¦
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.
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.
@pastaluego We would like to assure that we will keep improving SpriteShape and appreciate every feedback and suggestion that has been posted. We have been and will be continuously addressing bugs and have addressed most of the forum feedback.
However certain things such as Horizontal split, a great suggestion but may not work for all cases and we want to ensure that solutions for certain features work for most of the general use-cases and do not affect existing use. Also regarding corner sprite, we will continue to improve it. https://discussions.unity.com/t/695382 page-9#post-5139287
Recent versions also improved corner tessellation and provided flexibility.
With upcoming version, we have improved memory allocations for SpriteShape generation. Also SpriteShape is out of preview as @rustum mentioned above
Thanks for the bug report and feedback. We will address this bug in an upcoming release. You may also want to consider GeometryCollider from SpriteShape Extras which fits the generate SpriteShape more accurately.
Corners are currently designed so they naturally fit the two neighbor edges and therefore requires Linear mode neighbors and pivot, height settings be same.
However while we make it more flexible, there are also workarounds to achieve the corner sprite when you have neighbor edges with different pivot and heights : 1) Sprite Borders of the Edge Sprites 2) Sprite Variants.
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!
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?
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.
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.
using UnityEngine;
using UnityEditor;
public class EditSnap : EditorWindow {
public static float snapX {
get { return EditorPrefs.GetFloat("MoveSnapX"); }
set { EditorPrefs.SetFloat("MoveSnapX", value); }
}
public static float snapY {
get { return EditorPrefs.GetFloat("MoveSnapY"); }
set { EditorPrefs.SetFloat("MoveSnapY", value); }
}
public static float snapZ {
get { return EditorPrefs.GetFloat("MoveSnapZ"); }
set { EditorPrefs.SetFloat("MoveSnapZ", value); }
}
[MenuItem("Tools/Set Snap", false, 120)]
static void Init() {
EditorWindow.GetWindow(typeof(EditSnap));
}
void OnGUI() {
GUILayout.Label("Old Snap Settings?", EditorStyles.boldLabel);
snapX = EditorGUILayout.FloatField("Snap X", snapX);
snapY = EditorGUILayout.FloatField("Snap Y", snapY);
snapZ = EditorGUILayout.FloatField("Snap Z", snapZ);
}
}
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.
Thanks for the feedback. SpriteShape only uses rect data of sprites to generate render geometry and collider points. Therefore using outlines of the sprite for collider is not possible. Also doing so, will increase geometry and physics2d runtime cost quite considerably.
For accurate results, we would suggest using Geometry Collider found in the extras of the Package.
I believe this issue is unrelated to SpriteShape and a fix for a related bug is available in recent releases. Thanks for posting.
Basically HasSplineChanged tests for change in the spline data and if regenerating the Spriteshape is required. This can potentially be optimized on runtime for static spriteshape objects (i.e objects that never get modified on the runtime).
