• Editor

  • Seeking project structure recommendation

    inglés

Hello,
I'm working on a pretty complex monster customization system for Unity Game Engine that would allow for 30+ unique characters composed of a Head, Body, Right Arm, Left Arm, and a pair of Legs. Any one of these categories must be interchangeable across all character types. So for example, a zombie body, with a werewolf head, ogre arms, and demon legs. The body is the part that connects all the rest and each body has its own unique pivot points for each limp, as well as a scaling factor for those limbs. I was planning to have each character be its own skin and use constraints to track the pivot points and scales. Lastly, the character has an up, side, and down facing direction (this is a top down game).

Since this is a pretty large and ambitious project, I want to be very sure that I am structuring the project correctly from the start.

Right now my project is set up like so:
• One character skeleton as root
• A slot for each body part (head, body, R. arm, L, arm, R. leg, L. leg)
• Each slot has an Up, Side, and Down placeholder
• Each character type has a Skin Folder and each typed body part has it's own Skin (Zombie Body Skin, Zombie Arm Skin, etc) and I use the Skin panel to mix and match one of each Body Part skin.
• Each Body Skin links to a constraint to rearrange the pivot points of each limb.
• I am using Animations to coordinate directional poses.
• I have all of this already importing nicely from Photoshop which is a big pro for me.

This works for most of my use cases. My only issue with this structure (so far) is that I worry about future extensibility and character type complexity. For instance, say I add in a Spider character and I want a pair of legs that are actually 6 legs instead of 2. To put it simply, it's as if I need to be able to swap out bone hierarchies with certain Skins. I don't think that's possible, so that is where I think this all falls apart. As far as I know, the only way to do this is to create all required bones and toggle/overload their use, but I worry about scope and performance over time. I also thought about each limb being it's own skeleton(and then I could create new skeletons for new limb types), but then I lose relationship between each body part, so that doesn't work.

I would prefer to use Spine since I already own Professional and would like to hire out animations more easily. I'm also more familiar animating in Spine. However, I am mainly a programmer, so I know that if I needed to, I could code all of this in Unity.

So I've come here wondering:
• Is there a better way for me to structure this to my needs?
• Should I be concerned about performance? I plan to have many instances of this character on screen at once.
• Should I even be using Spine for this over Unity Animation?
• Any "think outside the box" ideas?

I know that was a lot and this is an overloaded question. I very much appreciate anyone who can offer me any kind of recommendation. Thank you very much in advance!

-Eric

Related Discussions

  • Nate

  • Publicación n.º 4
  • Publicación en inglés
CosmiCat_Arts escribió

This works for most of my use cases.

Yep, it looks like a good approach. One thing though, you could rig the unique parts just once in Spine, then swap out the art at runtime. This is mentioned here:
Runtime Skins - Spine Runtimes Guide: Creating attachments

CosmiCat_Arts escribió

My only issue with this structure (so far) is that I worry about future extensibility and character type complexity. For instance, say I add in a Spider character and I want a pair of legs that are actually 6 legs instead of 2. To put it simply, it's as if I need to be able to swap out bone hierarchies with certain Skins. I don't think that's possible, so that is where I think this all falls apart.

Bones can be added to skins:
Skins - Spine User Guide: Skin bones

However, while you can use skin bones to basically cram multiple skeletons into one skeleton, a spider may be better organized as a completely separate skeleton.

CosmiCat_Arts escribió

I also thought about each limb being it's own skeleton(and then I could create new skeletons for new limb types), but then I lose relationship between each body part, so that doesn't work.

Assembling a character out of multiple skeletons can work, but you lose some functionality with draw order, as usually each skeleton is drawn completely above or below other skeletons.

7 días más tarde

Thank you very much to both of you!

Ah, I totally missed that bones can be skinned - glad to know, that makes things much more manageable.

For having multiple skeletons, I can't find a way to add any kind of relationship between them, is this possible? Or do I just need to sync animations between them? If so, I can see that getting tedious; I will stick with bone skinning instead.

Is there a significant scaling overhead in Unity based on the size of a Spine project? I speculate memory and initialization will take a hit since I'm guessing the entire skeleton and all textures will get statically loaded with just one character instance (is this true?). I don't need everything loaded for just a few instances in a scene.
And what about scaling overhead for general post-init runtime activities like swapping skins and playing animations? Is there a point where a skeleton can have too many skins and animations? (besides maintainability). If so how many is the recommended too many? Tens, hundreds, thousands?

I'm just worried about putting a lot of effort into a Spine project just to find out down the road that I'm asking too much from it. I suppose if performance became a significant issue down the road, I could always keep a master project and then split it up into several projects for individual body parts and skins - then import those projects into Unity. Then I could load smaller skeletons as needed. There would be more disk space used for redundant skeletons and animations, but that's not as important to me as runtime performance. Has this been done before?

Thanks again!

  • Nate

  • Publicación n.º 6
  • Publicación en inglés

The only relationship between skeletons is which is drawn on top:
Skeletons - Spine User Guide: Skeleton draw order

Is there a significant scaling overhead in Unity based on the size of a Spine project? I speculate memory and initialization will take a hit since I'm guessing the entire skeleton and all textures will get statically loaded with just one character instance (is this true?). I don't need everything loaded for just a few instances in a scene.

The skeleton data is unlikely to ever be large enough to need to worry about it. Loading times should be fast when binary is used.

Image data is separate from skeleton data and it is more common to have so many images you can't load them all at the same time. In that case you can pack multiple atlases beforehand and only load what you need, or you can pack an atlas at runtime with only the images you need.

Is there a point where a skeleton can have too many skins and animations?

Nope! You can have as many skins and animations as you want without affecting runtime performance.

The Spine editor is usually very efficient, but if you make a massive Spine project that is significantly larger than what most people are doing, then you may give the editor some trouble. You should be fine up to around 75k attachments. Beyond that, depending on your CPU and other hardware, the editor may not be able to hit 60 fps. The editor remains usable even below 60fps. You can try it out by duplicating attachments a bunch of times, selecting all those and duplicating them more times, etc. For example:

Image removed due to the lack of support for HTTPS. | Show Anyway


That's 54k attachments at 61fps, though the FPS is capped at 60fps to match screen refresh rate. Uncapped it is 77fps and drops to 60fps at 75k attachments, then goes down slowly from there. Note this test was done some time ago and we likely have a bit better performance in v4.0+.

People have made projects with 50k+ attachments, but it is not a good idea. If you have so many attachments, it's better to use attachments as "templates" and replace them with images at runtime. That way you don't have to have every possible attachment in the editor, which would be tedious when you have tens of thousands. More info on that here:
Runtime Skins - Spine Runtimes Guide: Creating attachments