Quick&dirty Unity3.5 crash demo (skinned mesh)

Just a very quick dirty crash test I did last night with Unity 3.5 Preview exporting in Flash.

Sorry about the graphics, im not a good rigger or modeler either

Look at this picture, it shows while playing that only 3 drawcalls are needed for the 9 "smith" there, even if they animate independently, one has also a ragdoll on it.

how can be just. 4 draw calls here ?

check it out! (latest version of the flash player needed)
http://www.madoball3d.com/test-hi.html

What do you think?

 

nicely done!
is this a single mesh object, with merged rigs/skeletons; instead of each actor being its own mesh with its own rig?

 

exactly, this will allow crowds like seen in some games, with the limit of bones numbers per group and 65000 / numOfverticesOfSingleCharacter for the obj limìt.

imagine 10 Smith, with 10 skeletons, with 20 bones each, each smith is 800 vertices, would mean deal with a skinned mesh with 200 bones and 8000 vertices. And, 1 drawcall.

the real challenge now is making this easy to re-use, without the need to touch the graphic package, and here is where Ippokratis could give an hand

 

Hi,
This is a very interesting approach. I am curious about some things :

• How much time did you spend in the graphics program to achieve this results ( aprox )?
• What is the rendering time ( in ms, from the profiler ) with and without this approach, for the same objects ? ( I.e x ms with 10 separate Smiths, y ms with 10 batched Smiths ).
• How many bones per vertex do you use ( from the skinned mesh component in unity inspector ) ?

I ask because batching is done to reduce the rendering time. Batching many objects into one reduces the overhead each draw call has, but, in certain circumstances, batching can degrade performance. The reason is that besides the number of draw calls there are other parameters as lighting, nr of bones per vertex, visibility, nr of vertices, nr of triangles e.t.c that influence the decision to batch.

Version 1.4 of Batching Tools will not have this functionality, but I plan to include batching of skinned meshes in a future version, under certain conditions. The reason for this is that in my tests I found that batching skinned meshes with vertex bones count over 1 degrades performance. Hence, I will opt to support 1 bone per vertex.

I wish you the best with your project and I also wish to thank you for your support and for sharing your findings,
-Ippokratis

 

1.
That was not so long times, just clone twice the char, to have 3, and exported as a single mesh with 3 independent skeletons.
Fortunately the graphic tool renamed for me automatically the joints name, so I really had to just check that the 3 were animating correctly (In the graphic package, if I animate walk, all 3 walked, but in Unity I could achieve independent animations.

2.
About the profile ms, I didn't check with single characters, but since the total number of bones and of triangles is exactly the same, but the draw call is /3, I'm sure this will benefit <30draw calls mobile applications. But you have to pay attention and use very low poly stuff. I can make more deep test at a later time.

3.
Number of bones is around 16 per char.
I didn't know you could check this in the inspector. I'm pretty sure I used a 3 vertices per bones, weighted.
The artifact you see on the model, is just a rig fault on some triangles, not a "rigid" skinning (1 vertex per bone) problem.


Now, consider this famous mobile game screenshot attached here below, these little characters are very low poly and low number of bones, but they are SO many ( note: airplanes are not animated) !!!

You see ? How much stuff is in play ?
This runs 30 fixed on the iPad 1st gen too and on the iPod2G (where the limit is just 7K tris) too !

How did they do ?
200 creeps on screen without 200 draw calls ? Just guess.
Not to mention particles. I see many many many explosion and bullets around here!

In my opinion, for each type of creep, there is a single mesh with this material, moving all (10, 20, or even 50) of them.
Hence: 1 for ants, 1 for aliens, 1 for flying. 3 Draw call to shoot 3x50x 80-120 triangles creep. Not to mention the 50 flying creeps will dynamic batch, so they all will make 1 draw call anyway, even without being a single mesh.

Total triangles will be around 10 / 15.000, with just 3 draw call to visualize 150 average creeps on screen.
This seem a very good compromise to me!

 

So how do you animate them independently?

 

Code (csharp):

1. What is the rendering time ( in ms, from the profiler ) with and without this approach, for the same objects ? ( I.e x ms with 10 separate Smiths, y ms with 10 batched Smiths )

Here the two benchmarks, first the 27 idividual skinned mesh characters, then the 3x9






I imagine that with 50 or more chars you will feel the difference. especially if 1 with 5 you would have 10 draw call against 50(out of mobile reach)


@Hippocoder: This is fair easy by code, but can also done by disabling the root gameobject animation component, while putting one for each skeleton root node.
oh and a,so you should import the mesh: " Store in original roots"


Note: the 3 additional draw call and 8'batched are for the floor/walls

 

Sorry for stupid question, but what exactly is going on behind the scenes that you get less draw calls? What is changed from original/ default workflow?

 

I'd be very interested in an MS comparison on the same number of actors(mesh-renderers) animating individually, not batched using this method(via their rigs), compared to the same number of actors all animating using the (ever so interesting) animation component trick you described above.

I've used a similar method to reduce draw calls in the past, but was unaware that you could disable the animation component for the (grouped) meshrenderer, and then reapply separate animation components for each actors root bone. If this works like you describe, this is genius imo. Can you really call upon stored (bone-based) ANIMATION CLIPS to each individual root bone, thus affecting that particular actor in a batched mesh of multiple actors, without breaking batching?

To elaborate on this point: Lets say I have 10 actor-meshes(rigged meshes with animation clips, as an FBX file), each actor is the same mesh, each(obviously) with the same 5 animation clips(walk/run/attack/defend/idle). Using this method, I would merge all their rigs into one master-rig, and merge all their (10x)meshes into a single master-mesh. I then export this FBX out, so unity can import this newly merged mesh(with 10 individual rigs now merged into a single rig). If I understand you correctly, are you saying that I could remove the animation component from the master-mesh(the 10x merged individual actors), and then re-apply a new animation component to each of the root bones in the new master-rig for each of the 10x(merged)rigs, THEN be able to trigger individual animation clips in each of the 10x(merged) actors? So, of the 5x animation clips I describe above, that each rig would have, I could then have one actor running, one idling, another attacking, etc, etc, and still have 1 draw call? Please excuse the long text, I just wanted to see your insight into this. Thank you for your help

 

What do you mean exactly by breaking batching ??
Skinned meshes don't batch. That's the point.

Otherwise why should I bother with this ? I should have just thrown my 200 vertices characters and I was done.

Yes is exactly what I'm demonstrating here.

The answer is simple.
If I have a single skinned mesh with a single skeleton, I have 1 draw call.
If I make 100 clones of it, no matter what method I use for instancing, I have 100 draw calls.

Instead (method of the second picture, which shows 27 characters with just 9 drawcalls, 3 are for the background)
If I have a single skinned mesh, done with 3 characters and 3 skeletons, I will still have 1 draw call
and when I want 30, I just make 10 draw calls instead of 30.

Imagine what you can do if you use batch of 5 - 10 characters.

This seems fair enough to will to investigate!

 

hmm, I cant seem to get this to work using the method you described. I'll keep at it.

"@Hippocoder: This is fair easy by code, but can also done by disabling the root gameobject animation component, while putting one for each skeleton root node.
oh and a,so you should import the mesh: " Store in original roots"

If its not inconvenient you have the time, I'd(And I'm sure others) really appreciate a more detailed step-by-step walk through as to how you achieve this.

 

Sure.

Ill post something to the asset store when I have something great and better automatized.

 

sounds good. Please pardon the additional questions, but your help/insight would be greatly appreciated:

What modeling/3d-suite are you using?

are you exporting out the rigs/armatures merged into one rig, or just merging all of the meshes into one mesh?

are you renaming the bones(adding a suffix/prefix or whatever) to each of the rigs that you're duplicating?

on each of the actor-meshes you merge into one, are all of the vertex groups all named identically to that of the original mesh you made the duplicates from?

are you exporting as FBX to Unity?

Are you exporting the merged mesh(multiple actors) along with SEPARATE rigs, into the same FBX?

I've gotten 2 actors, duplicated merged into a single mesh, with 2 separate rigs/armatures, to export and (in a broken fashion) "work" in unity with a single draw call, but am running into many issues and glitches. I'd appreciate some insight/walkthrough if you have the time. I'm sure many would benefit from you sharing more of your process.

 

Hi,
Sorry for the delay,
Thanks a lot for sharing your findings Litobyte Softworks, best luck with your project,
-Ippokratis

 

zhx:

1) a) Modeling: Blender b) UVmapping/Final fbx export: UltimateUnwrap3D c)

2) Meshes as a single mesh, with different skeletons, each with its own root, and without a general father.

3)

No, the animation package I use does this for me when I merge more scene with the same skeleton.

4) This question is too techy, or better, I might have not understood it, or it may regard a particular package, but I guess vertices have just index numbers not names, dont't they?

5) Yes we are exporting the final file to Fbx but we go through a .x deforming meshes file export, then we convert this with Ultimate Unwrap which supports animation, multiple UV and what not, we use FBX because is the best standard.

6) Yes we are basically doing so.

7) The problem you might have is about understanding what are the object that need the Animation component and what not. Or with some mistake the last export is making. In general, if you have many different skeletons with different joint names, you would be good to go, I will post a screenshot of the FBX's hierarchy. Maybe this helps.

Sorry for the delay,

 

I REALLY thank you very much for talking the time to write such a detailed reply. I'm going to attempt a 2nd round at getting this to work from Blender3D(my 3D tool of choice) to Unity. Thank you again

If you do still find the time to post a screenshot of the FBX's hierarchy, it would be much appreciated, thanks

 

Hi, I'm just finishing up a patch for blender3d that limits the number of vertices per bone to a selected number. This might be helpful for exporting to some game engines with bone limits. If anyone wants to try out the patch (can custom build for windows or linux to a given version) or test when it is released, or help with the wiki that would be great.
If there are any other glitches in the workflow of exporting meshes related to vgroups let me know.

darKoram

 

@darKoram that would be a most useful patch for some engines. Definitely post links to it, and share it on twitter with @AIBlender on twitter