Skinned meshes performance issues

I am importing my animated models from Blender in the way, that they have skinned mesh renderers. I made manual performance comparison between used 2 LODs - they are just different in number of tris and verts. Unfortunately simplifying mesh (decreasing number of tris) does not improve performance at all (compare top and middle panels in the figure below).

Changing other options, like playing all animations, adding/removing shadow casters, using 1 bone or even replacing mesh (for skinned mesh renderer) to much lower tris meshes also almost do not affect performance.

However, if I am deactivating skinned mesh renderer, or replacing game objects with ones, which have just regular meshes (not skinned) show dramatic performance increase (bottom panel).

So I am curious, what drains my performance so much when I am using skinned mesh renderers?

If it is just script itself, when what is the purpose to use LODs, as they do not affect performance? Do I miss something here (i.e. maybe there is another way to import animated meshes)?

 

The last pic's drawcalls and tris look much much lower than the first two.
could you align your camera to contain same number of models as the first two pics, and test the FPS again?

 

Yes. It changes a bit, but not so dramatically:

My interest is mainly why between top and middle panels (in the first figure) is no change at all if I decrease number of tris and verts by factor of 2-3 ?

 

The statistics don't provide you solid performance data. You need to actually build all the different variants and compare the performance using this kind of script:
http://wiki.unity3d.com/index.php?title=FramesPerSecond

Don't compare the performance in the editor!

 

Just my guess, the drawcall in first two pics are 3000+, that's quite enough to draw down the fps in editor.
Take a look at this, it's just 3000 cubes,

 

use same material to reduce draw call from 3000 => 5, doesn't make too much difference,
only 33% performance boost, maybe it's just 3000 renderers :[


the profiler of white cubes;


The profiler of colored cubes;

 

Oh, I think this could the key answer to my performance issues. I read a bit about draw calls and batching, where it is mentioned that skinned mesh renderer is not batched. This could be explanation, why I am getting so many draw calls when I am using skinned mesh. But now I am wondering if there is possible to go around this problem?

 

Do you need to make each unit a SMR? Maybe you could do the modeling, like, 10 units in a model, and make them one SMR.

If you're up to fancy stuff, you could even try doing runtime SMR batching yourself.

 

That's would be interesting. You mean to merge lets say 10 human meshes into 1 model and use these merged models on Unity, or is it something else?

To try something like SMR batching would be very interesting. However, I am not sure, how I could make shared meshes, animations and shaders from the same model and apply it to all game objects...

I was also thinking to export all animation frames as different objects and use them in Unity as regular meshes. I.e. if there are 30 frames in my walk cycle animation, there would be 30 different models. Integer counter would run for each game object between 1 and 30, saying which phase to show. On the other hand model switcher would be switching between meshes based on that integer. I.e. let say game object get value 24, what means that at this time it should show 24th frame of animation. If there are 600 game object in my scene, about 20 of them would be satisfying 24th frame condition. To all these 20 objects frame model would be applied. However I am not sure if it would work, as mesh switching might be very slow in Unity, what would lead in terrible animations....

 

1. Yeah, That's what I mean, if your cam is very high, and you don't need to strictly identify single unit, I think it could be used as workaround.=)

2. I remembered there're some assets that can do the runtime SMR batching, MeshBaker?

Just think about another thing that, in Nobunaga 14, They simulate big battle field with many soldiers, I heard they make each soldier as a paper-man, maybe you could take a look at that?

Cannot see it very clear if its billboard.

 

Yeah, I'm getting a little refreshed mind now.
Let's just take the video as example, it's said a 9k vs 15k soldiers fight, and there're footman, knight, archer, rifleman, etc.

I just want to say, if it's all billboard or plane, then it's just 24k * 2 = 48k tri.
and assume each billboard is using like 2D frame animation, e.g.: 24 Frame one second,
then if they have at most 10 types of soldiers, and each have 120 different frames, then there're at most 1200 materials,

So, that means 48k tri and 1200 drawcall, quite do-able setup. you could even reduce more as the cam is quite high angle, I think you don't really need 120 frames animations per one type of soldier.

====================

And if you make atlas of each type of soldier's animation, then you could reduce the material to 10.

 

Nobunaga looks interesting, but the tricky part could be how to calculate these 2D projection views from different angle of 3d objects?

 

I didn't see the cam rotated around Y-axis, so I think maybe just use vertical billboard would do?

But I notice the soldiers sometimes attack from flanks, I'm no sure if the standard sprite is sufficent under that angle.
maybe need some more sprites in atlas for going middle way or going sideway.

 

Sprites looks quite promising. I am quite interested if there is possible to create sprite sets for various angles by scripting. The point here is if I can make projection of animated 3d object onto 2d sheet and record it from my random view of camera?

 

Bunt games has a "Model 2 Sprite" asset, I've never tried with it though.
https://www.assetstore.unity3d.com/en/#!/content/16610

 

I found quite interesting option to capture rendered scene and save it to png in this thread. If I can capture camera view, then half work is done. Next half would be to run a loop for animated frames of exposured single object. Another loop would be for rotation around y axis and third loop for camera angle to x-z plane (horizon). So it would be like 3d grid of png images. I found also this video to be quite useful in correctly setting up sprite sheets, where set up was done in 3d project. These steps does not require additional assets.

Interesting question now can be how fast Unity can switch between different sprite sheets...

 

Nice. never done such things before.
So If you have succeeded in filling the battlefield with sprite soldiers, would you share some experience?

thanks =)

 

Sure, I need firstly to look how things will look like and then I will let you know these results

 

Sprite Maker : http://forum.unity3d.com/threads/sprite-maker-convert-3d-to-2d.232302/

 

I like what you share

 

I got first rabbit! Non self-rotating sprites are here:


And also demo for whose, who don't believe
https://dl.dropboxusercontent.com/u/248943005/spritesBS/gr1/gr1.html

These sprites are animated, but it needs to zoom in to see the effect. I used SpriteManager scripts to bring these sprites to life.

However, there is one issue - sprites looks very blurred, as their resolution is decreased at low distances from camera. Does anyone know how to change this, as I can't find it explained in SpriteManager wiki ?

 

I haven't tried with SpriteManage before, so I'm not quite sure if it works same way.
Have you tried changing the texture type to GUI?
Or use the advanced type without Mipmap.




L: GUI R: Texture

 

Not bad
This looks about only 400 units in cam, have you tested with high camera to contain 2000+ units and check with the FPS?

 

well, I am currently working a bit on restoring correct rotation from various sides, that switching between sprites would make like 3d effect. First tests show that switching is not computationally heavy, so I guess I will have soon something like 3d self-rotating sprite analogs.

The issue there is that I can't find how to increase visibility radius of these sprites, as they are disappearing very quickly. If I would be able to increase it then results probably would look much better.

 

You could try adjusting the camera's far plane distance to 3000 or so.

 

I just did that. Here is the screenshot:

These small dark grey dots are sprites, but as they are viewed from very large distance, they are quite small. There are 3535 units visible in the entire scene and all should be visible in this camera view. Why draw calls are so low I am not sure, but I suspect, that it can be related that sprites are referencing to single animation, which I put just once in the scene. I also compared several sprites, and it looks like they individually playing different frames, as it should be.

I am also quite interested if there would be a way to increase sprite resolution lowering distances, as they are getting blurred very quickly?

 

Maybe the spritemanager build mesh by merging multiple plane together, no idea.

Have you tried changing the texture's type?

 

well, I just got some new results - I created sprites imitations for any kind of 3d game object. Here is a picture:

I still need to work out with some performance issues (sometimes it drains performance very heavily, while other times it runs very smoothly), but I will probably release this one quite soon.

 

I just find out that spritemanager is placed onto position of 0,0,0; but it builds mesh vertices at the offset, which is equal to the position of game object. As more game object, which holds sprites are in the scene, as more complex vertices configuration is set. I guess that it only uses single mesh, but builds multiple vertices in it.

However, one animation can hold one sequence of textures, i.e. object exposed from one angle. If I am reconstructing view from lets say 10 different angles, I need to use 10 separate animations and keep switching between them. I find out that better quality animation grids (i.e. set of 8 vertical rotation x 32 horizontal rotation = 256 views = 256 textures = 256 animations) are getting very expensive, as switching occurs very frequently, but I may try to find out these things...

 

I more or less finished with rotational levels, what brings 2d sprites looking like there would be thousands of animated objects in 3d. Here is demo. I included all these changes into my uRTS asset.

 

Looks much better, some sprites flicker still exist though.

by the way, you really baked each one animation in 256 angles? That's a lot.

 

yes, but it's building textures automatically. Here is the list of some videos, I just made on how this sprites system works.

Yes, it's flickering, but I suspect that it is coming from Sprites manager, as it sometimes making vertices to look to opposite side. If I would know when it happens, I could to switch vertices rotation, but it's not clear at the moment when it occurs.

 

I see great job you've done there.

 

Thanks, but it's just a beginning I need to do much more till I will get nice looking 3d realistic games.

 

I just implemented performance self-regulation and this brings previously unseen snapshot of almost 10k animated sprites playing at 10 FPS:

 

The tris and drawcalls are quite low, the renderer time is only 1.8ms.
It looks choked at the cpu, maybe sprite baking, pathfinding, AI or somewhere else

But I quite like the scene, maybe you could replace the green cube with a banner, that would make it much more visual appealing.
.

 

Well, these green cubes represents buildings. I still do not have "Castle" building model, so cubes are still here. I will replace cubes into castles, houses etc. in near future. Small grey dots are individual knights.

Sprite baking is not running here, as sprites are prebaked into png's in another scene. All materials are linked to these png's and loaded onto level. As I am looking to one direction, not all rotational modes are on - these animations, which have 0 sprites I set to be disabled.

I think the heaviest component here is NavMesh agent. Another possibility could be that search algorithms waiters are waiting not enough for large numbers of objects. I will take a look at some time to bring performance further (if it is not NavMesh, otherwise I have no power here ).