Low Fps when adding AnimatedMeshSceneNode

[GabinMD]

Hello,

I'm creating a game on irrlicht and i have a lot of fps issues.
I'm using thread to generate the nodes.
When i create 4 players i can't get abrove 30 fps and it's worth when my player generate nodes.

for an example, each player use 5 animated node (run, attack, static, win, death) and those node a stored in a map.
to switch from a animation to an other i juste change the position vector of the node.
each player can generate Bombs, all of those bombs are delete after a certain time with the remove() function (node->remove())

can you help me?

[CuteAlien]

Maybe you have too many polygons?
You can also always use a profiler (for example verysleepy on Windows or gprof on Linux) to find out which parts are slowing down your application.

[GabinMD]

thanks for your answer

i used gprof but i don't understand the analysis file can you help me?
https://mega.nz/#!yc8jiAbT!R_QxSTzwqzeM ... q3WHXq6yxU

it's write that the map::getColision is the issue but i'm still lagging when the player generate node if i dont use the function

[CuteAlien]

The upper table is statistics over all functions. The cumulative seconds are pretty useless - ignore that. self seconds is the one that matters (or % time - should have the same ratio). And calls is interesting as that way you can often see that something is simply called far more often than you expect.

The infos later are functions sorted by the amount of time they are called. If I remember right the function with the index (like [1]) is always the function itself. And the other functions in the same group are those called inside that function. But you can probably find better documentation about it. And I'm not sure I'm correct as I would expect main() to show up first in that case - but maybe it's filtered out automatically.

So first table is about time of functions themself - second listing of functions is about time of functions + their sub-functions. So the table helps mostly to find a bottleneck while the lower half of info is about finding out where it's called from.

From those data I would guess - the Map::getColision inside your Player::setPosRot is the expensive one (or well - you seem to call it a lot 241406 times in 10 seconds - how many players do you have?).

But you should run the test longer - not just 10 seconds. Otherwise the parts of you application where you load models might distort the runtime parts.

If you don't call that function it shouldn't show up.

[GabinMD]

thanks for your answer.

When i said, when i don't use the function, i mean i did an other analysis on the program without using my expensive function (Map::GetColision and GetCommand) (look at the new link)

https://mega.nz/#!7EFz1BDB!u7LIxmf70mub ... cOtq0abeIU

in this file we can see that there is many calls to Bomb::timeDiff but i think that's not the probleme because if i launch the game without touching anything (then player can't generate bomb) i'm still under 30 fps..

[GabinMD]

I found the probleme but it's very strange.

In my game i stored 5 animation per player but the game can't support all those node and loses fps.
Is it possible to make a difference between the 3d model and the animation? i'm using B3D format
because when i try not to store the node and remove/create them on each action my program crashes.

[CuteAlien]

Sorry, not understanding your problem. And if you have a crash you should figure out what causes it.
It's possible to split animation and mesh, but that doesn't sound like something which should improve your framerate (still has to do the exact same animation calculations). So I don't think this is the solution here.

[GabinMD]

my program crash when i create and remove node,
all player are thread, but when i need to switch of an animation to an other, i remove the actual node and add the new animation to the same node
but when 2 player addNode in the same time the irrlicht drawAll crash, and i'm using mutex when i use addAnimatedMeshSceenNode
EDIT: even if only one is moving drawAll crash i realy don't understand

[CuteAlien]

Maybe don't use threads? Threads are not something that makes coding easier...

[MartinVee]

To add to CuteAlien, wouldn't you need a mecanism for thread synchronization when you check for collision if the information necessary for collision detection belongs to different threads? And if such a mecanism was implemented, wouldn't it add a significant amount of overhead for locking and for cache coherency?

I haven't seen your code, but for example, if you check collision on each frame using memory on different threads, it would then mean that the CPU would spend a lot of time flushing mutex memory from the cache. That may be where your bottleneck is. Having multiple threads can negatively impact the performance of an application, especially if lots of locking happen.

Additionally, take note that Irrlicht doesn't support multithread.