Bullet 2.74 & iPhone Problem

User avatar
sio2interactive
Posts: 31
Joined: Tue Jul 29, 2008 10:26 am

Bullet 2.74 & iPhone Problem

Post by sio2interactive »

The problem actually occur since 2.73 SP1 and is also present in 2.74... for some reason on the iPhone (not simulator, only the device) in release (as well as debug) some of the values the opengl matrix become NAN as soon object(s) collide with each others, and the world start bouncing all over the place... I haven't been able to track the exact cause... but with 2.73 everything work perfectly, its probably coming from some of the modifications on the linear math, I thought that'll be fixed in 2.74 but it is still present...

Am I the only one with this problem or someone else have noticed strange behavior on iphone since bullet 2.73 SP1?

If someone knows how to fix that in 2.74 please lemme know...

Cheers,
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Bullet 2.74 & iPhone Problem

Post by Erwin Coumans »

It has been reported before, so here is the issue in the tracker:
http://code.google.com/p/bullet/issues/detail?id=201

Can you please help narrowing down the problem?
Does it happen with any collision shape interactions? sphere-vs-sphere, box-against-box etc?
Does it happen with any broadphase?
Can you help finding which SVN revision broke the build exactly?
Have you tried changing any of the constraint solver/friction settings?

Thanks,
Erwin
User avatar
sio2interactive
Posts: 31
Joined: Tue Jul 29, 2008 10:26 am

Re: Bullet 2.74 & iPhone Problem

Post by sio2interactive »

Does it happen with any collision shape interactions? sphere-vs-sphere, box-against-box etc?

>> I tried with box, sphere, cylinderZ, capsuleZ, cone, convex hull and they are all doing it, I do believe that it happen with ALL of them...

Does it happen with any broadphase?

>> Im using btDbvtBroadphase, haven't tried with others yet...

Can you help finding which SVN revision broke the build exactly?

>> I will try to find the time...

Have you tried changing any of the constraint solver/friction settings?

>> Nope... Im using the same default values as Blender
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Bullet 2.74 & iPhone Problem

Post by Erwin Coumans »

The latest Oolong Engine has been upgraded to Bullet 2.74 now:
http://oolongengine.googlecode.com

The Examples/Physics/FallingCubes sample compiles, links and runs fine without problems.

Can someone reproduce the problem in the Oolong Engine, or another very small hello-world project that is easy to build (no external dependencies etc)?
Thanks,
Erwin
User avatar
sio2interactive
Posts: 31
Joined: Tue Jul 29, 2008 10:26 am

Re: Bullet 2.74 & iPhone Problem

Post by sio2interactive »

Ok I test oolong cube example myself (on the device firmware & SDK 2.2.1) and it got the same problem... Bullet 2.74 is also not working properly with oolong, the cubes are bouncing all over the place while they should simply fall down attracted by the gravity...

Someone have found what causes the problem?
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Bullet 2.74 & iPhone Problem

Post by Erwin Coumans »

Can you confirm that Bullet 2.74 with Oolong Engine is working fine when enabling the 'thumb' setting?

http://code.google.com/p/bullet/issues/detail?id=201

It seems that other engines, such as Box2D had similar issues that they resolved by making some variables 'volatile':
http://www.bulletphysics.com/Bullet/php ... f=9&t=3225

Can anyone help narrowing down which file(s) break iPhone support, by partially enabling the 'thumb' setting only for certain files?
Thanks,
Erwin
gleemer
Posts: 15
Joined: Sat Nov 29, 2008 6:34 am

Re: Bullet 2.74 & iPhone Problem

Post by gleemer »

I posted this on the other iphone thread on the same topic.

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.