📌 Just wanted to add some additional relevant information here - This test was done with a character from a low poly Synty pack, the mesh has about 10k vertices and 5k triangles (kindof a lot for "low poly" lol). Also, after posting this video I did remove some things from the character's material (shadows, normal map, spec highlights, environment reflections) and got draw calls all the way down to just 68 even in wide camera mode. This did allow me to spawn a few hundred more static entities, but in my preliminary testing it doesn't seem to change the results of the close camera tests or other animation solutions. I'll keep playing around with it and post a supplementary video if I have any major performance breakthroughs through some more or less simple configuration options. Please do let me know if you have any suggestions on how to improve!
@@PotatoManager420 This model is available through one of the Synty asset packs. It is one of their more expensive packs but it does go on sale from time to time - assetstore.unity.com/packages/3d/environments/sci-fi/polygon-sci-fi-worlds-low-poly-3d-art-by-synty-206299?aid=1101l9vRP
Bruh I knew that after watching the vid and reading the comments on blackthorns channel someone was gonna come to turbos most recent vid and say something about it, LMAO. (Altho I do completely agree with you tho, he did ruin it)
As Rukhanka developer I need to explain poor Rukhanka results here. Rukhanka is a pure animation library. It evaluates animations, places bone entity objects in correct positions, and prepares skin matrices for EntitiesGraphics. All skinned mesh rendering is done via the built-in deformation mesh renderer feature of EntitiesGraphics. If you carefully look at the tables you will notice that there is almost no difference between the "Static Entities" and "Rukhanka Animations" fields. So both fields show just poor EntitiesGraphics skinned mesh rendering capabilities (no frustum, occlusion culling, poor batching, etc.) Rukhanka's animation code has a negligible impact on the final results. My raw animation performance tests show that Rukhanka v1.3.1 (current version) is three times faster than Mecanim (you can find "Stress Test" sample scene in Rukhanka samples package, which have animated prefab without skinned mesh renderers) and four to five times faster in upcoming v1.4.0 I understand that overall performance is what the customers looking for, so own Rukhanka's optimized skinned mesh renderer is on short todo list.
Thanks for the deeper context here. Though it is a bit unfortunate that many people will just look at the performance metrics without the additional context. I did try to note in the video some of the correlations you mentioned, but I apologize if this video made you feel like you needed to defend your asset. Glad to know you're working on getting around some of the limitations of the Entities Graphics package and would really like to do an updated comparison when appropriate. I still really love the Rukhanka asset and would recommend using it for an easy to use and feature rich animation solution. All the best!!
I was going to post, but saw that you responded. Glad to see your involvement here, and I'm happy with my purchase knowing that you're doing the constant updates. Note to others that yes it is still "worth" it as this lets you use ECS to remove any processing overhead of logic/math, and be able to easily use animations as per your standard game objects. That's the real performance gains right there.
@BakinKoljac he was invited to a game dev on blackthornprod's channel. when it was his turn to work on the game, he removed every fun mechanic the previous developers created and then branded the game with his logo
Well you seem like a nice enough guy. I think everybodies mad you saw linear in map design but made the mechanics as linear as possible and claimed it was improved 🤢Claimed it was boring then made it boring and put that cliché helmet that’s coincidentally your logo in. At least you were brave enough to add a point to the game albeit at the expense of the game. Whoops. Anyway. Although I enjoy the comments massively and find your misplaced confidence comical as hell I hope you don’t let it get you down and keep up the har- uh. Keep up the work.
I don't wanna sound mean but you litteraly added nothing in the challenge you litteraly just removed core features of a fast paced shooter game thinking it was slow and stale, and just added your logo and called it a day. You could have just build upon the game that was already there but you removed the core feature where past game devs worked on for hours just for you to remove it.
Brother you are really talented when it comes to the technical side of game development, but i don't know what you were doing in that blackthornpods video. idk you live and learn, but you must admit that you made some weird choices.
That’s exactly the kind of benchmarks I was looking for like 2 days ago ! And it’s even better that what i was imagining ! Thank you for your great work
I also think that thoose technologies are most likely still WIP and maybe in 6 months or so i would be interested to see if any improvements were made. There are also some animationsfeatures that aren’t available on ECS solutions at the moment, like IK, but when they are, it would be interesting to compare against unity default mecanim
Another benchmark that I would really be interested to see is dots netcode against other networking solution like NGO / mirror / fishnet, and how many moving entities can be replicated by each of theese
@@vecto8695 OH! hes just a guy alr that changes my mind, shoulda told me. Like what is that argument? He removed the fun and slapped his logo in the game stfu
@@TurboMakesGames I made a little fractal generator in ECS last week (in part thanks to your detailed tutorial). It was super fun, it feels like there's so much potential with the tech!
Hi, how do you to optimize vfx ? For exmeple 100 players playing 100 vfx make my game laggy on mobile even with 10 particles for each player, the problem is 100 vfx component
Optimizing VFX is going to be the same for regular GameObjects as it would be for ECS - in general you can use things like LODs and culling to reduce the amount of vertices and particles needed to render in the view. A lot of this is going to be very specific to your project though, so I'd suggest to do some more in-depth profiling to figure out the main draws of performance and doing some research into ways to optimize those things. Hope that helps get you going in the right direction!
Great video thanks! I would definately love to see more tests like that. I've been doing my own perf tests with ECS but I often wonder if it's my inexperience with ECS causing problems so it's great to see someone else's results
Pretty good results. Not sure when I would have over 1000 animated entities, on the screen all at the same time, so this is good enough for me. Wonder what Unity is cooking up for their own solution.
i think you should do more of these performance breakdowns, but no excel sheets, put like a simple colorful scene in the background of something happening, blur it out, have the tables on top built from the ui toolkit and give us some nice easing on some graphs that generate in real time for the visual learners in the crowd. thats my $0.02
@@TurboMakesGames@Tarodev has done some performance testing while keeping it graphically very interesting, I think taking a bit of inspiration from Sebastian Lague who always does amazing visuals.
damn not a lot of people happy about you removing wall dashing in blackthornpods video. Its not a big deal but maybe you should reply to some of the comments on that video... thanks
Because he didnt really do anything, all he did was add his own logo as an objective and removed a bunch of movement mechanics due to it being overwhelming. Did the least out of all the devs and allowed another dev to blame himself for the movement issues.
Thank You for making this video,... 💯👍🏻 these Benchmarks are indeed very useful for estimation and Planning the Performance for our games, using DOTS / ECS. Very interesting.
Wow, I'm a bit underwhelmed by these results. Thought about changing my game to ECS, but if these results are accurate, it would not matter at all. Are you sure you enabled GPU instancing on the material and that the characters do not contain any sub meshes, etc? Something seems a bit off here.
Yeah, it just confirms that ECS doesn't really do much in terms of render performance. Checked the pinned comment I just posted for some additional context. Right now skinned mesh renderers don't have full feature parity in entities graphics and likely won't until Unity's native ECS animation solution
Awesome video! Something is going on with the frustum culling in the entities.graphics package. It should be culling entities outside of the camera field of view. Because it's not culling, your narrow FOV numbers are way lower than they should be. For the game object renderer, frustum culling is clearly working fine. I know I have frustum culling with entities working fine in a couple of my projects. I will try to figure out which setting is needed to make it work. Question - how many vertices does the model have? I'm sure it's a huge number. Like you said, if you reduced the poly count of the model, then those wide FOV numbers would improve drastically. On my crappy laptop with a 600 vertex mesh I'll get 100k entities running with a wide FOV even without LODs. The graphics cards just can't handle all those triangles without something like Nanite.
Glad you liked the video!! Yeah not sure what was up with the entities culling - these tests were all ran with an orthographic camera and I just changed over to a perspective camera to test the results, but I was still seeing pretty much the same results. The model is one of the Synty Low-Poly characters, but each one still has about 10k verts and 5k tris. Kindof a lot for low-poly lol
Not sure if you were using the Burst Occlusion Culling which seems to be an experimental feature of entities graphics - just tried setting it up with a few different configurations and it doesn't seem to be making a difference there either (I very well could be using it incorrectly though)
@@TurboMakesGames No I definitely didn't enable the burst occulusion culling because it's still too experimental. The camera has "occlusion culling" enabled on it by default, but I don't think it does anything without ENABLE_UNITY_OCCLUSION enabled. According to the documentation, frustum culling is supposed to be enabled by default. I will send you screenshots of some of my components in your discord. I just tested and I am 100% sure that frustum culling is working with my setup - 100,000 static entities, 140fps zoomed in, 9fps zoomed out.
QUICK SUMMARY of what we learned: The "stationary" entity used in the video is a game object that has an armature (lots of game object children representing bones) and a SkinnedMeshRenderer component. It turns out that when SkinnedMeshRenders are converted to DOTS entities they are super slow compared to game-objects and don't support frustum culling. Spawning too many entities will use a lot of memory and crash Unity. Search for "Mesh deformations" in the Entities Graphics package to learn more about the limitations.
Drawcalls are too high to give accurate results. Your gpu is drawing each skinned mesh one at a time when it could be doing them all in parallel. This would make you gpu bound in every scenario.
@@garryguan7115 Sounds good, I'll keep playing around with things and post an update if I find any significant changes. I was able to remove some things from the default Synty material and now draw calls were down to only 68 in wide camera mode. I was able to spawn a few hundred more static entities in wide camera mode, but in my preliminary testing the other animation solutions and close camera mode are still pretty much the same even with the greatly reduced number of draw calls.
@@TurboMakesGames I would also merge them. Meshbaker on the asset store has this functionality I believe. Kinda dumb that unity doesnt tbh. Love you Unity
Yeah I think in terms of performance: vertex position texture baking > bone texture baking (GPU ECS Animation) > pure ECS animation (Rukhanka). In terms of features and flexibility, it's the exact opposite.
The results for the Hybrid Entities would basically match the performance for pure GameObjects as they really are just GameObjects doing the animations at the end of the day. The only place you might see a difference is with the moving tests if each GameObject had their own MonoBehaviour moving it in a circle, may be an interesting idea to whip up a little test for it though 🤔
Certainly! My guess is that it would be closer to the Steam Deck results, but feel free to download the test and run it on your device to see how it goes! johnnyturbo.itch.io/animation-perf-test
I did more tests and It seems that performance varies depending on the number of vertices. It appears that for GameObjects, performance tends to be better when there are more vertices, while for Entities, performance seems to be better when there are fewer vertices.
There are clearly some issue with your configurations, entities are not being culled and absolutely no batching is being performed and you have extremely high draw calls per entity (41k draw calls for ~1500 entities?)
Yeah not sure what was going on with the culling, these tests were done with an orthographic camera, but it looks like I'm getting pretty much the same results with a perspective camera. Can skinned meshes be batched like that? The materials did have GPU instancing enabled, but I don't think it is actually doing anything on the skinned meshes.
I wasn't clear on if you're using skinned meshes for the "static" objects. Even if no batching, your draw calls at way too high. 21,488 draw calls for 1,300 entities is 16 draw calls per entity. Given that your entity is basically a basic crash test dummy you should have no more than like 4 draw calls per unit at worst. Sometimes it's hard to say what is triggering additional draw calls. It could be the shader used, it could be that you are using forward rendering with multiple lights hitting a mesh. Shadow casting. Receiving shadows. I definitely think some playing around is required as this information isn't always freely given.
@@Zuriki09 Cool thanks for the additional info, yes even the "static" objects are still using skinned meshes. I did remove some unneeded things from the default Synty material I was using and got my draw calls all the way down to 68 even in wide camera mode. Looks like I was able to spawn a few hundred more static entities, but in my preliminary testing so far the results for the other animation options and close camera tests seem to be just about the same even with the greatly reduced number of draw calls. Will keep playing around and post an update if I find anything significant
I'm no expert on batching, but as far as I know, skinned meshes cannot be batched. However: The GPU-animation baker and also the rukanka(?) system are baking the animation into textures, right? So this should eliminate the need for skinned mesh renderers. That said, the resulting characters should be able to be batched and drastically reducing draw calls - but only if they don't have multiple materials or mutliple child meshes. Another possibility is vertex count. As the baked texture must contain every position of every vertex for every frame, the resulting textures will be quite large and might be a bottleneck for the GPU.
@@dreamterrormaster The Rukhanka one does not back animations to textures and it still uses skinned mesh renderers. It turns out that skinned mesh renderers in ECS is experimental and runs super slow - worse than game objects, and it doesn't support frustum culling. And you're right, vertex count is super high per model, which is why all the techniques choke when zoomed all the way out.
I am really surprised the static entity close camera result, wow! Actually I never used static entity and I don't know exactly what it is... (Maybe static GameObject is baked in subscnen?) then it would be better to compare with entity just stationary, too But that's just my opinion. This video is really really greatly helpful. Thank you.
sadly I bought those two ecs animation asset from store weeks ago So if this video was uploaded on start at sales, then I would use the link of yours..... I hope you to upload video associated assets from store on sales time to promote people like me to buy then (Also it's just another my opinion. and I acknowledge that's too hard work) But with my limitation of time, I just choosed to use only ecs gpu baker for now. And after watch this video I think I will use the other one for specific situation.
Yes, I realize my use of the term "static" is a bit misleading. All I meant by it is that the entity/GameObject is still a skinned mesh renderer, but it just does not have the animation components associated with it so it just stays in a static T-pose. In doing some research with people in the Discord after the fact, we confirmed a bunch of limitations with skinned mesh renderers in the Entities Graphics package which is why the numbers are comparatively low. And yeah I originally intended to have this video go live a few days prior when the summer sale was still active as a final reminder, but the video ended up taking a bit longer than I expected. I do my best to keep people informed when relevant DOTS assets do go on sale though!!
Thanks for the research, those are interesting results, hands down. For now it looks like GPU ECS is the best choice but it's not optimized for AMD gpus according to results and it affects scaling really hard. It would be interesting to see a test results for AMD desktop gpu to see if this problem is integrated gpu only or not. Rukhanka looks like a waste of money. But it's impossible to say anything about implementation without access to source code. So we can't say it's implementation problem or ECS itself.
I don't necessarily agree with your conclusion that the GPU ECS asset isn't optimized for AMD GPUs, there still are some other factors to consider on the rendering side and why the Steam Deck numbers are the way they are. Rukhanka is a really great asset though, it is incredibly easy to use and it supports some features that the GPU ECS asset doesn't. In terms of raw performance right now, yes it is the lowest, but it is limited by the entities graphics package. I know the developer has some concrete plans to update the asset to get around some of these limitations and I'll likely put up an update when that time comes. Thanks for watching and glad you found the video informative!
These results are quite interesting. I own GPU ECS Animations but have not used it yet. I also own GPU Instancer - Crowd Animations which is similar and it could happily render about 15+k animated characters all visible on screen. And my system specs are lower than your own. It did make heavy use of LoDs so that may have had a big impact. But I honestly expected better from an asset using ECS. Apologies if already mentioned, but were you using LoDs? If not, I wouldn't mind see how well it performs with it.
Nope, I'm not using LODs at all in this perf test - the character mesh is about 10k verts and 5k tris. Think I may do a little weekend experiment with some lower poly models and see how the results continue to scale. Turns out in doing a bit of research after the fact, there are still a bunch of limitations on skinned mesh renderers in the Entities Graphics package, which is why the results are lower than one may think. Likely won't see that change on Unity's side until their native animation solution
This leaves me perplexed. I was just finally learning ECS with its promised ability to do incredible things…with about the same or worse performance than GameObjects? Obviously, vertex offset shaders being the exception, but then you didn’t actually test GameObjects using vertex offset shaders for a comparison. What’s the convincing argument for switching to ECS if it doesn’t improve performance?
The intention of this test was to compare the performance between different animations systems, but the results ended up showing that rendering performance is the main bottleneck in all these tests. The main advantages of ECS come from the CPU and memory optimizations it offers, and not GPU performance. For these tests specifically, I'm not really doing anything particularly taxing in terms of CPU and memory, so that is why you can't see the performance gains from ECS. However, if we were to start having all these entities perform more complex work i.e. pathfinding or running some multi-step AI logic, ECS would outperform their GameObject counterparts. Hope that gives a little more context to these tests, feel free to stop by our Discord if you have any other questions about things! tmg.dev/Discord
I want go use ECS so bad, but: 1. My project is already very far ahead. 2. A lot of things that I normally use don’t support ECS 3. The current GameObject approach makes it easier to add, remove and edit components without having to jump back into the code. 4. There is a better chance to hire someone who can work with GameObjects than ECS. I hope Unity make ECS a lot easier to use in the future, and I heard that Unity is working to add animation for ECS
ECS is shitty and everything ECS can do Compute Shaders can do better. Especially compared to writing it from scratch with C++ or even Assembly ECS is slow as f. Just use Jobs or if your GPU is dying already then try to factor out ECS parts.
I was using a parallel IJobEntity to move an entity in a circle, then there is a separate system to sync the GameObjects' positions with their associated entities
@@TurboMakesGames is that second system multi threaded? I guess it's not? I would love to see the same tests but iJobParallelForTransform vs pure entity transform.
Mainly because ECS and GameObjects use the same render pipelines and ECS just gives you optimizations for CPU and Memory performance, not GPU. The reason the GPU asset is better is because it fundamentally changes how data is sent to and processed by the GPU. Where you start to see the major difference between ECS and GameObjects is when you start to do actual work across large numbers of entities - i.e. pathfinding or complex AI calculations.
Hi there. I heard that you are working hard on learning and maybe making a tutorial about Netcode for entity. I m super exited cuz i m trying to learn this stuff myself and there are some stuff i dont rly understand. I knwo this is no easy stuff. If you say at your level of DOTS that you will need 6 months to give us a feedback on your learning adventure than it must be hard as F....k. I m currently trying to dive in the Car Racing sample but i dont rly know where all this start to follow allong the code création.
Hello! Yes indeed I am working on a big Netcode for Entities tutorial. Just to be clear... I haven't been learning netcode for entities over the past 6 months, I've just been procrastinating making the tutorial for it 😂😂 Though as I've been diving over the past few weeks, there are definitely a lot of unique quirks that you need to consider. Also, if you haven't already, I'd recommend checking out the base netcode samples (part of the ECS samples GitHub repo) as those are a bit simpler as each of them focuses on individual concepts of netcode. All the best!
I was really hoping when I came to his videos that people won’t be here shitting on him, like yes we all agree it wasn’t a good idea to remove the cool movement but THIS ISN’T THE PASS IT ON VIDEO keep those comments in the relating video
Well shit, i'm sorry for you for getting so much hate. You're only human so mistakes are always to be made. But damn, this hits hard. The internet is brutal. Try looking forward and doing better next time!
Hey Turbo, you are an awsome game dev. I feel like you had a misunderstanding from your last dev challenge, but don't let the comment bullies get to you. It happens. Keep up the good work
There’s a difference between misunderstanding and shameless plugging and removing the components that made the game fun. He’s gonna have to do a lot to clear his name😂
Sheesh... seeing the comments section reminds me of why I choose not to participate in TH-cam or any social media platforms. Making mistakes is a natural part of being human, and the best approach is to offer people the opportunity to learn and grow from their errors. However, it's the internet; it seems that most people are less interested in fostering this growth and instead opt for negativity and hate. Allowing individuals the room to make mistakes is a crucial aspect of personal development in life. Personally, I miss your content and am looking forward to your next upload! There's simply not enough ECS content out there. Much love!
Yeah I definitely don't resonate with that kind of reaction, especially on a silly and fun video like that one. Appreciate the support - been working on a big Netcode for Entities tutorial that I'm super excited about! Hopefully will have a preview of it up early next week 😀
@@TurboMakesGames As a youtube game dev you should know that games and videos are work, dont you think the hate you are getting is because you refuse to acknowledge what you did? you can downplay it and call it silly all you want but being greedy and stepping over other devs work is not a quick simple mistake. if you were actually interested in having a healthy exchange with other devs you would have apologised already...
📌 Just wanted to add some additional relevant information here - This test was done with a character from a low poly Synty pack, the mesh has about 10k vertices and 5k triangles (kindof a lot for "low poly" lol). Also, after posting this video I did remove some things from the character's material (shadows, normal map, spec highlights, environment reflections) and got draw calls all the way down to just 68 even in wide camera mode. This did allow me to spawn a few hundred more static entities, but in my preliminary testing it doesn't seem to change the results of the close camera tests or other animation solutions. I'll keep playing around with it and post a supplementary video if I have any major performance breakthroughs through some more or less simple configuration options. Please do let me know if you have any suggestions on how to improve!
Hi, can you please link the asset model you used in this test?
@@PotatoManager420 This model is available through one of the Synty asset packs. It is one of their more expensive packs but it does go on sale from time to time - assetstore.unity.com/packages/3d/environments/sci-fi/polygon-sci-fi-worlds-low-poly-3d-art-by-synty-206299?aid=1101l9vRP
Blud you can’t remove core game elements then stick your logo there and dip how did you not expect this
bro why did you remove most of the fun game mechanics bruh (im talking about the pass it on game challenge)
Fr bro ruined it
Bruh I knew that after watching the vid and reading the comments on blackthorns channel someone was gonna come to turbos most recent vid and say something about it, LMAO. (Altho I do completely agree with you tho, he did ruin it)
bro is the kid that pauses the game in tag before he gets tagged
As Rukhanka developer I need to explain poor Rukhanka results here. Rukhanka is a pure animation library. It evaluates animations, places bone entity objects in correct positions, and prepares skin matrices for EntitiesGraphics. All skinned mesh rendering is done via the built-in deformation mesh renderer feature of EntitiesGraphics. If you carefully look at the tables you will notice that there is almost no difference between the "Static Entities" and "Rukhanka Animations" fields. So both fields show just poor EntitiesGraphics skinned mesh rendering capabilities (no frustum, occlusion culling, poor batching, etc.) Rukhanka's animation code has a negligible impact on the final results. My raw animation performance tests show that Rukhanka v1.3.1 (current version) is three times faster than Mecanim (you can find "Stress Test" sample scene in Rukhanka samples package, which have animated prefab without skinned mesh renderers) and four to five times faster in upcoming v1.4.0
I understand that overall performance is what the customers looking for, so own Rukhanka's optimized skinned mesh renderer is on short todo list.
Thanks for the deeper context here. Though it is a bit unfortunate that many people will just look at the performance metrics without the additional context. I did try to note in the video some of the correlations you mentioned, but I apologize if this video made you feel like you needed to defend your asset. Glad to know you're working on getting around some of the limitations of the Entities Graphics package and would really like to do an updated comparison when appropriate. I still really love the Rukhanka asset and would recommend using it for an easy to use and feature rich animation solution. All the best!!
I was going to post, but saw that you responded. Glad to see your involvement here, and I'm happy with my purchase knowing that you're doing the constant updates.
Note to others that yes it is still "worth" it as this lets you use ECS to remove any processing overhead of logic/math, and be able to easily use animations as per your standard game objects. That's the real performance gains right there.
Thank you for support,@@rcdemoral1982. Yes there are "hidden" performance benefits when one start attach game logic to the animated characters.
Thanks, pls keep us posted on your updates. Also a video showing some stress tests and numbers would be nice.
Hollup let me delete all this and make it boring real quick
he fr ruined it. and then shamelessly plugged his brand into the game
I really hope he takes all of the backlash as constructive criticism… that whole section was a tragedy
what happened?
@BakinKoljac he was invited to a game dev on blackthornprod's channel. when it was his turn to work on the game, he removed every fun mechanic the previous developers created and then branded the game with his logo
@@i12p exactly
Well you seem like a nice enough guy. I think everybodies mad you saw linear in map design but made the mechanics as linear as possible and claimed it was improved 🤢Claimed it was boring then made it boring and put that cliché helmet that’s coincidentally your logo in. At least you were brave enough to add a point to the game albeit at the expense of the game. Whoops. Anyway. Although I enjoy the comments massively and find your misplaced confidence comical as hell I hope you don’t let it get you down and keep up the har- uh. Keep up the work.
I don't wanna sound mean but you litteraly added nothing in the challenge you litteraly just removed core features of a fast paced shooter game thinking it was slow and stale, and just added your logo and called it a day.
You could have just build upon the game that was already there but you removed the core feature where past game devs worked on for hours just for you to remove it.
This game is way too overwhelming, I say delete half of it and add advertisements
Brother you are really talented when it comes to the technical side of game development, but i don't know what you were doing in that blackthornpods video. idk you live and learn, but you must admit that you made some weird choices.
all love tho
That’s exactly the kind of benchmarks I was looking for like 2 days ago ! And it’s even better that what i was imagining ! Thank you for your great work
Haha no kidding! Glad it was helpful 😊
I also think that thoose technologies are most likely still WIP and maybe in 6 months or so i would be interested to see if any improvements were made.
There are also some animationsfeatures that aren’t available on ECS solutions at the moment, like IK, but when they are, it would be interesting to compare against unity default mecanim
Another benchmark that I would really be interested to see is dots netcode against other networking solution like NGO / mirror / fishnet, and how many moving entities can be replicated by each of theese
Bro should be blacklisted from all future challenges
Dude chill he's just a guy
@@vecto8695 OH! hes just a guy alr that changes my mind, shoulda told me. Like what is that argument? He removed the fun and slapped his logo in the game stfu
I'm sure he already is
I really like your content. Not a lot of other great ECS videos out there right now.
Thank you so much for the kind words, I'm having a great time making these videos 😀
@@TurboMakesGames I made a little fractal generator in ECS last week (in part thanks to your detailed tutorial). It was super fun, it feels like there's so much potential with the tech!
Needs more logos
Maybe we delete everything to make it fun
Hi, how do you to optimize vfx ? For exmeple 100 players playing 100 vfx make my game laggy on mobile even with 10 particles for each player, the problem is 100 vfx component
Optimizing VFX is going to be the same for regular GameObjects as it would be for ECS - in general you can use things like LODs and culling to reduce the amount of vertices and particles needed to render in the view. A lot of this is going to be very specific to your project though, so I'd suggest to do some more in-depth profiling to figure out the main draws of performance and doing some research into ways to optimize those things. Hope that helps get you going in the right direction!
Great video thanks! I would definately love to see more tests like that.
I've been doing my own perf tests with ECS but I often wonder if it's my inexperience with ECS causing problems so it's great to see someone else's results
Awesome, glad to know you'd like to see some more of these!
Pretty good results. Not sure when I would have over 1000 animated entities, on the screen all at the same time, so this is good enough for me. Wonder what Unity is cooking up for their own solution.
Yeah it will be super interesting to see how Unity's animation solution stacks up too!
Erasing other people's work and making it boring
They better not let him be in any more challenges 😂
This channel should be called Turbo Ruins Games 😂
i think you should do more of these performance breakdowns, but no excel sheets, put like a simple colorful scene in the background of something happening, blur it out, have the tables on top built from the ui toolkit and give us some nice easing on some graphs that generate in real time for the visual learners in the crowd. thats my $0.02
Good to know you'd want to see more of these, and yes I agree that some prettier charts and graphs would help a bunch 😁
@@TurboMakesGames@Tarodev has done some performance testing while keeping it graphically very interesting, I think taking a bit of inspiration from Sebastian Lague who always does amazing visuals.
the ui is kinda overwhelming, you should remove it.
damn not a lot of people happy about you removing wall dashing in blackthornpods video. Its not a big deal but maybe you should reply to some of the comments on that video... thanks
Because he didnt really do anything, all he did was add his own logo as an objective and removed a bunch of movement mechanics due to it being overwhelming. Did the least out of all the devs and allowed another dev to blame himself for the movement issues.
Thank You for making this video,... 💯👍🏻 these Benchmarks are indeed very useful for estimation and Planning the Performance for our games, using DOTS / ECS.
Very interesting.
Glad they were helpful, thanks for watching!
Honestly really boring mechanics, try removing it and adding a different logo
Wow, I'm a bit underwhelmed by these results. Thought about changing my game to ECS, but if these results are accurate, it would not matter at all. Are you sure you enabled GPU instancing on the material and that the characters do not contain any sub meshes, etc? Something seems a bit off here.
Yeah, it just confirms that ECS doesn't really do much in terms of render performance. Checked the pinned comment I just posted for some additional context. Right now skinned mesh renderers don't have full feature parity in entities graphics and likely won't until Unity's native ECS animation solution
Awesome video! Something is going on with the frustum culling in the entities.graphics package. It should be culling entities outside of the camera field of view. Because it's not culling, your narrow FOV numbers are way lower than they should be. For the game object renderer, frustum culling is clearly working fine. I know I have frustum culling with entities working fine in a couple of my projects. I will try to figure out which setting is needed to make it work.
Question - how many vertices does the model have? I'm sure it's a huge number. Like you said, if you reduced the poly count of the model, then those wide FOV numbers would improve drastically. On my crappy laptop with a 600 vertex mesh I'll get 100k entities running with a wide FOV even without LODs. The graphics cards just can't handle all those triangles without something like Nanite.
Glad you liked the video!! Yeah not sure what was up with the entities culling - these tests were all ran with an orthographic camera and I just changed over to a perspective camera to test the results, but I was still seeing pretty much the same results.
The model is one of the Synty Low-Poly characters, but each one still has about 10k verts and 5k tris. Kindof a lot for low-poly lol
Not sure if you were using the Burst Occlusion Culling which seems to be an experimental feature of entities graphics - just tried setting it up with a few different configurations and it doesn't seem to be making a difference there either (I very well could be using it incorrectly though)
@@TurboMakesGames No I definitely didn't enable the burst occulusion culling because it's still too experimental. The camera has "occlusion culling" enabled on it by default, but I don't think it does anything without ENABLE_UNITY_OCCLUSION enabled. According to the documentation, frustum culling is supposed to be enabled by default. I will send you screenshots of some of my components in your discord. I just tested and I am 100% sure that frustum culling is working with my setup - 100,000 static entities, 140fps zoomed in, 9fps zoomed out.
QUICK SUMMARY of what we learned: The "stationary" entity used in the video is a game object that has an armature (lots of game object children representing bones) and a SkinnedMeshRenderer component. It turns out that when SkinnedMeshRenders are converted to DOTS entities they are super slow compared to game-objects and don't support frustum culling. Spawning too many entities will use a lot of memory and crash Unity. Search for "Mesh deformations" in the Entities Graphics package to learn more about the limitations.
Drawcalls are too high to give accurate results. Your gpu is drawing each skinned mesh one at a time when it could be doing them all in parallel. This would make you gpu bound in every scenario.
Correct, how can I do this for skinned meshes?
@@TurboMakesGames You merge the skinned meshes into batches of big skinned meshes.
@@garryguan7115 Sounds good, I'll keep playing around with things and post an update if I find any significant changes. I was able to remove some things from the default Synty material and now draw calls were down to only 68 in wide camera mode. I was able to spawn a few hundred more static entities in wide camera mode, but in my preliminary testing the other animation solutions and close camera mode are still pretty much the same even with the greatly reduced number of draw calls.
@@TurboMakesGames I would also merge them. Meshbaker on the asset store has this functionality I believe. Kinda dumb that unity doesnt tbh. Love you Unity
It turns out animation can be baked
Yes that is what the GPU animation solution does and it works great!
Thx for the video. I think in terms of performance nothing can beat vertex position baking. But it has unfortunately a lot of other drawbacks.
True indeed!!
Perhaps best of both worlds would be ECS animations for quality close-up and vertex position baking farther back
Yeah I think in terms of performance: vertex position texture baking > bone texture baking (GPU ECS Animation) > pure ECS animation (Rukhanka). In terms of features and flexibility, it's the exact opposite.
This data is really interesting, thanks! I'd love to see a comparison to pure gameobjects, but I guess that's quite a bit of work. Anyway, great job!
The results for the Hybrid Entities would basically match the performance for pure GameObjects as they really are just GameObjects doing the animations at the end of the day. The only place you might see a difference is with the moving tests if each GameObject had their own MonoBehaviour moving it in a circle, may be an interesting idea to whip up a little test for it though 🤔
Thanks for doing these tests, it's a huge help and timesaver, since you have basically informed my approach.
Absolutely, so glad to hear this one was helpful to you. Definitely would like to do more of these soon!
Very interesting test, and great work! Thanks.
GPU ECS IT IS.! great video. It will be nice to see the same comparison on an average laptop.
Certainly! My guess is that it would be closer to the Steam Deck results, but feel free to download the test and run it on your device to see how it goes! johnnyturbo.itch.io/animation-perf-test
I did more tests and It seems that performance varies depending on the number of vertices. It appears that for GameObjects, performance tends to be better when there are more vertices, while for Entities, performance seems to be better when there are fewer vertices.
Cool, thanks Johnny.
Sure thing 😀
There are clearly some issue with your configurations, entities are not being culled and absolutely no batching is being performed and you have extremely high draw calls per entity (41k draw calls for ~1500 entities?)
Yeah not sure what was going on with the culling, these tests were done with an orthographic camera, but it looks like I'm getting pretty much the same results with a perspective camera. Can skinned meshes be batched like that? The materials did have GPU instancing enabled, but I don't think it is actually doing anything on the skinned meshes.
I wasn't clear on if you're using skinned meshes for the "static" objects. Even if no batching, your draw calls at way too high.
21,488 draw calls for 1,300 entities is 16 draw calls per entity. Given that your entity is basically a basic crash test dummy you should have no more than like 4 draw calls per unit at worst.
Sometimes it's hard to say what is triggering additional draw calls. It could be the shader used, it could be that you are using forward rendering with multiple lights hitting a mesh. Shadow casting. Receiving shadows.
I definitely think some playing around is required as this information isn't always freely given.
@@Zuriki09 Cool thanks for the additional info, yes even the "static" objects are still using skinned meshes. I did remove some unneeded things from the default Synty material I was using and got my draw calls all the way down to 68 even in wide camera mode. Looks like I was able to spawn a few hundred more static entities, but in my preliminary testing so far the results for the other animation options and close camera tests seem to be just about the same even with the greatly reduced number of draw calls. Will keep playing around and post an update if I find anything significant
I'm no expert on batching, but as far as I know, skinned meshes cannot be batched. However: The GPU-animation baker and also the rukanka(?) system are baking the animation into textures, right? So this should eliminate the need for skinned mesh renderers. That said, the resulting characters should be able to be batched and drastically reducing draw calls - but only if they don't have multiple materials or mutliple child meshes.
Another possibility is vertex count. As the baked texture must contain every position of every vertex for every frame, the resulting textures will be quite large and might be a bottleneck for the GPU.
@@dreamterrormaster The Rukhanka one does not back animations to textures and it still uses skinned mesh renderers. It turns out that skinned mesh renderers in ECS is experimental and runs super slow - worse than game objects, and it doesn't support frustum culling. And you're right, vertex count is super high per model, which is why all the techniques choke when zoomed all the way out.
I am really surprised the static entity close camera result, wow!
Actually I never used static entity and I don't know exactly what it is... (Maybe static GameObject is baked in subscnen?) then it would be better to compare with entity just stationary, too
But that's just my opinion. This video is really really greatly helpful. Thank you.
sadly I bought those two ecs animation asset from store weeks ago
So if this video was uploaded on start at sales, then I would use the link of yours.....
I hope you to upload video associated assets from store on sales time to promote people like me to buy then
(Also it's just another my opinion. and I acknowledge that's too hard work)
But with my limitation of time, I just choosed to use only ecs gpu baker for now.
And after watch this video I think I will use the other one for specific situation.
Yes, I realize my use of the term "static" is a bit misleading. All I meant by it is that the entity/GameObject is still a skinned mesh renderer, but it just does not have the animation components associated with it so it just stays in a static T-pose. In doing some research with people in the Discord after the fact, we confirmed a bunch of limitations with skinned mesh renderers in the Entities Graphics package which is why the numbers are comparatively low. And yeah I originally intended to have this video go live a few days prior when the summer sale was still active as a final reminder, but the video ended up taking a bit longer than I expected. I do my best to keep people informed when relevant DOTS assets do go on sale though!!
@TurboMakesGames Thank you for explanation!
Thanks for the research, those are interesting results, hands down.
For now it looks like GPU ECS is the best choice but it's not optimized for AMD gpus according to results and it affects scaling really hard. It would be interesting to see a test results for AMD desktop gpu to see if this problem is integrated gpu only or not.
Rukhanka looks like a waste of money. But it's impossible to say anything about implementation without access to source code. So we can't say it's implementation problem or ECS itself.
I don't necessarily agree with your conclusion that the GPU ECS asset isn't optimized for AMD GPUs, there still are some other factors to consider on the rendering side and why the Steam Deck numbers are the way they are. Rukhanka is a really great asset though, it is incredibly easy to use and it supports some features that the GPU ECS asset doesn't. In terms of raw performance right now, yes it is the lowest, but it is limited by the entities graphics package. I know the developer has some concrete plans to update the asset to get around some of these limitations and I'll likely put up an update when that time comes. Thanks for watching and glad you found the video informative!
These results are quite interesting. I own GPU ECS Animations but have not used it yet. I also own GPU Instancer - Crowd Animations which is similar and it could happily render about 15+k animated characters all visible on screen. And my system specs are lower than your own. It did make heavy use of LoDs so that may have had a big impact. But I honestly expected better from an asset using ECS. Apologies if already mentioned, but were you using LoDs? If not, I wouldn't mind see how well it performs with it.
Nope, I'm not using LODs at all in this perf test - the character mesh is about 10k verts and 5k tris. Think I may do a little weekend experiment with some lower poly models and see how the results continue to scale. Turns out in doing a bit of research after the fact, there are still a bunch of limitations on skinned mesh renderers in the Entities Graphics package, which is why the results are lower than one may think. Likely won't see that change on Unity's side until their native animation solution
This leaves me perplexed. I was just finally learning ECS with its promised ability to do incredible things…with about the same or worse performance than GameObjects? Obviously, vertex offset shaders being the exception, but then you didn’t actually test GameObjects using vertex offset shaders for a comparison. What’s the convincing argument for switching to ECS if it doesn’t improve performance?
The intention of this test was to compare the performance between different animations systems, but the results ended up showing that rendering performance is the main bottleneck in all these tests. The main advantages of ECS come from the CPU and memory optimizations it offers, and not GPU performance. For these tests specifically, I'm not really doing anything particularly taxing in terms of CPU and memory, so that is why you can't see the performance gains from ECS. However, if we were to start having all these entities perform more complex work i.e. pathfinding or running some multi-step AI logic, ECS would outperform their GameObject counterparts. Hope that gives a little more context to these tests, feel free to stop by our Discord if you have any other questions about things! tmg.dev/Discord
I want go use ECS so bad, but:
1. My project is already very far ahead.
2. A lot of things that I normally use don’t support ECS
3. The current GameObject approach makes it easier to add, remove and edit components without having to jump back into the code.
4. There is a better chance to hire someone who can work with GameObjects than ECS.
I hope Unity make ECS a lot easier to use in the future, and I heard that Unity is working to add animation for ECS
ECS is shitty and everything ECS can do Compute Shaders can do better. Especially compared to writing it from scratch with C++ or even Assembly ECS is slow as f. Just use Jobs or if your GPU is dying already then try to factor out ECS parts.
great video thanks
Sure thing, glad you enjoyed 😀
Did you use IJobParallelForTransform for "static game object"? Or how do you move them?
I was using a parallel IJobEntity to move an entity in a circle, then there is a separate system to sync the GameObjects' positions with their associated entities
@@TurboMakesGames is that second system multi threaded? I guess it's not? I would love to see the same tests but iJobParallelForTransform vs pure entity transform.
Game is overwhelming, lets delete 70% of the game, its too boring now.. LETS SLAP SOME ADVERTISEMENT!
Hello, are you reading comments?
Have you ever thought of making an RPG making tutorial with DOTS?
Nice!
🙌🙌
Why are gameobjects holding their own against ECS??? (Aside from the GPU asset)
Mainly because ECS and GameObjects use the same render pipelines and ECS just gives you optimizations for CPU and Memory performance, not GPU. The reason the GPU asset is better is because it fundamentally changes how data is sent to and processed by the GPU. Where you start to see the major difference between ECS and GameObjects is when you start to do actual work across large numbers of entities - i.e. pathfinding or complex AI calculations.
Mhm, feels like my question from the last video was answered here. Feels like personalized content! :D Thanks for this!
Haha it was a fun little exercise to put these different solutions through their paces!!
Hi there. I heard that you are working hard on learning and maybe making a tutorial about Netcode for entity. I m super exited cuz i m trying to learn this stuff myself and there are some stuff i dont rly understand. I knwo this is no easy stuff. If you say at your level of DOTS that you will need 6 months to give us a feedback on your learning adventure than it must be hard as F....k. I m currently trying to dive in the Car Racing sample but i dont rly know where all this start to follow allong the code création.
Hello! Yes indeed I am working on a big Netcode for Entities tutorial. Just to be clear... I haven't been learning netcode for entities over the past 6 months, I've just been procrastinating making the tutorial for it 😂😂
Though as I've been diving over the past few weeks, there are definitely a lot of unique quirks that you need to consider. Also, if you haven't already, I'd recommend checking out the base netcode samples (part of the ECS samples GitHub repo) as those are a bit simpler as each of them focuses on individual concepts of netcode. All the best!
How did you study this whole thing? The contents are awesome
I learn best by doing and experimenting on my own! Digging into the docs and example/source code is very helpful too 😊
You are amazing keep going!
Thank you so much!
Youre bad at this
I was really hoping when I came to his videos that people won’t be here shitting on him, like yes we all agree it wasn’t a good idea to remove the cool movement but THIS ISN’T THE PASS IT ON VIDEO keep those comments in the relating video
can it handle george washingtons dumpy?
Another great video. I was wondering if you are ever going to do a netcode tutorial.
Too overwhelming. Delete half of it and add advertisments.
🤦
Oh boy let me tell you I was SHOCKED when I saw GPU ECS is only 50$. Like what?hell yeah take my money
Yeah that asset is such a bargain! Been very happy with it so far 😊
Well shit, i'm sorry for you for getting so much hate. You're only human so mistakes are always to be made. But damn, this hits hard. The internet is brutal. Try looking forward and doing better next time!
What? Dude shamelessly self promoted himself and ruined the entire game on thornprod. No defending that
ye the internets sooo "brutal" to a guy who removes half the mechanics and slaps his logo in the game and calls it a day. I really feel for him.
Hey Turbo, you are an awsome game dev. I feel like you had a misunderstanding from your last dev challenge, but don't let the comment bullies get to you. It happens. Keep up the good work
There’s a difference between misunderstanding and shameless plugging and removing the components that made the game fun. He’s gonna have to do a lot to clear his name😂
Sheesh... seeing the comments section reminds me of why I choose not to participate in TH-cam or any social media platforms.
Making mistakes is a natural part of being human, and the best approach is to offer people the opportunity to learn and grow from their errors.
However, it's the internet; it seems that most people are less interested in fostering this growth and instead opt for negativity and hate.
Allowing individuals the room to make mistakes is a crucial aspect of personal development in life.
Personally, I miss your content and am looking forward to your next upload! There's simply not enough ECS content out there. Much love!
Yeah I definitely don't resonate with that kind of reaction, especially on a silly and fun video like that one. Appreciate the support - been working on a big Netcode for Entities tutorial that I'm super excited about! Hopefully will have a preview of it up early next week 😀
@@TurboMakesGames As a youtube game dev you should know that games and videos are work, dont you think the hate you are getting is because you refuse to acknowledge what you did? you can downplay it and call it silly all you want but being greedy and stepping over other devs work is not a quick simple mistake. if you were actually interested in having a healthy exchange with other devs you would have apologised already...
Hey man good video! Also please don’t take the hate seriously it’s fine and mistakes happen keep going and tell me if your good.