[Release][Free] Unity Sprites And Bones - 2D skeleton animation

Yes TheValar! That is exactly what I need! If you have some code I can borrow, I'd love to add it to that script to handle it!

 

OK! Added some cool new features in the interim!



You can edit the color of bones, and bones marked with endings of either L, Left, R, or Right will have distinguishable colors automatically. You can always rename the game objects to something other than that or change the default of those colors in the Bone script.




True FFD using deform points! I have it simply create Control Points for the mesh in the Skin2D component by pressing "Create Control Points" and it will automagically create control points for the mesh that you can move the transforms and it will change the positions of the skin's mesh. You can also hit "Reset Control Points" to reset the control points for the skin. You can also change the size and color of the points in the Control Point component in the inspector. It will also have distinguishable colors if you label the game objects name with L, Left, R, or Right endings.

Not sure if I did this exactly the right way but I currently have the file in my unstable fork here:

https://github.com/playemgames/Unit...ssets/SpritesAndBones/Scripts/ControlPoint.cs

TheValar if you have that code to help me figure out the UV's I'll include that next so people can have a poor man's polygon editor to make meshes for the skin! Hope this helps some of you!

 

Ok I just got the chance to open up my old destruction project and get re-acquainted with my code. I believe that this method should do the trick.

Code (CSharp):

1. public Vector2[] genUV (Vector3[] vertices, SpriteRenderer sRend, Transform sTransform)
2.     {
3.         float texHeight = (sRend.bounds.extents.y * 2) / sTransform.localScale.y;
4.         float texWidth = (sRend.bounds.extents.x * 2) / sTransform.localScale.x;
5.         Vector3 botLeft = sTransform.InverseTransformPoint (new Vector3 (sRend.bounds.center.x - sRend.bounds.extents.x, sRend.bounds.center.y - sRend.bounds.extents.y, 0));
6.         Vector2[] uv = new Vector2[vertices.Length];
7.         for (int i = 0; i<vertices.Length; i++) {
8.            
9.             float x = (vertices [i].x - botLeft.x) / texWidth;
10.             float y = (vertices [i].y - botLeft.y) / texHeight;
11.             uv [i] = new Vector2 (x, y);
12.         }
13.         return uv;
14.     }

This takes a spriteRenderer, transform, and corresponding vertices that you generated from the collider. The reason the variables have s in front of them is for source as in "sourceTransform" which is not applicable to this context and should be modified.

Let me know if that works.

p.s. your additions are looking sweet. Simplifying skin2d creation is a huge plus

 

Thanks for the code TheValar! Unfortunately, it still came out wrong when I tried to apply the generated mesh to a Skin2D component Maybe it needs to use textureRect or textureRectOffset instead: http://docs.unity3d.com/ScriptReference/Sprite.html

I think we need to figure out the polygon collider's position against the sprite bounds and then that is used against the current UV for the rectangle of the sprite on the sprite texture. Just can't seem to figure out the math on how to handle it that way.

Here's the code I am using, I just call the function on the game object with the sprite renderer and polygon collider:

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.Sprites;
3. using System.Collections;
4. using System.Collections.Generic;
5. using System.Linq;
6.  
7. public class PolygonMesh {
8.  
9.     public PolygonCollider2D polygonCollider;
10.  
11.     public void CreatePolygonMesh()
12.     {
13.         if (polygonCollider != null)
14.         {
15.             Vector2[] vertices2D = polygonCollider.points;
16.  
17.             // Use the triangulator to get indices for creating triangles
18.             int[] indices = Triangulator.Triangulate(vertices2D);
19.  
20.             // Create the Vector3 vertices
21.             Vector3[] vertices = new Vector3[vertices2D.Length];
22.             for (int i=0; i<vertices.Length; i++) {
23.                 vertices[i] = new Vector3(vertices2D[i].x, vertices2D[i].y, 0);
24.             }
25.  
26.             // Create the mesh
27.             Mesh mesh = new Mesh();
28.             mesh.vertices = vertices;
29.             mesh.triangles = indices;
30.  
31.             SpriteRenderer spriteRenderer = polygonCollider.GetComponent<SpriteRenderer>();
32.  
33.             if (spriteRenderer != null)
34.             {
35.                 mesh.uv = genUV(mesh.vertices, spriteRenderer, polygonCollider.transform);
36.                 mesh.RecalculateNormals();
37.                 mesh.RecalculateBounds();
38.             }
39.  
40.             else
41.             {
42.                 Vector2[] uvs = new Vector2[vertices.Length];
43.                 Bounds bounds = polygonCollider.bounds;
44.                 int n = 0;
45.                 while (n < uvs.Length) {
46.                     uvs[n] = new Vector2(vertices[n].x / bounds.size.x, vertices[n].y / bounds.size.x);
47.                     n++;
48.                 }
49.                 mesh.uv = uvs;
50.                 mesh.RecalculateNormals();
51.                 mesh.RecalculateBounds();
52.             }
53.  
54.             ScriptableObjectUtility.CreateAsset(mesh);
55.         }
56.     }
57.  
58.     public Vector2[] genUV (Vector3[] vertices, SpriteRenderer sRend, Transform sTransform)
59.     {
60.         float texHeight = (sRend.bounds.extents.y * 2) / sTransform.localScale.y;
61.         float texWidth = (sRend.bounds.extents.x * 2) / sTransform.localScale.x;
62.         Vector3 botLeft = sTransform.InverseTransformPoint (new Vector3 (sRend.bounds.center.x - sRend.bounds.extents.x, sRend.bounds.center.y - sRend.bounds.extents.y, 0));
63.         Vector2[] uv = new Vector2[vertices.Length];
64.         for (int i = 0; i<vertices.Length; i++) {
65.      
66.             float x = (vertices [i].x - botLeft.x) / texWidth;
67.             float y = (vertices [i].y - botLeft.y) / texHeight;
68.             uv [i] = new Vector2 (x, y);
69.         }
70.         return uv;
71.     }
72.  
73. }

 

Regarding the control points, I'd suggest to use a single component, that manages all control points. Using a gameobject for every vertex is a waste of resources. Also I'd expect this to cause a slowdown with complex meshes or less powerful devices.

 

Not sure on how I'd approach that since the user would need to move the transforms in order to move the vertices. You can delete the unnecessary ones if needed if someone doesn't need that fine of control. Do you mean put a single script on the Skin2D object that handles the updates for the other objects?

Still stuck on this UV problem, I can't seem to wrap my head around it.

 

If I'd knew an easy answer to this, I'd have written it myself .
Sorry, that I can't be of help right now. I have a vacation lined up in a few weeks. Maybe I can do some work on Sprites And Bones then.

 

understandable! I'll be on vacation in a few weeks myself, but I'll be away from the desk at that time!

 

Ok I have a feeling I am really close with this one but still my math is off somewhere:

Code (CSharp):

1.     public Vector2[] genUV (Vector3[] vertices)
2.     {
3.         if (spriteRenderer != null && polygonCollider != null)
4.         {
5.             // Get lower left offset of polygon collider
6.             Vector3 polygonBounds = polygonCollider.transform.InverseTransformPoint(polygonCollider.bounds.min);
7.             Vector3 spriteBounds = polygonCollider.transform.InverseTransformPoint(spriteRenderer.bounds.min);
8.             Vector3 lowerLeftOffset = new Vector3((spriteBounds.x - polygonBounds.x)*pixelsToUnit, (spriteBounds.y - polygonBounds.y)*pixelsToUnit, 0);
9.             Debug.Log(lowerLeftOffset.x);
10.             Debug.Log(lowerLeftOffset.y);
11.  
12.             float texHeight = (sprite.texture.height);
13.             Debug.Log(texHeight);
14.             float texWidth = (sprite.texture.width);
15.             Debug.Log(texWidth);
16.  
17.             Vector3 botLeft = polygonCollider.transform.InverseTransformPoint(new Vector3 (spriteRenderer.bounds.min.x, spriteRenderer.bounds.min.y, 0));
18.             Debug.Log(botLeft.x);
19.             Debug.Log(botLeft.y);
20.  
21.             Debug.Log(spriteRenderer.sprite.rect.x);
22.             Debug.Log(spriteRenderer.sprite.rect.y);
23.  
24.             float spriteTextureOriginX =  spriteRenderer.sprite.rect.x;
25.             float spriteTextureOriginY =  spriteRenderer.sprite.rect.y;
26.  
27.             Debug.Log(spriteTextureOriginX);
28.             Debug.Log(spriteTextureOriginY);
29.  
30.             Vector2 spriteTexturePixelOrigin = new Vector2(spriteTextureOriginX + lowerLeftOffset.x, spriteTextureOriginY + lowerLeftOffset.y);
31.             Debug.Log(spriteTexturePixelOrigin.x);
32.             Debug.Log(spriteTexturePixelOrigin.y);
33.  
34.             Vector2[] uv = new Vector2[vertices.Length];
35.             for (int i = 0; i<vertices.Length; i++) {
36.                
37.                 float x = (vertices [i].x - botLeft.x) * pixelsToUnit;
38.                 float y = (vertices [i].y - botLeft.y) * pixelsToUnit;
39.                 // Debug.Log(x);
40.                 // Debug.Log(y);
41.                 uv [i] = new Vector2 (((x + spriteTexturePixelOrigin.x) / texWidth), ((y + spriteTexturePixelOrigin.y) / texHeight));
42.             }
43.             return uv;
44.         }
45.         else
46.         {
47.             return null;
48.         }
49.     }

I am basically trying to take the sprite's rect on the texture as a starting point, and then creating the uv's from there. I have to convert the space to pixels first before I can divide it against the texture though. If anyone has any better ideas or spots the flaws in my logic I am fair game for it.

 

Ok so I took some time to mess around with the code I posted. It actually does work, it just doesn't currently work with sprite sheets like the orc example. If you use the Spock sprite it works as expected. I think it could be made to work with sprite sheets too if the method of getting the texture size is modified. I made a unity package with an example scene as a proof of concept. Just run the scene and the sprite renderer will be replaced with a mesh renderer according to the polygon collider

https://www.dropbox.com/s/aabap8so51d10zx/MeshGeneratorPackage.unitypackage

 

Hey TheValar, yeah that is what I am trying to fix, it works fine if it is a single texture but not atlased sprites. That is why I have been trying the code above, I'm trying to get the offset between the collider and the sprite renderer bounds, and then use that as a starting point from the sprite's rect origin on the texture. Something with my math is off though, can't figure it out.

 

I'll keep working at it from my end and hopefully one of us will strike gold How exactly do you get the dimensions of the current sprite within the context of the sprite sheet?

 

I got it using the sprite.rect:

Code (CSharp):

1. float spriteTextureOriginX =  spriteRenderer.sprite.rect.x;
2. float spriteTextureOriginY =  spriteRenderer.sprite.rect.y;

I'm not sure if this is exactly right though but it is supposed to return the rect of the sprite on the texture.

 

OK I think I have partially solved it, I knew there was something off, it was because the parent object is rotated slightly! Now I have to figure in the parent rotation to the vertices before they are applied to the UV. When I had rotated the parent object back to Vector3.zero before creating the mesh it came out as it should!

 

Got it! Finally! It's those little things that go unnoticed sometimes! I'll have to write up some documentation on this all later but here is the new script:

https://github.com/playemgames/Unit.../SpritesAndBones/Scripts/Utils/PolygonMesh.cs



Now everything is as it should be! I also moved all the Menu items to it's own tab under "Sprites".



That way everything is all in one place and you don't have to hunt around for things. Next up, I will try to fix the Skin2D creation to have it automatically weight paint to the parent bone if it has one. Then I will see if I can make a bool variable under Skeleton that can flip the rig (without using scale) and flip the normals as well for the lighting for all the meshes.

If anyone has a better idea for the deform control points and how to implement it I am fair game to that as well, right now I have it using gameobjects for manipulating the mesh vertices, but if there is another way to track them using the animation tool in Unity that uses less resources I'll implement that as well.

 

Awesome! I'm glad you figured it out because messing around with procedural meshes and such always makes my brain hurt

I'm not sure if naming the drop-down menu "Sprites" is the best idea since it's kind of general. Obviously Sprites and Bones is a bit long for a menu title though. Maybe "S-and-B", "US&B", "Sprites & Bones"?

 

Thanks for all your help! I think "Sprites & Bones" might be best, I'll change it to that. In the interim I have finally got the Skin2D to skin automatically to the parent bone, and made the Control Points multi-editable so you can change the color and the size all together if you need. I'll work on the flipping next.

 

Good work everyone .

And the ampersand is not a good idea. Usually this is a reserved character, that in a menu creates an underscore under the next character.
How about "SpritesAndBones" in one word. It's the same length.

 

I just did "Sprites and Bones" instead

 

I guess, that works, too. But the 'A' needs to be capitalized. It's part of the name.

 

btw Banbury, I just realized that Blog is misspelled in your sig

 

You're perfectly right. Let me correct that. Better?

 

Woohoo! Got a new shader written up to accept flipping normals and adding lighting and shadows to the sprites on the rig!


Basically you can use the "flip" bool on the skeleton to flip the rig 180 degrees. I included a special shader that you can manually change the normals if needed. I have the Skeleton class flip the normals when you call the bool. You can also use the Flip button to flip the rig on the fly.

In addition I added a "useShadows" bool variable that you can call to use lighting and shadows on the rig when you want to. This will change the shaders on the fly for all SkinnedMeshRenderers and SpriteRenderers in the rig. You can use the "Use Shadows" button to add or take away the lighting and shadows on the rig on the fly in the editor.

Banbury I also made your minor change to the menu name and did "Sprites And Bones"

You can see my changes in my fork here:

https://github.com/playemgames/UnitySpritesAndBones/tree/unstable

Let me know what you think! I am going to take a little break from this now for a bit, and going on vacation next week. If you find anything wrong please let me know right away. I will most likely work on ragdolls and collision next, maybe a script to auto-set it up. I am unsure of how to bake animations and the like so if there are any ideas on that front I am all ears as well.

 

I think you have done a fantastic job. So many new features in such a short time!
When I find the time, I will merge your work. There are some new usability features in Unity 4.6, that I want to make use of, too.

And I tried baking the animation myself, but I couldn't find a way to access the animated values, while the animation is playing. A possible way is to query the animation window by reflection. You can find my experiments with that in the AnimationWindowUtils class. But I didn't get far with it. I wish the Unity devs hadn't made all the editor classes internal.

 

Thanks Banbury! Yeah I am looking forward to 4.6 myself, I really needed these features in the animation tool so I can start working on the redo for animations for my game. So after I am back from vacation I'll look into all of it a bit more. Yeah it's a shame they haven't opened up the animation classes at least, I'm pretty sure they could easily add onion-skinning with it. One can only hope that we can get more from Unity soon!

 

Looking forward to playing with these new features. Once they get merged you should consider doing a revised tutorial on using Skin2D. I'll probably download your unstable fork this weekend and test it out.

 

Yeah actually it is insanely easy for Skin2D, just select the SpriteRenderer gameobject you want to skin, go to "Sprites And Bones>Skin2D" in the menu and it automagically skins it for you and creates a mesh! If you want to change the current mesh, drag and drop the mesh and hit the "Recalculate Weights" button, then you have to repaint your weights for the new mesh.

Once I am done with vacation, I'll see if I can make some new tutorials for it.

 

Have a few new changes, I fixed some bugs I found with rotation handling when adding Sprite or Polygon meshes and Control Points, also ketura on Github added more custom setups for Helper objects.



https://github.com/playemgames/UnitySpritesAndBones/tree/unstable

 

@ketura That's a nice one. Maybe it would be worth to spin off the helper object into its own addon.

 

I also found out today that when you scale a texture in the inspector, the Pixels to Units value is scaled as well. So I pre-calculated the Pixels to Units value using the sprite's rect width and the sprite's bounds width. Hopefully this will solve any scaling issue's with the mesh UV creation using a polygon collider.

 

Another more hacky way you can handle scale and rotation is by storing the values, rotating/scaling the object to default, then calculate uvs and reset the position and rotation back to what it was.

 

I wouldn't call this 'hacky'. It's an acceptable way to deal with complicated geometric transformations.

 

Actually that is exactly what I did for the mesh setups, but for the texture stuff it is impossible I just had to pre-calculate it using the sprite.rect and bounds size.

 

Looking back on the thread I see you actually mentioned that earlier.

btw nice work on getting all the uv and mesh stuff working. That stuff can get complicated and it's awesome to have it included in this open source package

 

@playemgames Could you make a pull request with your changes? No hurry, though.

 

@playemgames Never mind the pull request, I merged it manually. But whatever you did with the tutorial files, destroyed them for me. All textures and meshes are missing. Please be more careful, when moving stuff around.

 

I've just uploaded version 1.2 of Sprites And Bones. This release wouldn't have been possible without the contributions by @playemgames, @Denvil and @ketura. Thanks guys!

 

Thanks! Hope it helps more people out! I'll do some more tweaking that I'll post when I am back next week!

 

I had just got them from Denvil's branch, I was going to re-upload them the way they were before, but hadn't gotten a chance yet. I'm back for a couple of days, then will be out till next week. Good work on the release, I'll have to check it out, I was thinking of having the Left/Right colors editable per skeleton and just adding a couple of fields that way. I don't think anyone will want to mess with them if they have to edit it in code or search for it in Edit/Preferences.

Any other ideas for the control points? This was the easiest way I could think of to put them in.

 

Not really. I didn't have the time to think about that. But I think there's no easy solution. Maybe there's a way to cache the animated vertices for production.

 

Yeah I think the way we have it now is probably the most reasonable solution. I'll see if they can be added to the poses as well. I haven't had a chance to look at how poses are stored yet.

 

I wouldn't call it reasonable . But it's the easiest way to accomplish it. Gamemakers will have to decide, if it's usable.
The poses are just arrays of bones rotations. If you want to add the mesh deformations to poses, I'd suggest using a separate class that inherits from the Pose class.

 

Sounds good, I'll see if I can add that in sometime next week.

 

So I have been playing with Sprites and Bones the whole day yesterday but something is not clear to me, maybe someone could help?

In case I have a character mesh with body parts what wold be the advantage of using this over mecanim? And can I use deformation in this case? Thanks!

 

Sprites And Bones isn't meant to replace Mecanim, but to enhance it. Of course it's possible to animate the sprites without bones, but bones make it easier. Especially if one uses Inverse Kinematics. There are other advantages to using bones, like reusing of poses and animations on multiple characters. And yes, mesh deformation can be used in conjunction with Mecanim.

And thanks for trying Sprites And Bones.

 

OK I'm back! I haven't merged all your code changes into my unstable branch but I put the ones I thought improved it like auto-adding a polygon collider for creating a mesh from a PolygonCollider2D and hiding the bools for flip and useShadows. I didn't really like the idea of going all the way into Edit>Preferences to just edit the colors for the left and right of the Skeleton so I added them to the Skeleton class and have Bone and ControlPoint referencing those instead:



I also added ControlPoint positions to the Pose class so you can save deform point positions for SkinnedMeshRenderers:



The scripts assume that the Control Points have a parent object and the references track the parent object name + the control point's name. So if you rename the parent or the control point, it will not be able to restore it.

I'm also looking into adapting the polygon drawing methods from this open source project for mesh creation:
http://www.reddit.com/r/gamedev/comments/2bwinb/prettypoly_open_source_polygonal_level_editing/

https://bitbucket.org/q_bert_reynolds/platformerdemo

Maybe the author can give me some tips on how to implement it into Sprites And Bones. Hope this helps some more people out!

https://github.com/playemgames/UnitySpritesAndBones/tree/unstable

 

My reasoning for the Preferences is, that I don't want to setup the colors everytime I create a new skeleton.
If you want to create a version different from mine, I'd suggest doing it in a separate branch. Otherwise it becomes quite difficult for me to integrate your changes. Since you've made your changes already in your unstable branch, you could create a new branch (let's call it 'upstream'). Then you could merge all changes from your unstable branch, you want to have included in Sprites And Bones, into the new branch.
For this it's also important to make changes for different features in separate commits.

 

This weekend I was working on Porting my game over to WP8 and I uncovered a very small bug. Something in the SkinMaker.cs script causes an error when you try to build for the WP8 platform. Something in the GenerateMesh() method is not supported for whatever reason. Since Mesh generation isn't required at runtime and the error only occurs when creating a build it can probably be fixed with a UNITY_EDITOR platform selector. I'll look into it later today but just wanted to give a heads up.

 

Did you get an error message?

 

Yes I did but I don't remember the specific message off the top of my head (I'm currently away from my home/Unity machine).

That being said I'm about 99% sure that

Code (CSharp):

1.  int[] faces = Triangulator.Triangulate(System.Array.ConvertAll(controlPoints, x => (Vector2)x));

was the culprit.

I think that perhaps System.Array.ConvertAll is not available in WP8

EDIT:
Ok did a tad more research and that's definitely the problem. This is from the MS docs

They then give an example of convertall functionality using LINQ...

Code (CSharp):

1. List<string> strings = numbers.Select(n => n.ToString()).ToList();