In the case of humanoids, any more humanoids will cause more fast clusters to be made and delegated, so any more humanoids will always be bad on performance. NPCs that are no longer in the client’s DataModel will be moved out of memory, so moving to different places will not cause any issues as far as I know.
Sharks, maybe? They take damage like a player does, so I’d be willing to bet they use Humanoids
1 Like
Is there any way to remedy this while still having the crews and the town npcs, or does it just have to be one or the other?
1 Like
Sharks probably do use humanoids, that is a good one!
One or the other. There are ways you can try to optimize, but they will probably be futile. You will have to wait until more optimizations come into the Roblox Engine directly to notice change without action.
Guess I’d rather live with meh performance then cause I really like the crews and town npcs. If sharks are humanoids I guess the same would go for other sea monsters? Also depending on how much can be done with solution number 2 could it possibly make up for the humanoid stuff, does it just not work like that, or is the humanoid problem that bad?
Vetex did say this in the last optimization post
which if this works as it should I don’t know why humanoids still cause so much lag
It can definitely make up for the humanoid stuff. I do want to make this clear though, there are ways to keep the NPCs but improve performance. AnimationControllers, disabling unused properties, etc… In this scenario, lowering geometry of the humanoids can help too or removing unused instances under these NPCs. I would like to say, simple sea monsters like sharks would not need a humanoid and can be added in with a custom script.
I have no idea how the unloading system works, but I never noticed any sort of substantially performance increase after it was implemented. It is possible the way he made it unload is flawed, like keeping the humanoid somewhere in the DOM which will still make it be apart of fast clusters.
i won’t pretend to fully understand this but i’ve always wanted to go through and analyze this sort of stuff in game, and you break down a lot of the elements really well, good stuff
1 Like
I don’t get it but keep doing what you’re doing pal
We especially see that the one on the bottom seems extremely long and consists of two parts: prepare and perform. Ideally, we would want our prepare time to be as small as possible, but why is that? That is because the prepare thread yields EVERYTHING from continuing until it is over, which is not ideal to have high if we want good FPS.
was this after a specific action, more noticeable after a specific action, or just something that happened consistently? For example, was it on spawn? Death? Skill use? Destruction?
why are non-humanoid objects getting classified as humanoids
No, this represents the average amount of time on a large set of frames. Actions would have zero to none affect on the render thread.
If someone puts a humanoid under a non-humanoid object, then it will be considered a humanoid and then fast clustered. I do not think this is the problem in Arcane Odyssey’s case though.
So this has nothing to do with frame drops then unless it’s excessively long prepare times, it just explains a generally low average fps.
Exactly. The prepare times seem to be consistent no matter what situation you are in for the most part. I’ll try to find reasons for frame drops too, but in general the consistently low FPS is because of these prepare times.
I’m curious what would it look like if you ran this test in World of Magic?
That game had a ton of overworld NPCs and yet it seems to run a whole lot better (except when someone blows up the silent tower)
1 Like
I’ll give it a go.
So, I don’t want to go too in-depth, but it seems that WoM actually doesn’t have this performance problem with humanoids. In fact, I don’t see the “updateInvalidatedFastClusters” thread in WoM at all.