- Изменено
Spine NEEDS a way to organise in Editor
Hi there,
First of all, Spine is absolutely amazing and a breeze to animate with, but I think it really needs to scale up as it has become a mature and production ready tool.
I posted a thread on "Tags to filter assets" in editor that was the staring point of this idea > http://esotericsoftware.com/forum/viewt ... =11&t=1998
I really feel like Spine is not scaling up to more complex project as well as it could and should. We get nice and complex animation tools, but not really a way to get everything to the next level in term of global project complexity.
In editor, there's basically no way to organise and filter objects or group of objects, yet.
This is, in my opinion, absolutely needed if you want to see Spine used on complex projects(in our production we're really suffering from the lack of editor tools to organise with bunch of assets).
Our project has a minimum of 2 realistic looking(means realistic animations and realistic details) characters, 5 mounts, 40 Gear Sets per character, realistic looking animations for ALL(see below why they all have to be in the same Spine file and why Gear has to be parented to the characters skeletons).
Here's a screenshot of what we have to deal with and go through by hand in order to work on a given GearSet on a given Character Skeleton. Note that this represents only 1 character skeleton with 3 GearSets, there should 40 per character.
Note we are using colour coded bones right to find stuff, not ideal, but kind of works, still we have to go object by object to activate theGear we want to work on.
(Click on the picture to expand)
What is the plan for Spine about that ?
Layers ? Tags ? Referencing external Spine projects(think Maya) ?
We need a way to filter and organise the data we're dealing with.
Not only can it get too much data in the Skeleton, it can as well get too much data in the Spine project itself.
Not that Spine is not capable of handeling hundreds of skeletons, bones and slots, yes it is, but more like there's no way for us to organise and work with that in a non ultra frustrating way.
Here's our project's scenario,what we're dealing with right now, at a basic level.
2 realistic looking(means realistic animations and realistic details) characters, 5 mounts, 40 Gear Sets per character, realistic looking animations for ALL. Doesn't sound like a lot on paper, right ?? Sounds like manageable. But in Spine, it's not. The freedom we gain on one side with animation is lost with workflow in Editor.
It just gets frustrating to find back the objects we want to work on in skeletons containing up to 500 bones and slots, when you have 6 to 10 skeletons in the same Spine file.
Please do not propose me to separate the Gear in different skeletons or the Mounts in a separate Spine file, this is not possible for us without sacrificing the animation quality.
Gear pieces HAVE to be parented to characters bones as we absolutely need to them to follow the characters bones motion(the Gear itself is animated as well, not just "plugged in", so it needs perfect timing), we end up having skeletons in editor with hundreds of bones and slots(we filter that at runtime down to something that runs) > a proper organisation solution like show/hide editor objects based on "tags" would make all this soooooooooooo much easier. Select the tags to display > "show" > work on your stuff > select tag to display > "hide" > the file is clean for the next person to work on it.
I mean, look, when I open my animators file and want to check the Gear7 on the 2nd character, I don't even know exactly where all the gear pieces are nested. I gotta to ask them to show me where they are, if they even remember, because they worked on that Gear a month ago.
Mounts and Characters sync is hard to achieve because they are and have to be separate skeletons in our project. Again we need perfect timing to not break the effect. Yes we can play the animations together in the same Spine file, but no we can't parent the character to the mount to work best.
External files referencing would probably allow us to do that.
Nested animations would permit that as well, if we're able to edit the nested animation in place. If not, again, good timing, will be just not achievable.
I know there's in editor a selection set of 10 selections you can save and retrieve, but we need nearly a hundred in our current project.
2 characters X 40 GearSets + 5 Mounts X 4 Gears = 100
Currently every time animators want to work on a given Gear Set, one has to go through the whole skeleton and find a bunch of bones/slots in order to activate and work on them.
This is getting very tiring for the animators(and for me if i need to do a fix). I know Spine is what it is right now, but why not make it scalable to more complex projects by adding some "simple" organisational features ? 
Note : we have no issue at runtime, this is only about editor workflow.
Also, is it to be considered to "open" Spine in order to let developers write their Editor tools ?
With this, I wouldn't even bother you with new features, we'd just write our own tagging system.
Thanks,
ben
Besides Tagging, another option I forgot to mention is just regular selection filtering.
We already have a Find and Replace tool in Spine, right ? And we are using naming conventions for our gears.
Like Gear_7 bones are the ones used for Gear 7. So it's easy to find them using a Find feature.
From there, could we maybe have a feature that let s us search a string, select the found assets, expand only these and optionally allows us to sow/hide them ?
It is not as elegant and modular as a tagging system, though.
- Изменено
I've brought up the issue before. You have as well.
I still think the naive 1:1 representation of the Skeleton data structure in the tree works against the animators especially with complex skeletons.
I'm sure Nate and Shiu appreciate the ideas but there's no rushing these things despite our caps and bolds and underlines. Nate's just one person after all. 
And as much as one can believe Spine is production-ready (and for most people, it practically is), it's still quite in development for someone like me and I think the next foundational features makes the Spine runtime what it's really supposed to be. And the editor, as much as it has improved and become usable when it gained the UI features you expect from modern graphics programs, still doesn't scale well with complex skeletons.
It's gotten better though. I have to be thankful for the new customizable shortcuts. Some of these were basic stuff that we've come to expect in something modern, but whatever. H to hide. P to parent. The reorientation tools for bones. CTRL+B to show and hide bones for easier selection by name in the viewport (if you enable bone names to be visible). CTRL+# for temporary selection storing. Heck, even just being able to just press enter to confirm dialog boxes was a big timesaving change.
That said, I feel your pain and frustration, and this tags idea sounds pretty good for the editor. I do often find myself wanting to search items in the tree by name, like I would the Windows search box.(I think Photoshop CS6 has a feature like this too.) For parts that may be grouped in a meaningful way, tag system makes sense.
And if something like it works well with Maya, I hope it becomes part of Spine too.
Yeah that's right the work that's been done on Spine is tremendous !
adding features to a tool requires much much muuuuuch thinking to be put in, I don't want to make it sound like it's an easy thing to do. Because it's not.
And Nate and Pharan have been making very good decisions in my opinion.
I tend to let my frustration parasite my speech
I'm not part of Esoteric, by the way. That's just Nate and Shiu. (see my signature) XD
I'm just a fan. And occasional contributor to the Unity/C# runtime.
I know hehe
Still, your intervention are extremely valuable !
When thinking about how to make complex projects manageable, we have to be sure we don't have the tail wagging the dog. There are many ways to use Spine and while you have a large and complex project, that doesn't necessarily mean that is the exact problem that needs to be solved. More ways to manage large projects would definitely be useful of course.
The core of your problem is that you need to stuff so much into a single skeleton. If you could attach skeletons to bones, it would probably help a lot. I understand you would need to animate multiple skeletons together. This would also affect the runtime, as it has to play multiple animations at the same time. The upside is you could animate a gun, for example, and all the complexity of that item is stored in the gun's skeleton. When you move on to the next item, it isn't left in your character's skeleton. Skeleton attachment is not too far away. Getting the basics working was easy, it just needs a lot of polish.
One way to organize multiple attachments that belong together conceptually is to use skins. It makes the most sense for "gear sets" where parts for different gear can go under the same skin placeholder. Eg, the "helmet" skin placeholder shows the helmet attachment for whatever skin is attached, or nothing if a skin has no helmet. This can be extended for other items, eg a gun that for whatever reason is made up of 3 attachments could be put in a skin. When you want to work on that gun, you show the skin for it.
At runtime you can combine skins, eg skin "gearChainMail" and skin "machineGun" are combined and the skeleton uses the resulting skin. Currently you can't combine skins in the editor, but this is planned and could be added relatively easy, making it much easier to outfit your character with attachments.
With this approach you may end up with a skin placeholder that only has one attachment in one skin. I guess this is ok, as it doesn't really have a negative impact.
I hesitate to add something similar to skins solely for grouping attachments. Skins are for grouping attachments and have the benefit that they decouple animation attachment changes from the actual attachments used, which enables animations to be reused with different skins.
A text filter for the tree is relatively easy to implement and would at least allow you to easily find things by name.
You've mentioned referencing another Spine file, which I guess is something Maya does. I doubt this is a great idea, as it spreads your project across many files and has a high complexity cost.
The bottom line is that we do want to improve the tool for more complex projects, but first need to get through the new features (skinning, IK), get the runtimes working with them, and make Spine more stable. Since it can't be our main focus at this time, anything we do to help complex projects in the short term needs to be relatively easy to implement.
17 дней спустя
Hey Nate,
I'm very late on this.
First of, thank you very much for taking the time and explaining.
Yes, a Text Filter for the Tree would be amazingly helpful, we're really struggling with the amount of objects we have to deal with.
Do you think we could have that ?
Regarding skins : the only reason we can't use them for our gear is that we have "subanimations" on the gear pieces. Let's say a torso piece of gear has feathers that are animated. Skin only accepts attachments, but not bones. Our gears tend to be animated and pretty different one from another.
What our programer does at runtime is, once gear is selected in the menus and just before getting into action, he filters the skeleton to find the gear pieces we need, rebuilds the skeleton containing only the selected gear pieces, filter the spine generated atlases and rebuild a custom one containing only the selected gear pieces + the base character > 1 draw call for a modular character.
Thanks for your support !
ben
There's a task for the text filter.
You could still use skins. You would have one skin for the torso gear piece that has only the feather attachments for the feathers skin placeholders. You can show that skin and animate the feathers as needed. At runtime, you would combine skins. Eg, the main skin that controls most of how the character looks combined with the torso gear piece. The problem is in Spine you can currently only have one skin visible. There is still an organization problem, but it may be more manageable.
3 месяца спустя
Hey Nate,
Thanks for the update !
hooo I understand now what you mean with the skins, and indeed, it does offer a partial solution to our issue right now.
ben
Hi !
Is there any update regarding that Text Filtering feature ?
Thanks !
ben