Why Bone Count Matters?

So the doc [ https://docs.unity3d.com/Manual/ModelingOptimizedCharacters.html ] and lots of old posts suggest bone count matters, especially for mobile.

I'm honestly struggling to understand why it should matter, at least on the order of hundreds of bones vs the advice to "keep the number below thirty for mobile devices, and don’t go too far above thirty for desktop games"

I believe there is a per vertex cost proportional to the number of bone weights (1, 2 or 4), and the cost to walk the transform hierarchy and make matrices in object (or world) space for each of the bones on the CPU should be insignificant (right?)

Engines supporting GPU skinning (via vertex shader) on DX 9 or GLES 2, and storing the bone matrices in uniforms would be limited by the number of uniforms supported, but everything I can find suggests Unity only supports software skinning on such targets, and I don't think that fits the advice.

So why does bone count matter? Am I missing something?*

*In before someone suggests the question is wrong because it suggests I haven't benchmarked Unity's performance myself: No, I haven't and that's not helpful (!): whether Unity performs well or badly wth a high number of bones doesn't speak to whether it should, or why the documentation (and many threads) suggest bone count should matter.

 

I am honestly struggling to see the point of your post. If this doesn't apply to you, why is it an issue?

It seems to me you probably won't run into bone performance issues. If you did, you'd know. Less bones do perform better, on all platforms, due to less work being done.

Consider 500 enemies with 120 bones each?

A lot of projects require access to the transforms, you can optimise them out in mecanim if you do not require access to optimise CPU transform performance. GPU skinning is available on a lot of hardware for the actual skinning optimisations.

 

Hippocoder, thanks for your reply.

I'm new to Unity and reading the docs - there's a lot of things that don't 100% make sense and this is one of them. I posted in the documentation area because I feel the documentation is lacking here.

I don't believe I suggested that this doesn't apply to me, but if the implication is that Unity has bad performance in a place I'd expect better, I'll look towards alternatives.

I haven't yet, but I've invested very little time in Unity thus far... that comment is hardly reassuring... or encouraging :O

Besides the whole point of performance guides to to try to avoid such problems in advance, right?

I presume transforming bones to be fed to CPU/GPU skinning is O(n) with the number of bones and that the vector maths involved is a dozen or so FPU operations to concatenate matrices and possibly convert quaternions to matrices.

500 enemies with 120 bones on say mobile seems unreasonable (but less so for PC, especially if you fall back to proxies with lower bone counts at a distance), but it might be unreasonable still for 500 enemies with 25 bones; though the linked documentation doesn't mention it in relation being multiplied by the number of characters (of the same mesh or otherwise, I believe instancing might play a factor in such cases). From my assumption of what Unity might do, I agree it would make sense to expect this to scale (but the documentation doesn't actually suggest this)

I presume that just saves on garbage for the GC to collect?

I'll admit too: I don't have a good grasp of what Mecanim is yet. Just that it does stuff, lots of different stuff in fact, that's all very monolithic but that doesn't necessarily work together (like what do muscles do, if they aren't used for forward animation or IK; or rag dolls which are separate it seems?)

 

It's just we see it a lot - your query is the most common kind. I think you'll probably run out of steam adding content before you experience actual performance issues. And if you do, please come back and post - there are a lot of workarounds.

I'm sure you've heard the phrase that premature optimisation is the root of all evil - well it applies here too! In general, Unity is a moving beast, optimisations are often applied every major version update. It's also quite old so the docs are usually going to be out of date the moment they're written.

As Unity supports more relevant platforms than any other engine that I know of, the advice is broadly generic, and usually centred around some horrid tv box, or web gl, or anything - you just don't know until you find out due to it being specific to your own parameters.

In general though, I've never encountered a bone performance issue.

 

Again, not reassuring... I would've most queries would be asking for help with basic issues that could be solved by reading documentation, Googling, common sense, general game/development knowledge, or some mix of these.

I try pretty hard not to post such things. I think posting to say I'm sure the documentation is wrong is different.

I did want to confirm that was what it was, I'm not an "art" guy so I don't want to do any more of this rigging stuff than I have to... I don't want to lots of effort adding helper bones just to have to strip them out later (nor corrective blend shapes, to have to reauthor them for a different rig, but I don't feel comfortable with that tech)

EDIT: And part of that means deciding some aspects in advice like whether I'm likely to want to use Mecanim's IK down the line, because then I understand I have to parent twist bones in an unusual way (so that child IK bones aren't descended from them) so that it won't break it (or at least that's my understanding of "with a correctly configured Avatar"(emphasis manual) looking at 3rd party advice)

Anyway, I do think "bad" advice in documentation should be a addressed, if that ultimately is what it is, I do read and heed performance guides (because I can't afford to test on many devices, etc*) but I do take them with a few more grains of salt then many hence my scepticism here.

The problem with advice like this is that even if removed now seasoned users will likely continue to quote it for years longer eg. as a potential reason for others performance issues. Particularly if they had previous (potential confirmation bias) where they removed bones and performance seemed to improve or the complaining user didn't followup

Here's some Siggraph 2012 slides suggesting 4 bones weights on iPad 3 CPU(albeit optimised Neon instructions) can transform 6.7 Mverts/sec... that's 5 years ago: http://www.realtimerendering.com/downloads/MobileCrossPlatformChallenges_siggraph.pdf

*There's a post over in the Daydream forum suggesting that one of the Unity recommendations for Daydream may be misleading (it's from a Google engineer), regarding 16 vs 32 bit colour buffers.

Anyway, thanks for your very quick and patient replies

 

No, it just means less work is done as they don't need to be exposed.

Just do stuff. I think you'll find Unity can keep up with ease. It'll probably be non engine specific choices you make that cause problems or not such as asking the GPU to do to much - heavy shaders, bad design and so on... (not a Unity problem).

A Unity problem is will crop up when you're pushing things a lot further than worrying about a few bones

 

When researching this topic, this helpful response is the first google result, years later. If you're going to answer questions on a forum, just answer it or don't. When half of the answers look like this, it is beyond frustrating. Clearly the point of the post was asking for additional info on bone count and performance, if any info was possible.

 

Your first post is to raise a long-dead thread to whine to a moderator of the forum. Not a good start, Cletus.

The point of the feedback is: build games, determine the actual leading bottleneck of the game performance in YOUR GAME ON YOUR TARGET, and focus on that. Any minute spent trying to theorize about performance of some feature without cold hard data is a wasted minute.

The engine is really good at giving you the data about YOUR GAME ON YOUR TARGET instead of trying to guess: just create an example project with a 20-bone skinnedmesh, a 30-bone, a 50-bone and so on. You don't need to hire an artist to do that. Duplicate the mesh until your game struggles on your chosen target platform. Look at the profiler to see what the actual contributing cause is. Maybe it's the bones. Maybe some other part of your game is sucking down so much CPU overhead that the bone count is lost in the noise, and you now know cold hard data about what to focus your team energy on.

 

I am well aware I was whining to a moderator of the forum - it's specifically why I posted on this dead thread, but thank you for the summary. It's frustrating that to newcomers, THIS is what people see. Nasty responses to well meaning questions, over and over again. In response to Unity's lack of documentation, the moderator of the forum whines to the poster because they are frustrated that these types of questions get asked so frequently. As the original poster says, this is the farthest thing from reassuring.

 

Unity is a frustrating engine to use, so reading the forums and getting frustrated is excellent preparation for using Unity.

But to go back to the original question: An engine doing less stuff is going to be faster than it doing more stuff. So bone count "matters". But maybe it doesn't. Maybe you have only one character at the screen at any time, and you're targeting high end PC, in which case, go nuts.

If you are a beginner, asking these questions is kinda pointless, especially in pure theoretical terms (as opposed to a more practical and specific: I have a game for PS4 and I want 20 characters on the screen, what's a reasonable bone count?) and a lot of people get into the mindset of preparing and getting info and will probably hit a completely different performance issues. You can't really predict what performance roadblocks you are going to hit if you are a beginner and you are using S***ty middleware engines with code outside of your control.

Bone count matters, does it matter for the game you're making? Who knows? And even if I answer today, will that answer also be valid tomorrow? Who knows.

Now if you want to talk about Unity's manual being really terrible at times and the docs team being really reluctant to do any meaningful changes to it, even when the info in the manual is misleading, outdated, or flat out wrong, we can have that discussion, although nothing will come out of it.