- Змінено
A few basic questions about the Unity runtime
Hi, I'm considering purchasing Spine for use with Unity. I see that Unity and 2d toolkit runtimes are available. I also use 2dtoolkit, so should I use the 2dtk runtime as well? I'm not really sure what the advantage is, unless it's just for consistency so all of my sprites will be displayed via 2dtk. My concern is that a 2dtk runtime would be more unstable, because I now have aspects of my game controlled by code belonging to two third party entities (esoteric and unikron), instead of just one.
Last I checked, importing into unity was a bit of a hassle (https://www.youtube.com/watch?v=x1umSQulghA). I've heard that it is much easier now- is there an updated video or documentation on this process?
Lastly, are there any known issues with retroactively adding bones/pieces to an animation? Part of the reason I'm here is because Smooth Moves (a puppet utility for unity) bugged out on me. I had two completed animations, then I decided to add a new bone to represent the character's weapon. After rebuilding the animations bugged out and no longer play properly in-game.
Thanks!
Hi. I used smoothmoves. Then I used spine - never looked back. Then I wrote the drag and drop importer for Spine that is now in the Spine Unity runtime and a bunch of other goodies. Drag and Drop TK2D support is... troublesome, but I'll be working on bringing Spine TK2D runtimes into line withe Spine Unity runtimes pretty soon. I'm not sure the import is going to be quite as clean because of that crazy TK2D atlas generator thing... but yea, its coming.
As for bones and retroactiveness, I can't directly speak for the TK2D runtimes, but even with the TK2D runtime all of the skeletal stuff is handled by the Spine part of that so I can't image there'd be any problems. If it looks right in the Spine editor it'll look right in Unity.
https://www.youtube.com/watch?v=-Gk_zJsY1Ms
This is the native Spine Unity import process.
Check these threads for some of the newer cooler stuff (Currently only in Spine Unity runtime, not Spine TK2D)
viewtopic.php?f=3&t=3318
viewtopic.php?f=7&t=3004
Also please feel free to PM me or hit me up on Skype if you have any other Unity workflow questions/comments/want a quick demo (Skype: Fenrisul )
Thanks!
Drag and drop is preferred, so is there any reason you know of to stick with the 2dtk runtime for now?
In terms of the retroactive addition of parts, I guess that is a question for spine itself- any evidence of the spine program improperly handling such a thing?
Do you recommend to keep my spine work in a totally separate folder, then only import the necessary parts into unity?
Lastly, any issues with lighting of pieces? When using smooth moves I could only use a vertex-lit shader, anything else caused the pieces of a character to render on top of each other with odd alpha transparency.
Afro-Ninja написавThanks!
Drag and drop is preferred, so is there any reason you know of to stick with the 2dtk runtime for now?
In terms of the retroactive addition of parts, I guess that is a question for spine itself- any evidence of the spine program improperly handling such a thing?
Do you recommend to keep my spine work in a totally separate folder, then only import the necessary parts into unity?
Lastly, any issues with lighting of pieces? When using smooth moves I could only use a vertex-lit shader, anything else caused the pieces of a character to render on top of each other with odd alpha transparency.
Spine comes with a couple good shaders, but honestly same as smoothmoves - the shaders are ultimately up to you as the output is just a mesh. There are some tech demos and examples of Spine assets being normal mapped and lit in all sorts of fancy ways (including good old Unity shadow casting).
If you are using Spine TK2D the "Parts" of your sprite are all imported into your project where as if you use the native Spine Unity workflow only the Atlas is imported. Using the Spine Unity runtime, I generally store my Spine project files and the components of that project outside of the Unity folder structure all together. Spine has an Export function that remembers (per project) where to put files so its pretty much a non-issue.
I don't see a reason to use TK2D unless you really want to. I believe you get better control over per-sprite draw order, but beyond that meh; personal preference. The non-TK2D runtimes are more up to date at the moment though (mostly to do with auto-import and my SkeletonUtility stuff)
Mitch написавSpine comes with a couple good shaders, but honestly same as smoothmoves - the shaders are ultimately up to you as the output is just a mesh. There are some tech demos and examples of Spine assets being normal mapped and lit in all sorts of fancy ways (including good old Unity shadow casting).
Gotcha. I'll assume that it hasn't been a huge issue then. With Smooth moves I could only get one of the lit shaders to work without bugging out the alpha transparency. The SM author didn't have much to help me with. It felt like a pretty glaring issue to me (what 2d game these days doesn't require/want some kind of lighting?) so if there are tech demos of normal mapped/lit spine assets I'll hope it's not a problem. Thanks again!
EDIT: I have to say this thread has me a bit nervous (viewtopic.php?f=11&t=760&hilit=lighting&start=50) but it looks like it can be fixed with some work-arounds.
By the way... Is it normal to request work for hire around here? or with spine in general?
I would like to use spine to layout the basis for my character but I may need someone better with animation to step in at some point to do some heavy lifting.
EDIT: I have to say this thread has me a bit nervous (viewtopic.php?f=11&t=760&hilit=lighting&start=50) but it looks like it can be fixed with some work-arounds
If you have the problem in TK2D, you'll have it in Spine, SmoothMoves, and all the others. They all just generate meshes. The rest is up to your shaders. Spine itself is agnostic.
By the way... Is it normal to request work for hire around here? or with spine in general?
There's a whole section on the forums for it 
Spine will let you add bones, add/remove/move vertices, change weights, etc, even after animating. You can even manipulate everything programmatically.
- Змінено
We came from SmoothMoves too. Never looked back. Spine is way better on many fronts.
And yeah, adding stuff like bones or new images or anything after you're done animating is not a problem at all. We do it all the time and it hasn't caused problems.
The runtimes are open source so if ever you do find bugs, or have some specific needs or ideas to extend it, you can read and modify the code.
But out of the box, unless you're doing some crazy things, chances are it already does all the things you need. And if it doesn't, these forums are always here too.
Just a note though, if you were animating flipping via scaling with SmoothMoves, you may have a bit of trouble doing the same in Spine. Animating flipping (horizontally or vertically) is also currently not possible except with a certain setup (via scaling where all bones have rotation = 0) because of the way Spine does scaling.
Other than that, Spine (especially Spine-Unity) is worlds ahead already.
Just to reiterate what Mitch said too, if you have some problems related to TK2D or Unity itself with shaders, materials and textures, it's mostly a separate issue. Spine is hooked up to use whatever material, texture and shader you give it.
With TK2D you can use png atlases. If you aim for mobile its a huge difference.
spiral написавWith TK2D you can use png atlases. If you aim for mobile its a huge difference.
Nothing stopping Spine Unity from loading external PNG atlases either.
Pharan написавJust a note though, if you were animating flipping via scaling with SmoothMoves, you may have a bit of trouble doing the same in Spine. Animating flipping (horizontally or vertically) is also currently not possible except with a certain setup (via scaling where all bones have rotation = 0) because of the way Spine does scaling.
Is it possible to just instantly update the scaling then? I don't need to animate a horizontal or vertical flip, but I do need the character to be able to switch between facing left and right (such as setting x scale to 1 or -1)
Will that be a problem? Seems like a pretty essential feature.
Afro-Ninja написавPharan написавJust a note though, if you were animating flipping via scaling with SmoothMoves, you may have a bit of trouble doing the same in Spine. Animating flipping (horizontally or vertically) is also currently not possible except with a certain setup (via scaling where all bones have rotation = 0) because of the way Spine does scaling.
Is it possible to just instantly update the scaling then? I don't need to animate a horizontal or vertical flip, but I do need the character to be able to switch between facing left and right (such as setting x scale to 1 or -1)
Will that be a problem? Seems like a pretty essential feature.
Thanks for being clear Pharan...
You are completely welcome to use FlipX or negative scale, but it has the same issues that all other Unity things do - meaning that you can't parent a collider to a bone in a character's hierarchy and THEN use FlipX and expect it to work - same as any 3D rig. I'm going to make a big "Wat" video about this topic today. TL;DR though its not Spine's fault and you'd have the same problems with any rig in Unity.
[Instant] flipping via code works fine. No problem at all. You can make your character face left and right.
A Spine skeleton has booleans called flipX and flipY you can set true or false and it'll make you character face left or right (or flip it vertically if you want). All basic stuff you'd expect, of course.
And if it doesn't intersect too much with game logic, using scaling by -1 or rotating by 180º will work too, though is less ideal if you want batching to stay intact (I think).
The situation Mitch describes only happens with slightly more advanced stuff like if you want Unity's 2D or 3D colliders to follow specific Spine bones, which would have the same problems in SmoothMoves or in a 3D context anyway. Even then, there's a way to use it so it'll work so it shouldn't be a problem.
Oh got it, no prob. My character is simple so I only need one main collider. I treat my character entities as a point in space, then add a sprite to the hierarchy so that the sprite itself doesn't dictate any of the character behavior.