iPhone and Thumb stuff

[Pilo]

Hi everyone,

As I read there, it seems that there are a lot of people using bullet on iphone. I am too
I am working on some car game, using custom raycast car, and tri mesh (bvh one) to make static word.

But I ran into strange trouble : I was going to post today because the trimesh collision (sphere, or convex shape, or box) was not working at all (crate using box shape was acting "like" sphere, before falling through the mesh, the car behave very weirdly when colliding with the mesh etc etc). I even switch back to an old version of bullet (where everything was right, but at that time I was working on simulator, and not the device).
Finally I discover that when I re-activate the "famous" "compile for thumb" option in xcode, everything works right! (but the cpu usage is more important, about double)... which is weird because the "compile for thumb" should make smaller code, as far a I understand, and it's an optimisation, but if I deactivate it, bullet collision seems to be broken.

Anybody has this trouble too? Any clue where this can comes from?

thank you very much!

Pilo

[gleemer]

Hey Pilo, yeah I'm having the same problem. When rendering with thumb I am drawing a ragdoll made up with boxes. When I turn off compile for thumb the boxes are not drawn.

Does the previous version of Bullet work? (v2.72) I haven't tried that yet. But it appears that with any physics used on the iphone the thumb compile should be off for performance (fps) boost as you noted.

I am going to try out the older version.
Maybe someone else knows what's up with this.

[Erwin Coumans]

Can you help and share a small iPhone project that reproduces the problem?

If you don't have a framework, you could try to use the open source Oolong Engine for iPhone to try to reproduce the problem, it has Bullet integrated in some of the samples.
Thanks,
Erwin

[gleemer]

Okay I don't know why this was working in the simulator with both thumb and arm, but not on the iphone with arm only with thumb. Could be a bug.

BTW: I am using the oolong engine.

This is what I did to solve the problem.

When running with arm mode on the iphone and rendering I checked the values of the retrieved opengl matrix :

m_bodies[0]->getCenterOfMassTransform().getOpenGLMatrix( worldMat );
NSLog(@"worldMat[12]=%f worldMat[13]=%f worldMat[14]=%f", worldMat[12], worldMat[13], worldMat[14]);

these were being set to not initialized : worldMat[12]=nan worldMat[13]=nan worldMat[14]=nan

So where I create a rigid body I tried this:

Code: Select all

// transform.setIdentity();

transform.setOrigin(btVector3(0.0f, 0.0f, 0.0f));	

transform.setOrigin(btVector3(btScalar(0.0f * SCALAR_FACTOR), btScalar(1.2f * SCALAR_FACTOR), btScalar(0.0f * SCALAR_FACTOR)));
m_bodies[BODYPART_SPINE] = localCreateRigidBody( 1.0f, offset*transform, m_shapes[BODYPART_SPINE]);

Originally the transform.setIdentity() was called, and instead of using transform.setIdentity(), I commented that out and inserted set transform origin to 0,0,0.

Then the rigidbody transform matrix is initialized and rendered.

Don't know why this made a difference though.

[Erwin Coumans]

Could you check the values of a transform, directly after calling transform.setIdentity()?

Which version of Bullet are you using? Bullet 2.73 sp1 or Bullet 2.74 beta?
Thanks for the feedback,
Erwin

[Pilo]

Hi,

sorry for the delay, I was away last days.

I looked a little bit deeper in this trouble, and here's what I find :
When compiling for iPhone, with -O3 gcc option (or -O2), and "compile for thumb" option NOT activated (bigger code, but should be faster), I get instable collision (box on trimesh and box/box too I think) but everything else seems to work fine (raycast etc). With simple -O or -O1 optimisation flag, everything seems to work fine.
With -O3 or -O2, but "compile for thumb" activated (so use the "smaller float code optimisation"), everything works fine.

About performance : with compile for thumb NOT enable, on a simple scene, I can reach 50/60fps, which is pretty nice. When it's activated, I'm alway below 50fps, and more often near 40 (which is good either, but my current scene is too empty for good profiling).

The optimisation flag (O3, O2 or O1) doesn't seems to make a big improvement (I mean -O1 seems enough, but as I said before, I don't have a nice working scene yet). So I guess it can be a work around by now to use only O1 optimisation flag with compile for thumb disable (which is better than O3 and compile for thumb enable).

I don't have the time right now to try it in Oolong Engine, but sure I will give it a try in the future.
I'm using bullet 2.72, I also try 2.73 with the same trouble. I don't want to change bullet right now as I'm working on seomthing else (and fear to break everything), but in the end the last version of bullet will be tested too

Thanks for your help Erwin and Gleemer, I'll post more here when I have tested more

Pilo

[gleemer]

Erwin,
Thanks for this physics engine.

It appears when I tried Pilo's suggestion of compiling with -O1 on the device, the physics works correctly, as well as the transform.setIdentity();

transform.setIdentity();
transform.getOpenGLMatrix( mat );

mat[0]=1.000000 mat[1]=0.000000 mat[2]=0.000000 mat[3]=0.000000
mat[4]=0.000000 mat[5]=1.000000 mat[6]=0.000000 mat[7]=0.000000
mat[8]=0.000000 mat[9]=0.000000 mat[10]=1.000000 mat[11]=0.000000
mat[12]=0.000000 mat[13]=0.000000 mat[14]=0.000000 mat[15]=1.000000

So now the ragdoll character does not spaz out like before when I was compiling with -O2 optimizing.

Thnks Pilo for your discovery and sharing it, it helped me with a important part of my game.
-)

[Erwin Coumans]

It appears when I tried Pilo's suggestion of compiling with -O1 on the device, the physics works correctly, as well as the transform.setIdentity();

It is important that we figure out what parts of Bullet breaks the iPhone compiler when using -O2.

Can you please provide the values of 'mat' when using -O2 for your code fragment?

Code: Select all

transform.setIdentity();
transform.getOpenGLMatrix( mat );

Thanks a lot,
Erwin

[gleemer]

Hey,
I'm using Bullet 2.73.
Received correct identity matrix values like in the above post and from setorigin, all matrix values were correct.

Code: Select all

transform.setIdentity();
		transform.getOpenGLMatrix( mat );
		NSLog(@"mat[0]=%f mat[1]=%f mat[2]=%f mat[3]=%f", mat[0], mat[1], mat[2], mat[3] );
		NSLog(@"mat[4]=%f mat[5]=%f mat[6]=%f mat[7]=%f", mat[4], mat[5], mat[6], mat[7] );
		NSLog(@"mat[8]=%f mat[9]=%f mat[10]=%f mat[11]=%f", mat[8], mat[9], mat[10], mat[11] );
		NSLog(@"mat[12]=%f mat[13]=%f mat[14]=%f mat[15]=%f", mat[12], mat[13], mat[14], mat[15] );
		
		 
		transform.setOrigin(btVector3(btScalar(0.0f * SCALAR_FACTOR), btScalar(1.2f * SCALAR_FACTOR), btScalar(0.0f * SCALAR_FACTOR)));
		
		transform.getOpenGLMatrix( mat );
		NSLog(@"mat[0]=%f mat[1]=%f mat[2]=%f mat[3]=%f", mat[0], mat[1], mat[2], mat[3] );
		NSLog(@"mat[4]=%f mat[5]=%f mat[6]=%f mat[7]=%f", mat[4], mat[5], mat[6], mat[7] );
		NSLog(@"mat[8]=%f mat[9]=%f mat[10]=%f mat[11]=%f", mat[8], mat[9], mat[10], mat[11] );
		NSLog(@"mat[12]=%f mat[13]=%f mat[14]=%f mat[15]=%f", mat[12], mat[13], mat[14], mat[15] );

--------
But when rendering in a loop is where the values become 'nan'. Maybe the compiler is trying some fancy loop optimization that breaks the physics code.

Code: Select all

for (i=0; i < BODYPART_CNT; i++) {
				m_bodies[i]->getCenterOfMassTransform().getOpenGLMatrix( worldMat );
				
				NSLog(@"worldMat[0]=%f worldMat[1]=%f worldMat[2]=%f worldMat[3]=%f", worldMat[0], worldMat[1], worldMat[2], worldMat[3] );
				NSLog(@"worldMat[4]=%f worldMat[5]=%f worldMat[6]=%f worldMat[7]=%f", worldMat[4], worldMat[5], worldMat[6], worldMat[7] );
				NSLog(@"worldMat[8]=%f worldMat[9]=%f worldMat[10]=%f worldMat[11]=%f", worldMat[8], worldMat[9], worldMat[10], worldMat[11] );
				NSLog(@"worldMat[12]=%f worldMat[13]=%f worldMat[14]=%f worldMat[15]=%f", worldMat[12], worldMat[13], worldMat[14], worldMat[15] );
				
				glPushMatrix();
					glMultMatrixf( worldMat );
				 	size[0] =   bodyPartsDims[ i ][ 0 ] * SCALAR_FACTOR;
					size[1] =   bodyPartsDims[ i ][ 1 ] * SCALAR_FACTOR;
					size[2] =   bodyPartsDims[ i ][ 0 ] * SCALAR_FACTOR;
					DrawBox( size );
				glPopMatrix();
			}

The correct values are given when compiling with -O1 (JTLYK).

[Erwin Coumans]

Are you using Bullet 2.73 SP1 or later, or Bullet 2.73?

Using -O0 or -O1 is not a good solution, it just hides the problem. If Bullet doesn't compile using -O2 or -O3 we need to figure out why and fix it.

The Examples/Physics/FallingCubes sample in the Oolong Engine builds and runs fine. It uses a bunch of dynamic btBoxShape bodies bouncing on some btStaticPlaneShape.
http://code.google.com/p/oolongengine/

Can any of you please try to reproduce this in the Oolong Engine, or another small testbed?

Thanks a lot,
Erwin

[gleemer]

If you want I could email you a Oolong Falling Cubes example with ragdoll physics like the one I was testing.?
You'll need a iphone or itouch device to test it.

[Erwin Coumans]

If you want I could email you a Oolong Falling Cubes example with ragdoll physics like the one I was testing.?
You'll need a iphone or itouch device to test it.

Could you please zip the example and attach it to this topic?

Thanks a lot,
Erwin

[Pilo]

I just try oolongengine, with the Falling cube example : no need to modify anything, it has the same issues :
When you compile it with the "compile for thumb" option DEACTIVATED (about 100% faster...) and -O2 compile option, cubes has a lot of jitter (almost impossible to make a stable stack of box).
Box/plane collision seems to be fine (as cube resting on the plane doesn't jitter), but every cubes above are always moving, penetrating etc.

When activating "compile for thumb", everything seems fine. (as expected).
Can't it be a bug with iPhone SDK? (I mean, not a bullet issue?)

[BigZaphod]

Has this been figured out yet? I just ran into it myself and then found this thread, so I'm curious. I'm currently using Bullet 2.73.

EDIT: I saw a thread about Box2D where they ran into the same problem. Adding "volatile" to a couple variables appeared to work around the issue. I have no idea if that'd work in Bullet, though. Nor do I know where exactly the optimizer is bombing the logic, either..

EDIT AGAIN: I believe this problem is caused by the optimizer leaving values in registers that are wider than the float type. This is probably true of the math hardware on the ARM chip the iPhone is using which is why it shows up only when Thumb is disabled. What happens then is that values don't compare/compute in the usual/expected way (perhaps being seen as equal when they wouldn't be if the registers were smaller, etc.).

[gleemer]

I found this on the box2d board:

Porting to iphone myself.

O3 is definately the fastest, along with disabled thumb. The problem here is, with O3 you need to always initialize your variables fully.

This is because the fastest, smallest flag actually uses a local stack, and doesn't assume that new variables will be null.

By making sure all variables are nulled to begin with, you will avoid bugs with O3. Its all about making sure that new vars are not pointing to some garbage, but to null. If you make it null, it will work fine.

I think Box2D is a little lazy in places and doesn't always initialise variables with null or a value and this is why it breaks. I pulled this info off Apple site someplace, can't remember where.