Yes i'll test without the bug. I'll also try bullet 2.79 and the newest version of their svn repo to see if they already fixed it.
Edit:
Here are the results of the new tests
Old Laptop:
1/50. | 91 | 11
1/30. | 98-102 | 11
1/20. | 102-105 | 11
1/10. | 107-111 | 11
Dekstop:
1/50. | 139 | 18-19
1/30. | 149 | 19
1/20. |149 | 19
1/10. | 150-151 | 19-20
The bug is still present in the svn and i couldn't find a bug report that looked like it could be for it.
Bullet Optimisation
Re: Bullet Optimisation
@gus: I noticed there is still an unmerged branch from you in OpenEngine. Should it be merged?
- lgromanowski
- Site Admin
- Posts: 1193
- Joined: 05 Aug 2011, 22:21
- Location: Wroclaw, Poland
- Contact:
Re: Bullet Optimisation
I'm not familiar with bullet code, but when I changed physic.cpp to:
I have 7 fps instead of 1 in Vivec (nVidia 9600 GT with 280.x drivers).
Callgrind shows that "void btAlignedObjectArray<btBroadphasePair>::quickSortInternal<btBroadphasePairSortPredicate>(btBroadphasePairSortPredicate, int, int)" was called very often.
Code: Select all
//TODO: memory leak?
btOverlappingPairCache* pairCache = new btHashedOverlappingPairCache();
//pairCache->setInternalGhostPairCallback( new btGhostPairCallback() );
Callgrind shows that "void btAlignedObjectArray<btBroadphasePair>::quickSortInternal<btBroadphasePairSortPredicate>(btBroadphasePairSortPredicate, int, int)" was called very often.
- Attachments
-
- callgrind.out.21123.bz2
- callgrind profile output
- (561.23 KiB) Downloaded 191 times
Re: Bullet Optimisation
Sorry for the late reply.
K1ll: your bench show that without the bullet bug, performances are the same if you simulate 50 or 10 time per second, so bullet impact is negligible on performances.
Zini: I will have a look at it.
lgromanowski: That's perfectly normal. When you remove the line you removed, there are only static objects in the scene, so there is no need to simulate anything. That's why perfs are so high.
But what you point out is interesting. It's the broadphase which take the most time, so doing batching the same way we do it with rendering might give a perf boost.
K1ll: your bench show that without the bullet bug, performances are the same if you simulate 50 or 10 time per second, so bullet impact is negligible on performances.
Zini: I will have a look at it.
lgromanowski: That's perfectly normal. When you remove the line you removed, there are only static objects in the scene, so there is no need to simulate anything. That's why perfs are so high.
But what you point out is interesting. It's the broadphase which take the most time, so doing batching the same way we do it with rendering might give a perf boost.
Re: Bullet Optimisation
Like i said in the End of Year Status 2011 thread:
Good news everyone!
It seems like this issue is finally solved in the bullet svn (it's still present in the 2.79 release thought). I couldn't reproduce it anymore with my laptop nor with my desktop on linux.
So please try out the latest revision of the bullet repository to verify that this is fixed for everyone.
And remember to recompile both libbullet and OpenMW otherwise you might run into problems!
Good news everyone!
It seems like this issue is finally solved in the bullet svn (it's still present in the 2.79 release thought). I couldn't reproduce it anymore with my laptop nor with my desktop on linux.
So please try out the latest revision of the bullet repository to verify that this is fixed for everyone.
And remember to recompile both libbullet and OpenMW otherwise you might run into problems!
Re: Bullet Optimisation
nice. although i'm not able to test anything today :/
Re: Bullet Optimisation
The 1fps bug is fixed in the svn version! Had to change a few things in the source to get it compiled but it finaly works...