Sometimes I look at Unity and its incredible to see how they get to have thousands of skeletal meshes and instances navigating, pathfinding, flocking etc… running on perfectly smooth framerates, some even run on mobiole phones over 60 FPS!
Meanwhile in UE, I take my 30K poly character duplicate it 20 times and set a default simple point and click navmesh + pathfinding. The frame rate dies. just dies. It starts dying without any Navmesh or pathfinidng, it starts dying by simply having those 20 actors play a looping animation together.
And I’ve got an RTX card and an I7.
What gives? Is it a skeletal instancing problem? Is there something in the engine that is left out?
Thanks for the links, I did check some of them out but not these.
I suppose all this is not production ready. I also suppose we are asking something a bit more specific, I see a lot of actors I click.
But then again if one looks at strategy games from way back from 2003, you still get tons of units on screen at the same time, sometimes in the thousands (I know these are dedicated engines built gorund up to handle this).
I probably have brought up this subject before but i’ve seen unity also do many units on screen without DOTS but with some kind of an instancing you build into your actors Link.
It includes 1000 units, 3 types of different skeletal meshes and animation blending.
How is this running on mobile at 60 fps in Unity (The code is also made free). I can’t get half of that running on my PC
I never understood this, there are two things happening: Skeletal Instancing and a faster method of navmesh/pathfinding.
In UE4 like I mentioned above, I had some 30 basic characters (20K poly each 3 draw calls), I put navmesh and point and click for them to move, my fPS drops dramatically to impractical numbers with nothing else happening.
Is there something missing in UE4 that needs looking into. I heard Skeletal mesh instancing at the moment is not so good or non-existent? and that is one of the primary causes?
I don’t think there’s any skeletal mesh instancing. Only static meshes can be instanced as far as I know. If you have 30 characters drop your FPS then I’d expect it to be due to exponential increase of performance needs when it comes to collisions (30^30). Especially if they do not use any avoidance.
I can assure you that when you see Unity demos where they have thousands of moving characters, they are not actual skeletal meshes as in bone-driven deformations. They are most likely static meshes with vertex cache animation. Unreal can do that too, of course. I wanted to send you a video of it but @Solenism has already done it for me
That is a niagara based crowd system, it isn’t even skeletal mesh and has a very limited poly count.
No control over your crowds either. good for insects and swarms not good for anything more serious.
I am looking quality over quantity, I dont need 1 million units on screen with more than half of them billboards.
The Unity example I gave above was entirely skeletal mesh with animation tree running multiple animations and 3 different unique character meshes on mobile!
It really doesn’t matter. It’s using vertex animated textures, you don’t have to apply it to a niagara system. There’s a plugin on the marketplace that uses this with AI agents. The idea primary idea is to use VAT for actors further from the player and them switch to full skeletal meshes when they get close, this is how pretty much every game does huge crowds afaik.
For higher vertex counts there’s an alternative script included with the engine for 3DS Max for static mesh skeletal animation which you can see in action here.
I’m sorry that is NOT how every game does it. Why do you assume a game is a first person shooter or a Fortnite, what if my game is a strategy game how will you LOD then?
Also vertex animation doesn’t cut it not in the least bit. Just look at those hideous animations you think thats passable? sorry.
Animation sharing also only works if you have Swarm all working identical animations what if you want various clever looking corwd movements?
I gave everybody a simple and straight forward working example in Unity and all I heard back so far are excuses of half @ssed solutions in UE4. Come on guys.
I mean… that’s what is happening in your video… First LOD is 3500 triangles, the last is 500, it LODs aggressively as the camera distance increases.
Meanwhile, you’re using a 30k poly skeletal mesh with no mention of LODs at all. If that’s what you’re working with for a strategy game then you’re already on the wrong path and it doesn’t matter what engine you use.
Animation sharing also only works if you have Swarm all working identical animations what if you want various clever looking corwd movements?
Not necessarily, the original example that they provided had a horde of zombies chasing the player but I can’t be bothered to find it. Certainly not for this.
there’s just no chance of pulling off strategy game if you are not willing to invest into creative solutions and just expect the engine to give you some “RTS Toolkit” tailored for you. When it comes to RTS games of past two decades, vast majority of those that put a lot of deforming units on the screen at once uses vertex animation on static mesh instances. Exactly what that Niagara video shows. They probably don’t use particle system to actually drive their positions, but rendering wise, that’s what’s happening.
The unity video uses GPU skinning, which UE4 offers too. There’s also no implication anywhere in the video that DOTS is being used.
Anyway, if you dropped those 30k poly characters (10x more polygons than the LOD0 in that video) which most likely had a lot more unique bones, and your framerate died, did you at the very least open the profile to see where the bottleneck is?
Also, generally the LOD idea can be generalized to animations: Nearby characters receive detailed animations, whereas more distant characters can get a away with simpler animations. So, you might use skeletal animation for nearby characters, but vertex deformation for more distant characters.
Yes, this is probably not easy to implement, but that is also why there are so few (if any?) games which have large, yet detailed crowds.
I’ll go back to the drawing board and figure it out, i’m not one for dragging this into the abyss.
One last thought, the bottleneck in my tests was not the animations or the complexity of the mesh, the bottleneck was moving character actor and duplicates of said actor running on navmesh with AI and collision.
Also has to do with skeletal instances and how they are managed by the engine, also the need to build a new custom actor class from C++ without the dozen extra features of the character class which can prove to be heavy with all the extra unused features in many enemy or pawn units.
For comparison here is 300x skeletal meshes, each running a behavior tree that picks a random spot on the nav mesh and runs to it, stops a few seconds, then repeats.
