Re: Bullet performance on Android - Determinism problem

ratamovic
Posts: 6
Joined: Mon Aug 23, 2010 7:18 pm

Re: Bullet performance on Android - Determinism problem

Post by ratamovic »

Hi all,

I am new to bullet and I would like to have some input on its performance on Android.
I have some concerns because I tried Bullet with a small application (basically a square of more than 150 cubes of 1x1unit separated by 1unit + 2 falling cubes) and I found the result are a bit disappointing (slow FPS). Maybe I am a bit too demanding. The weird thing is that the two box fall is slow but once they touch other boxes on the ground, it gets faster (maybe 10/12fps). This is not a graphic related issue (that part seems to run fast). Am using an HTC Desire.

You can find the sample APK here: http://www.mediafire.com/?m7xt20wc44cc5h0 and the resources files here http://www.mediafire.com/?8p2j59atw3765cq (to put in /sdcard/carinae/data/etc.)
The screenshot is a bit weird on the right because it's composed of two images (screen capture is a bit rubbish on Android :shock:)
Image

The code is basically the following (sorry for that messy extract, this is just was just a small test):

My PhysicsService:

Code: Select all

	PhysicsServiceWrapper::PhysicsServiceWrapper():
		mCollisionConfiguration(new btDefaultCollisionConfiguration()),
		mDispatcher(new btCollisionDispatcher(mCollisionConfiguration)),
		mBroadPhaseInterface(new btDbvtBroadphase()),
		mConstraintSolver(new btSequentialImpulseConstraintSolver())
	{
	}

    PhysicsServiceWrapper::~PhysicsServiceWrapper()
	{
		delete mConstraintSolver;
		delete mBroadPhaseInterface;
		delete mDispatcher;
		delete mCollisionConfiguration;
	}


    PhysicsService::PhysicsService(TimeService& pTimeService):
		PhysicsServiceWrapper(),
        Service(),
        btDiscreteDynamicsWorld(mDispatcher, mBroadPhaseInterface, mConstraintSolver, mCollisionConfiguration),
	    mTimeService(pTimeService)
	{
    	setGravity(btVector3(0,-10,0));

    	// Sets-up the ground.
    	static glm::mat4 TODO;
    	TODO[3].y = -1.0;
    	PhysicsMotionState* lGroundMotionState = new PhysicsMotionState(TODO);
    	btCollisionShape*   lGroundShape       = new btStaticPlaneShape(btVector3(0.0, 1.0, 0.0), 0.0);
        btRigidBody::btRigidBodyConstructionInfo lGroundInfo(FIXED_MASS,
        		                                             lGroundMotionState,
        		                                             lGroundShape,
        		                                             btVector3(0.0, 0.0, 0.0));
        btRigidBody* lGroundBody = new btRigidBody(lGroundInfo);
        addRigidBody(lGroundBody);
    }


    const status PhysicsService::start()
	{
	    return STATUS_OK;
	}

	const status PhysicsService::stop()
	{
	    return STATUS_OK;
	}

	const status PhysicsService::update()
	{
		double l1 = mTimeService.immediateElapsed();
		stepSimulation(mTimeService.elapsed(), 5);
		double l2 = mTimeService.immediateElapsed() - l1;
		Log::debug("Physics: %f", l2);
		return STATUS_OK;
	}


My component for blocks (am experimenting a component based approach):

Code: Select all

	class PhysicsBlock : public Component
	{
	public:
        struct Record
        {
        public:
        	float      mass;
        	glm::vec3  size;
        	glm::mat4* output;

        private:
        	friend class PhysicsBlock;

        	btRigidBody* rigidBody;
        };


		PhysicsBlock(PhysicsService& pPhysicsService):
			mPhysicsService(pPhysicsService),
			mRecords()
		{
			mRecords.reserve(256);
		}

        virtual const status start()
        {
        	foreach (iRecord, std::vector<Record>, mRecords) {
        		addRecord(*iRecord);
        	}
        	return STATUS_OK;
        }

        virtual const status stop()
        {
        	foreach (iRecord, std::vector<Record>, mRecords) {
        		removeRecord(*iRecord);
        	}
        	return STATUS_OK;
        }

        virtual const status update()
        {
        	return STATUS_OK;
        }


        Record& add()
        {
        	// TODO Multithread problem here
        	mRecords.resize(mRecords.size()+1);
        	return mRecords.back();
        }

	private:
        void addRecord(Record& pRecord) {
    	    carinae::PhysicsMotionState* lMotionState = new carinae::PhysicsMotionState(*pRecord.output);
    		btCollisionShape* lCollisionShape = new btBoxShape(btVector3(pRecord.size.x,
    				                                                     pRecord.size.y,
    				                                                     pRecord.size.z));
    		btVector3 lInertia(0.0, 0.0, 0.0);
    		lCollisionShape->calculateLocalInertia(pRecord.mass, lInertia);
    		btRigidBody::btRigidBodyConstructionInfo lBodyInformation(pRecord.mass,
    				                                                  lMotionState,
    				                                                  lCollisionShape,
    				                                                  lInertia);

    		pRecord.rigidBody = new btRigidBody(lBodyInformation);
    		mPhysicsService.addRigidBody(pRecord.rigidBody);
        }

        void removeRecord(Record& pRecord) {
    		//mPhysicsService.removeRigidBody(pRecord.rigidBody);
        }


        PhysicsService& mPhysicsService;
        std::vector<Record> mRecords;
	};
Instantiation:

Code: Select all

		for (int i = -7; i <= 7; ++i) {
			for (int j = -7; j <= 7; ++j) {

				carinae::PhysicsBlock::Record& lPhysicsBlockRecord = lPhysicsBlock.add();
				lPhysicsBlockRecord.mass   = 1.0;
				lPhysicsBlockRecord.size   = glm::vec3(1.0, 1.0, 1.0);
				lPhysicsBlockRecord.output = &lGraphicsElementRecord.attitude;
			}
		}


		carinae::PhysicsBlock::Record& lPhysicsBlockRecord1 = lPhysicsBlock.add();
		lPhysicsBlockRecord1.mass   = 1.0;
		lPhysicsBlockRecord1.size   = glm::vec3(1.0, 1.0, 1.0);
		lPhysicsBlockRecord1.output = &lGraphicsElementRecord1.attitude;

		carinae::PhysicsBlock::Record& lPhysicsBlockRecord2 = lPhysicsBlock.add();
		lPhysicsBlockRecord2.mass   = 1.0;
		lPhysicsBlockRecord2.size   = glm::vec3(1.0, 1.0, 1.0);
		lPhysicsBlockRecord2.output = &lGraphicsElementRecord2.attitude;


So am I performing badly (I am an absolute neebie to bullet) or am I too demanding (or both :lol:)?
Have you found some results yourself?



Edit: after testing a bit more, I realized that it's just the first seconds which are slow. Are first simulationSteps slower in bullet? Here is a second app, a bit more funny :D:
http://www.mediafire.com/?nb74ybcwgj6wbu5
I also forgot to say that you need resources files (images, etc.) in the "/sdcard/carinae/data..." directory. Here is the URL for these files http://www.mediafire.com/?8p2j59atw3765cq

But the result is not really "reproducible". When I execute it several time, the result is different. Maybe that"s a clue of bad usage (or maybe some random values are used for bullet simulation?).
Last edited by ratamovic on Tue Aug 24, 2010 11:31 pm, edited 1 time in total.
Dominik
Posts: 32
Joined: Fri Dec 19, 2008 2:51 pm

Re: Bullet performance on Android

Post by Dominik »

The problem is that in the beginning, bullet simulates all the 150 boxes on the ground - which is pretty much for a small phone :P
After some time, bullet sees that the boxes on the floor don't move, and puts them to sleep, thus the performance increase
ratamovic
Posts: 6
Joined: Mon Aug 23, 2010 7:18 pm

Re: Bullet performance on Android

Post by ratamovic »

Thanks a lot for your answer. That seems to be a good explanation. So i suppose i should first execute my physics service in the background first to stabilize it and then launch my boxes?

My second problem is that the result is not reproducible (the boxes hit the ground in a different way each time). I will make some trial because i think the very slow framerate may cause the problem (not enough stepSimulation). Would you have any other idea? Is it a good idea to change the number of simulation steps according to the framerate?

Thanks again.
ratamovic
Posts: 6
Joined: Mon Aug 23, 2010 7:18 pm

Re: Bullet performance on Android - Determinism problem

Post by ratamovic »

Hi again,

I read lots of doc and thread about stepping the world and I am a bit... disturbed.

Tell me if I am wrong but shouldn't the following:
stepSimulation(mTimeService.elapsed(), X); where X >= 1 give always the same simulation result? Maybe it the resulting simulation will be slower when X is low (moon effect) but the "end" positions should be the same.

Because on my PC, this is the more or less the case. But on Android, when I use:
stepSimulation(mTimeService.elapsed(), 1);
the simulation result is always the same.

But as soon as I use for example the following (like on the APK for which I gave a link):
stepSimulation(mTimeService.elapsed(), 10);
with a greater maxSubStep, the simulation result (I don't talk about speed) is neither the same. I mean: one time the box go to the foreground, the second times completely in the background after it hits the ground. Again, this works on my laptop.


So could it be possibly a bug? like an approximation which gets bigger and bigger, but only when using lots of subSteps (e.g. 10) but not when calling several times stepSimulation (10 times 1 subStep) to achieve the same result?

I also tried with fixed timestep (i.e. stepSimulation(btScalar(1.)/btScalar(60.), 10); ) and here the simulation is deterministic. So could it be related to interpolation?
Sorry if my explanations are a bit messy as I am a complete newbie with Physics :)


Funny thing: When I use "deterministic" simulation on Android and PC, I don't get the same result between both platforms. Could it come from my code (altough I use the same one)?



I just want to add my motionState code (communicates with g-truc glm) which was written quickly for test purpose:

Code: Select all

	class PhysicsMotionState : public btMotionState
	{
	public:
		PhysicsMotionState(glm::mat4& pAttitude) :
			mGraphicsAttitude(pAttitude),
			mPhysicsTransform()
		{
			mPhysicsTransform.setFromOpenGLMatrix((btScalar*) &mGraphicsAttitude);
		}

		virtual void getWorldTransform (btTransform& pPhysicsTransform) const
		{
			pPhysicsTransform = mPhysicsTransform;
		}

		virtual void setWorldTransform (const btTransform& pPhysicsTransform)
		{
			mPhysicsTransform = pPhysicsTransform;

			const btVector3& lRow1 = pPhysicsTransform.getBasis().getRow(0);
			const btVector3& lRow2 = pPhysicsTransform.getBasis().getRow(1);
			const btVector3& lRow3 = pPhysicsTransform.getBasis().getRow(2);
			const btVector3& lPos  = pPhysicsTransform.getOrigin();

			mGraphicsAttitude = glm::mat4(lRow1[0], lRow2[0], lRow3[0], 0.0f,
										  lRow1[1], lRow2[1], lRow3[1], 0.0f,
										  lRow1[2], lRow2[2], lRow3[2], 0.0f,
										  lPos[0],  lPos[1],  lPos[2],  1.0f);
		}


	private:
		glm::mat4& mGraphicsAttitude;
		btTransform mPhysicsTransform;
	};

Thanks in advance.
Dominik
Posts: 32
Joined: Fri Dec 19, 2008 2:51 pm

Re: Bullet performance on Android - Determinism problem

Post by Dominik »

About the sleeping bodys - if you know that some bodies start in a position where they won't be moved by the simulation, so that they would be put to sleep soon, you might want to

About the determinism:
As far as I understand, both your examples of calling stepSimulation should be deterministic.
A while back, the DbvtBroadphase was non-deterministic, but I believe that was fixed, never tried it though. Could you try using the btAxisSweep3 Broadphase instead?

About the difference between different platforms - that's perferctly normal. Due to differences in stuff like floating point operations etc., results can always be different.
josemarin
Posts: 38
Joined: Fri Aug 12, 2005 5:37 pm

Re: Bullet performance on Android - Determinism problem

Post by josemarin »

Are 150 boxes on the ground static?

If so, why not set their mass to 0?
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Bullet performance on Android - Determinism problem

Post by Dragonlord »

Dominik wrote:About the sleeping bodys - if you know that some bodies start in a position where they won't be moved by the simulation, so that they would be put to sleep soon, you might want to

About the determinism:
As far as I understand, both your examples of calling stepSimulation should be deterministic.
A while back, the DbvtBroadphase was non-deterministic, but I believe that was fixed, never tried it though. Could you try using the btAxisSweep3 Broadphase instead?

About the difference between different platforms - that's perferctly normal. Due to differences in stuff like floating point operations etc., results can always be different.
I've never witnessed Bullet to perform deterministic. Any pointers on where this is claimed in the docs or what classes are supposed to provide this behavior? In general I would be astonished since numerical instability should not allow a physics simulation to run deterministic inside certain boundaries.
ratamovic
Posts: 6
Joined: Mon Aug 23, 2010 7:18 pm

Re: Bullet performance on Android - Determinism problem

Post by ratamovic »

Thanks for your interest.


@dominik
About the sleeping bodys - if you know that some bodies start in a position where they won't be moved by the simulation, so that they would be put to sleep soon, you might want to
I think something is missing :D

I tried with btAxisSweep3 but it is still not deterministic. However it looks "more deterministic" than btDbvtBroadphase. Here are two screenshots to make it more clear. With btDbvtBroadphase and 10 maxSubSteps:
Image
With btAxisSweep3 and 10 maxSubSteps (more deterministic but still different):
Image

When I use a maxSubSteps of 1, results perfectly match. (My demo is just 5 seconds, so it should not really diverge anyway).


@josemarin
Are 150 boxes on the ground static?

If so, why not set their mass to 0?
Thanks for the suggestion. Well that's just a try to see the performance of bullet on Android. The box are not static as some other boxes fall on them. But to be honest I have a Bomberman-like in mind so if I go further I'll definitely use some fixed and moving block.


@Dragonlord
I've never witnessed Bullet to perform deterministic. Any pointers on where this is claimed in the docs or what classes are supposed to provide this behavior? In general I would be astonished since numerical instability should not allow a physics simulation to run deterministic inside certain boundaries.
I suppose it depends on these "boundaries". My demo is quite short so I think the "numerical divergence" shouldn't be so huge if any. And I suppose also that the fixed step system of bullet should limit this effect particularly in (sorry I am repeating) a short demo like that.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Bullet performance on Android - Determinism problem

Post by Dragonlord »

Actually the length of a simulation is not that much the problem but more what kind of math is used. Error Propagation Calculation shows some interesting behavior on certain mathematical constructions. That said though this simulation does not look that error prone.
ratamovic
Posts: 6
Joined: Mon Aug 23, 2010 7:18 pm

Re: Bullet performance on Android - Determinism problem

Post by ratamovic »

I understand.
But the weird thing here is that stepSimulation(mTimeService.elapsed(), 1); doesn't cause any "deviation". Final pictures are strictly the same. On the opposite to stepSimulation(mTimeService.elapsed(), X); where X > 1 which causes what you can see above.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Bullet performance on Android - Determinism problem

Post by Dragonlord »

With 1 you force the time step to be the one you give. With any value above you allow bullet to use smaller time steps up to the given time step with the ability to spill unused time over to the next invocation. So it is possible if you specify X time that the simulation is actually at X-Y with Y<(X/maxNumberSteps).
ratamovic
Posts: 6
Joined: Mon Aug 23, 2010 7:18 pm

Re: Bullet performance on Android - Determinism problem

Post by ratamovic »

With 1 you force the time step to be the one you give.
:lol: Still a discussion on the meaning of fixed/max/time steps :lol:

Tell me if I am wrong (I may have misunderstood you) but when you specify maxSubStep=1, Bullet does not use your time step for computations, but just for interpolation with motion state. Like it would with maxSubStep=10 except that in that case it computes several "iteration" and maybe interpolate the last one.
In other word Bullet is always computing each "fixed" step whatever happens (except with 0) but he will maybe compute more of them "in one frame" if the framerate is low. So with "1" the simulation should be at worse slower in motion (not in FPS)...

Anyway I suppose it's not so dramatic on simulation which are not too "extreme".



I would need some help to analyse the result of the profiler on my Desire. I obtain the following result:
08-26 22:08:36.568: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: Root (total running time: 50.019 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- stepSimulation (55.22 %) :: 27.619 ms / frame (1 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (44.783 %) :: 22.400 ms
08-26 22:08:36.578: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: stepSimulation (total running time: 27.619 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- synchronizeMotionStates (1.32 %) :: 0.365 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 1 -- internalSingleStepSimulation (98.12 %) :: 27.100 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (0.558 %) :: 0.154 ms
08-26 22:08:36.578: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: internalSingleStepSimulation (total running time: 27.100 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- updateActivationState (1.58 %) :: 0.428 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 2 -- integrateTransforms (1.58 %) :: 0.428 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 3 -- solveConstraints (10.03 %) :: 2.717 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 4 -- calculateSimulationIslands (5.74 %) :: 1.556 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 5 -- performDiscreteCollisionDetection (50.56 %) :: 13.702 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 6 -- predictUnconstraintMotion (29.51 %) :: 7.996 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (1.007 %) :: 0.273 ms
08-26 22:08:36.578: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: solveConstraints (total running time: 2.717 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- solveGroup (6.77 %) :: 0.184 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 1 -- processIslands (16.86 %) :: 0.458 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 2 -- islandUnionFindAndQuickSort (71.92 %) :: 1.954 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (4.453 %) :: 0.121 ms
08-26 22:08:36.578: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: solveGroup (total running time: 0.184 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- solveGroupCacheFriendlyIterations (16.85 %) :: 0.031 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 1 -- solveGroupCacheFriendlySetup (49.46 %) :: 0.091 ms / frame (4 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (33.696 %) :: 0.062 ms
08-26 22:08:36.578: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: processIslands (total running time: 0.458 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- solveGroup (0.00 %) :: 0.000 ms / frame (0 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (100.000 %) :: 0.458 ms
08-26 22:08:36.578: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.578: INFO/LogTag(17843): Profiling: solveGroup (total running time: 0.000 ms) ---
08-26 22:08:36.578: INFO/LogTag(17843): 0 -- solveGroupCacheFriendlyIterations (0.00 %) :: 0.000 ms / frame (0 calls)
08-26 22:08:36.578: INFO/LogTag(17843): 1 -- solveGroupCacheFriendlySetup (0.00 %) :: 0.000 ms / frame (0 calls)
08-26 22:08:36.578: INFO/LogTag(17843): Unaccounted: (0.000 %) :: 0.000 ms
08-26 22:08:36.589: INFO/LogTag(17843): ----------------------------------
08-26 22:08:36.589: INFO/LogTag(17843): Profiling: performDiscreteCollisionDetection (total running time: 13.702 ms) ---
08-26 22:08:36.589: INFO/LogTag(17843): 0 -- dispatchAllCollisionPairs (18.92 %) :: 2.593 ms / frame (4 calls)
08-26 22:08:36.589: INFO/LogTag(17843): 1 -- calculateOverlappingPairs (0.22 %) :: 0.030 ms / frame (4 calls)
08-26 22:08:36.589: INFO/LogTag(17843): 2 -- updateAabbs (80.40 %) :: 11.017 ms / frame (4 calls)
08-26 22:08:36.589: INFO/LogTag(17843): Unaccounted: (0.452 %) :: 0.062 ms
08-26 22:08:36.589: INFO/CARINAE(17843): FPS: 20.625217

08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: Root (total running time: 533.356 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- stepSimulation (99.35 %) :: 529.877 ms / frame (1 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (0.652 %) :: 3.479 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: stepSimulation (total running time: 529.877 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- synchronizeMotionStates (0.54 %) :: 2.838 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 1 -- internalSingleStepSimulation (99.44 %) :: 526.886 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (0.029 %) :: 0.153 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: internalSingleStepSimulation (total running time: 526.886 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- updateActivationState (0.06 %) :: 0.336 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 1 -- updateActions (0.00 %) :: 0.000 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 2 -- integrateTransforms (0.79 %) :: 4.181 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 3 -- solveConstraints (81.64 %) :: 430.146 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 4 -- calculateSimulationIslands (0.18 %) :: 0.945 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 5 -- performDiscreteCollisionDetection (16.57 %) :: 87.312 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 6 -- predictUnconstraintMotion (0.74 %) :: 3.876 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (0.017 %) :: 0.090 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: solveConstraints (total running time: 430.146 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- solveGroup (0.06 %) :: 0.275 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 1 -- processIslands (99.53 %) :: 428.131 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 2 -- islandUnionFindAndQuickSort (0.38 %) :: 1.618 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (0.028 %) :: 0.122 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: solveGroup (total running time: 0.275 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- solveGroupCacheFriendlyIterations (22.18 %) :: 0.061 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 1 -- solveGroupCacheFriendlySetup (55.27 %) :: 0.152 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (22.545 %) :: 0.062 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: processIslands (total running time: 428.131 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- solveGroup (98.90 %) :: 423.432 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (1.098 %) :: 4.699 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: solveGroup (total running time: 423.432 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- solveGroupCacheFriendlyIterations (74.98 %) :: 317.504 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 1 -- solveGroupCacheFriendlySetup (24.54 %) :: 103.915 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (0.475 %) :: 2.013 ms
08-26 22:08:48.538: INFO/LogTag(17843): ----------------------------------
08-26 22:08:48.538: INFO/LogTag(17843): Profiling: performDiscreteCollisionDetection (total running time: 87.312 ms) ---
08-26 22:08:48.538: INFO/LogTag(17843): 0 -- dispatchAllCollisionPairs (94.20 %) :: 82.245 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 1 -- calculateOverlappingPairs (0.04 %) :: 0.031 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): 2 -- updateAabbs (5.77 %) :: 5.036 ms / frame (5 calls)
08-26 22:08:48.538: INFO/LogTag(17843): Unaccounted: (0.000 %) :: 0.000 ms
08-26 22:08:48.538: INFO/CARINAE(17843): FPS: 2.511337

08-26 22:08:52.143: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.148: INFO/LogTag(17843): Profiling: Root (total running time: 55.512 ms) ---
08-26 22:08:52.148: INFO/LogTag(17843): 0 -- stepSimulation (20.45 %) :: 11.353 ms / frame (1 calls)
08-26 22:08:52.148: INFO/LogTag(17843): Unaccounted: (79.549 %) :: 44.159 ms
08-26 22:08:52.148: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.148: INFO/LogTag(17843): Profiling: stepSimulation (total running time: 11.353 ms) ---
08-26 22:08:52.148: INFO/LogTag(17843): 0 -- synchronizeMotionStates (1.07 %) :: 0.122 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 1 -- internalSingleStepSimulation (98.12 %) :: 11.139 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): Unaccounted: (0.810 %) :: 0.092 ms
08-26 22:08:52.148: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.148: INFO/LogTag(17843): Profiling: internalSingleStepSimulation (total running time: 11.139 ms) ---
08-26 22:08:52.148: INFO/LogTag(17843): 0 -- updateActivationState (1.37 %) :: 0.153 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 2 -- integrateTransforms (3.84 %) :: 0.428 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 3 -- solveConstraints (11.79 %) :: 1.313 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 4 -- calculateSimulationIslands (5.48 %) :: 0.610 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 5 -- performDiscreteCollisionDetection (44.93 %) :: 5.005 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 6 -- predictUnconstraintMotion (29.59 %) :: 3.296 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): Unaccounted: (2.998 %) :: 0.334 ms
08-26 22:08:52.148: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.148: INFO/LogTag(17843): Profiling: solveConstraints (total running time: 1.313 ms) ---
08-26 22:08:52.148: INFO/LogTag(17843): 0 -- solveGroup (9.29 %) :: 0.122 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 1 -- processIslands (9.37 %) :: 0.123 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): 2 -- islandUnionFindAndQuickSort (71.97 %) :: 0.945 ms / frame (4 calls)
08-26 22:08:52.148: INFO/LogTag(17843): Unaccounted: (9.368 %) :: 0.123 ms
08-26 22:08:52.148: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.148: INFO/LogTag(17843): Profiling: solveGroup (total running time: 0.122 ms) ---
08-26 22:08:52.148: INFO/LogTag(17843): 0 -- solveGroupCacheFriendlyIterations (0.00 %) :: 0.000 ms / frame (4 calls)
08-26 22:08:52.159: INFO/LogTag(17843): 1 -- solveGroupCacheFriendlySetup (100.00 %) :: 0.122 ms / frame (4 calls)
08-26 22:08:52.159: INFO/LogTag(17843): Unaccounted: (0.000 %) :: 0.000 ms
08-26 22:08:52.159: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.159: INFO/LogTag(17843): Profiling: processIslands (total running time: 0.123 ms) ---
08-26 22:08:52.159: INFO/LogTag(17843): 0 -- solveGroup (0.00 %) :: 0.000 ms / frame (0 calls)
08-26 22:08:52.159: INFO/LogTag(17843): Unaccounted: (100.000 %) :: 0.123 ms
08-26 22:08:52.159: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.159: INFO/LogTag(17843): Profiling: solveGroup (total running time: 0.000 ms) ---
08-26 22:08:52.159: INFO/LogTag(17843): 0 -- solveGroupCacheFriendlyIterations (0.00 %) :: 0.000 ms / frame (0 calls)
08-26 22:08:52.159: INFO/LogTag(17843): 1 -- solveGroupCacheFriendlySetup (0.00 %) :: 0.000 ms / frame (0 calls)
08-26 22:08:52.159: INFO/LogTag(17843): Unaccounted: (0.000 %) :: 0.000 ms
08-26 22:08:52.159: INFO/LogTag(17843): ----------------------------------
08-26 22:08:52.159: INFO/LogTag(17843): Profiling: performDiscreteCollisionDetection (total running time: 5.005 ms) ---
08-26 22:08:52.159: INFO/LogTag(17843): 0 -- dispatchAllCollisionPairs (17.66 %) :: 0.884 ms / frame (4 calls)
08-26 22:08:52.159: INFO/LogTag(17843): 1 -- calculateOverlappingPairs (1.22 %) :: 0.061 ms / frame (4 calls)
08-26 22:08:52.159: INFO/LogTag(17843): 2 -- updateAabbs (81.12 %) :: 4.060 ms / frame (4 calls)
08-26 22:08:52.159: INFO/LogTag(17843): Unaccounted: (0.000 %) :: 0.000 ms
08-26 22:08:52.159: INFO/CARINAE(17843): FPS: 8.334020
Could the performance here be improved with a different configuration (broadphase, etc.)?