Mesh Animator - Highly efficient animated crowds. For support, please use email.

Congrats! You have leveled up!

 

Next time check the forum first! Congratz for your unity!

 

Great Asset. Unbelievable performance with many instances on mobile. Great support!

 

Mesh Animator doesn't work in Unity 2018.1.3f1

 

Hey eron, I'm looking into using it with the latest version. What particular problem are you having?

UPDATE: I've tested everything and it appears to work correctly with that version of Unity. Can you please PM or email me your issue and we'll get it sorted out

 

jschieck, I am getting weird crossfade jitter. I tried to see if it was my animations or mesh, but it seems like it is related to MA. Someone posted a video of this issue last year so I am just going to link it.

FYI, it doesn't happen when I have few meshes, but when I go above 300+ it starts to happen. In standalone, it is less prone, but I let the animations run for 10 minutes and all 2000 meshes started doing it.

I am on 2017.4.2

 

It is a nice tool but no playmaker support?

 

I'll see what I can figure out what's happening here.

No, not at this time.

 

Any update on this? How do you plan for it to work?

 

I've been very busy so not had to time to work on it lately. Essentially the MeshAnimator component would only be a reference to the basic information needed for rendering and settings as it is now, and then the MeshAnimatorManager would handle calling the Graphics.DrawMeshInstanced for each active object, batching where it could. Removing the need for each individual MeshFilter and MeshRenderer.

 

Do you still plan to add support for it in the near future? Otherwise will probably start making a system myself.

 

jschieck, have you had any progress with this issue? I would like to implement ma in my game, but this issue is stopping me. Hope you can prioritize it as the issue is very abundant when there are many characters visible.

Thanks.

 

I'm not able to replicate the issue on my end. Can you PM or email me the mesh you're testing with? Also just to for testing purposes, can you you comment out this line:

#define THREADS_ENABLED

at the top of MeshAnimator.cs and let me know if it still happens?

When I find time definitely, but I can't make any promises as to when it will be done right now. Swamped with work at the moment.

 

That did it! The jitters are gone, but does that mean it is no longer multi threaded?

 

Right when cross fading it will generate the vertex positions on the main thread, which isn't a huge performance hit, just more efficient to do it elsewhere. I'll have to figure out why it sometimes glitches like that.

 

Thanks, I will be waiting for the update!

 

Hi, I've been using MA for a couple of years now and it's a fantastic asset - has really enabled me to do some fantastic in-game stuff featuring scores of gameobjects!

However I've been running into some errors in the log when pooling some MA'd objects which I believe are caused when a gameobject is deactivated/reactivated:

Code (CSharp):

1. IndexOutOfRangeException: Array index is out of range.
2. (wrapper stelemref) object:stelemref (object,intptr,object)
3. System.Collections.Generic.Stack`1[UnityEngine.Vector3[]].Push (UnityEngine.Vector3[] t)
4. FSG.MeshAnimator.AllocatedArray`1[UnityEngine.Vector3].Return (UnityEngine.Vector3[] array, Boolean resetValues) (at Assets/MeshAnimator/Scripts/Utilities/AllocatedArray.cs:43)
5. FSG.MeshAnimator.MeshAnimator+CurrentCrossFade.ReturnFrame () (at Assets/MeshAnimator/Scripts/MeshAnimator.cs:71)
6. FSG.MeshAnimator.MeshAnimator.UpdateTick (Single time) (at Assets/MeshAnimator/Scripts/MeshAnimator.cs:512)
7. FSG.MeshAnimator.MeshAnimatorManager.Update () (at Assets/MeshAnimator/Scripts/MeshAnimatorManager.cs:47)
8.  

Is there a method I can call to "tidy up" the MA component before deactivating it to try and avoid the above error spamming the log?

I'm currently calling Pause() on the component, and then disabling it, before deactivating the gameObject, but still get the error above.

This is on Unity 2018.1.5f1 (Win) with the latest version of MA.

Thanks!

 

Right about the Get() and Return() methods in the AllocatedArray.cs class. Try adding the following attribute and let me know if it stops the error from occurring

Code (CSharp):

1. [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.Synchronized)]

 

Thanks for getting back to me! I've just given this a go and *I think* it's fixed the problem! I'll do some more testing tomorrow to be sure (as it's an intermittent issue).

May I ask what those lines did?

Thanks again.

 

The Synchronized flag essentially puts a thread lock around the method, which in this case it's static, so only one thread can access the method at a time. What was happening is crossfading was happening on a different thread and trying to access the stack at the same time as the unity main thread when you were enabling and disabling objects, causing the error.

 

Aha thanks for the explanation!

I've also been messing around with threading this last week, so these problems could very well be a result of that.

Thanks for your help.

 

So does this asset correctly handle lighting? I tried out the animation instancing stuff from the Unity github repo, and it performs fine but they didn't solve for correct lighthing in their shaders.

 

Hi, I’ve been using this asset for few weeks. After I converted one character with a few animations, it seems to work but with one error below.

>>Mesh.Vertices is too small. The supplied vertex array has less vertices than are referenced by the triangles array.

The original character I converted has 9898 verts, 15009tris and 2 submeshes, and my Unity version is 2018.2.0f2.

Could you tell me what causes this problem and how to fix it?

Thanks in advance

 

So I'm having the same issue reported a while ago, strange jitter with threading enabled. Also recalc crossfade normals is pretty expensive. If I remember correctly that doesn't have to run on the main thread?

Other then that liking the asset. I'll likely convert your threading over to jobs and get some proper parallel work going that way, get rid of those locks. I mean it's way better then mecanim but it's still right at 3ms with normal recalc and crossfade for around 400 characters.

 

Yes it should handle lighting correctly.

I'm still working on a fix for the threading issue. RecalculateNormals cannot be done off the main thread in older versions of Unity, as well as the Job System did not exist before. There will have to be a major rewrite for newer versions of Unity done now that the Job System is out of experimental mode.

Would you be able to PM or email me the model so I can take a look?

 

I've sent the model to jschieck@gmail.com

Thanks

 

So I did a quick refactor to make it work with jobs. It's actually very straight forward just breaking up UpdateTick into stages. Probably made more then was necessary but basically it starts in Update, when it hits the point it generates the cross fade mesh calls a job that does that, then in LateUpdate it completes the job and runs the remaining stages.

It should work just fine on versions that don't support jobs with a few more ifdef's. No logic really changed I just had to turn a couple of local vars into class fields to persist over the code in UpdateTick that is now broken out over several methods.

Be happy to share it if you want it. Was kind of a rush job stages are not really where they ideally should be I think, but the general flow is correct for a jobified system.

 

Also found out why I was sporadically hitting errors complaining about vertices not being right. I saw a post about it earlier here also. It's from currentCrossFade being changed while in the middle of a threaded op. Same bug is in my jobified version also. Will try to work out a fix.

 

Hi I am developing an rts with about 1000-2000 units. All my systems work perfectly besides animation which kills my CPU. Will your asset instance my units or are there some catches I mean what are the limitations of your asset?
I guess since it uses textures to read animations there is no anim-blending, also can I use your asset for LODS while close units animate with builtin animator? And lastly what breaks instancing, I guess I need same mesh and material but do units need to be in the same animation frame to be drawn together?? I mean can a unit be on Walking animation frame 7 and another at frame 12 be drawn together or do I need a way to sync my units for optimal results? Thanks for your time

 

The system does not use textures for animation, and there is simple crossfading you can enable, but no blending beyond that.

Yes you can use the normal Unity LOD system to have an Animator on the lowest level, and MeshAnimator on higher levels. You can then synchronize the two with some simple scripts when the LOD level changes.

Yes this is how it works. Only meshes displaying the same frame of animation will be instanced by Unity. You could optimize this by splitting your unit's into groups and having them somewhat synced in their animations, rather than having them all on the same frame which would probably not look as good.

 

This has been fixed in the latest release that's live now.

 

this is great! Yeah my bad about the textures I got confused by another solution. Well even without sync though statistically 2000 units on a 70 frame idle will be drawn 28 at a time which is great!

 

So I bought the asset and it works wonders, its not only the instancing but mostly the animation baking doing the magic. I also profiled your code and noticed that most of the performance goes to updating exposed transforms without them performance is outsanding. Could you maybe fix this in the future? I guess a workaround would be to bake weapons etc. on the character. Regardless its a must have for any RTS game!

 

Preparing for smaller scale RTS (hundreds of units) this information is invaluable

 

So is there any way of baking lets say a mesh helmet to the character using this asset? Reducing exposed transforms really saves a lot of performance.

 

Mesh baking creates a complete set of meshes per animation per skinned mesh. So ya you can create a single skinned mesh with any variety of whatever you want, but it will become memory prohibitive really fast. Ie you can't use this approach when you have characters that all have custom clothing.

You really only see extensive character customization in rts games from larger studios, because the engineering required to make that work gets complex really fast and is not supported out of the box by any off the shelf engine.

For a few hundred where you need customization, legacy animations are your best bet right now. It's what I'm using for a game with 500 fully unique characters in view. It chews up around 5ms of main cpu time, I've had to basically move everything except for animations and rendering into the job system to make it all run at 60fps. But mecanim is almost double the cpu for the same numbers.

 

Hmmm got it, anyway I'm using very few meshes(4) and created a lot of materials to give appearance of different armor. Yeah Mecanim is a performance killer at this scale, my plan is to use your system for my 2 lods and legacy for the full resolution (13k triangles) which only appears really close.

Helmet is a simple mesh so I don't need to store its vertices. I see that you use Matrix4 to interpolate transforms between frames can't this be baked or somehow optimized? Anyway for me everything works wonders with 1500-2000 characters so it even goes beyond my original expectations! I'm just a performance nerd and believe you could push more in that direction but maybe this is too specific or it breaks your workflow. Anyway its a 5 star from me!

 

So I set up everything and it works wonderfully animations/crossfades/state machines. But there is a sync problem with LodGroup do you have a solution or some pointers? Does mesh animator work for multiple meshes? Or do I need to create a custom Sync Script and upon changing lod manually assign curent frame??
Edit: Also should I disable MeshAnimators of inactive lods?

 

Yes you would need to make a custom script to sync the Mecanim animator and the MeshAnimator. You should be able to hook into the OnBecameVisible and OnBecameInvisible to sync the two when the LODGroup enables/disables the renderers.

For example:

Code (CSharp):

1. using UnityEngine;
2. using FSG.MeshAnimator;
3.  
4. public class LODSync : MonoBehaviour
5. {
6.     public MeshAnimator meshAnimator;
7.     public Animator animator;
8.     public SkinnedMeshRenderer skinnedRenderer;
9.  
10.     private void Start()
11.     {
12.         // hook into the mesh animator visibility callback
13.         meshAnimator.OnVisibilityChanged += OnVisibilityChanged;
14.     }
15.     private void OnVisibilityChanged(bool visible)
16.     {
17.         if (!visible && skinnedRenderer.enabled)
18.         {
19.             // sync mesh mesh animator -> animator
20.             // requires that the mecanim stateName == animationName
21.             MeshAnimation meshAnimation = meshAnimator.currentAnimation;
22.             float normalizedTime = meshAnimator.currentFrame / (float)meshAnimation.totalFrames;
23.             animator.Play(meshAnimator.currentAnimation.animationName, 0, normalizedTime);
24.         }
25.         else if (visible)
26.         {
27.             // sync animator -> mesh animator
28.             AnimatorStateInfo stateInfo = animator.GetCurrentAnimatorStateInfo(0);
29.             // figure out which state is playing
30.             for (int i = 0; i < meshAnimator.animations.Length; i++)
31.             {
32.                 // requires that the mecanim stateName == animationName
33.                 if (stateInfo.IsName(meshAnimator.animations[i].animationName))
34.                 {
35.                     meshAnimator.Play(i);
36.                     meshAnimator.SetTimeNormalized(stateInfo.normalizedTime);
37.                     return;
38.                 }
39.             }
40.         }
41.     }
42. }
43.  

 

Hi, very infrequently (such that it seems impossible to replicate!) I get the following log error:

Code (csharp):

1. Mesh.vertices is too small. The supplied vertex array has less vertices than are referenced by the triangles array.
2. UnityEngine.Mesh:set_vertices(Vector3[])
3. FSG.MeshAnimator.MeshAnimator:UpdateTick(Single) (at Assets/MeshAnimator/Scripts/MeshAnimator.cs:537)
4. FSG.MeshAnimator.MeshAnimatorManager:Update() (at Assets/MeshAnimator/Scripts/MeshAnimatorManager.cs:52)

Should I worry about this in builds - i.e. will it become critical?

Thanks.

 

This should have been fixed in the latest version from the asset store. Are you using the latest one? (1.5.3 released Sept. 7th)

 

Hi, yes I'm using the latest version (just reimported again to be doubly sure) and still getting the error.

Is it a critical one?

Out of interest is there a version number stored in the asset somewhere to easily check which version the project is using?

 

Okay I will look and see if I can find another reason it might be happening then. There isn't a version # anywhere in the source at the moment. The error only occurs when a large amount of meshes are crossfading at the same time and thread synchronization fails. It's not a huge issue, but I'll try and find out what's causing it.

 

Thanks!

 

Hey does anyone know whether I can somehow make child gameobjects follow the animation or some sort of bone in the resulting animation?

 

Yes when baking, use the Exposed Transform section to leave child transforms intact after the bake. Then you can parent objects to them and they will follow the locations of the original bones during the animation.

 

Love the tool. We're using it for our crowd and it works great. However, we're getting corrupted meshes when running our game on the Nintendo Switch. Do you have any idea what would cause that? We've had no issues on the PlayStation or Xbox.

 

Hey @cpchristenson, I have had someone with this same issue on the Switch in the past, but we weren't able to come up with a fix. I believe Unity on the Switch does some funny thing with vertex ordering, which is messing it up. I acquired a Switch Dev Kit this week so I'll be able to look into the issue further for you.

 

Thank you so much! I've tried all kinds of stuff including every setting on the source mesh such as Optimize Mesh, Import BlendShapes, and Index Format. None fixed the issue.

We found a post on the Nintendo dev site that was potentially interesting, though probably not the same issue.

The quality setting of 'auto' for SkinnedMeshRenderer is different on Switch. It should be grabbing the BlendWeights value from QualitySettings, but on Switch, this isn't happening and is instead making 'auto' = 1 in all cases.
As a workaround, you need to set the quality settings manually

Here is the code they use to set the wiegth to 4, instead of using auto:

SkinnedMeshRenderer[] smrs = model.GetComponentsInChildren<SkinnedMeshRenderer>();
for (int i = 0; i < smrs.Length; ++i)
{
smrs.quality = SkinQuality.Bone4;
}
}​

Here is a bug report that Unity has since fixed:

https://fogbugz.unity3d.com/default.asp?1053442_llk9s8rpg4umpul1

 

Today I received a notification for MA 1.5.5. I tried to click the link to the upgrade page, and I discovered that mesh animator no longer appears to have pages accessible on the"old" asset store. You are on the new store, but absent from the old store. Just a FYI.