Collision computing problem on Cell processor

[zzcn]

I have two versions of my program, one uses the SPU with PPU together, another just use PPU. The SPU version works not well, sometimes it looks like the collision simulation is wrong. The PPU version works problemloss. The only different in my code is that the SPU version uses a SpuGatheringCollisionDispatcher, and the others use a normal collision dispatcher. They both have the same terrain data.

I would look into the bullet source code, see what i could find.
may anyone have met the same problem before?


besh wishes
kun

[zzcn]

I just saw a old post from Erwin on the forum, it's about the collision shapes that bullet supported for Spu:

http://www.bulletphysics.com/Bullet/php ... sion#p8198

I checked my collision shapes first and try to set the number MAX_NUM_SPU_CONVEX_POINTS larger.
The collision shapes in my program are all supported on SPU: btConvexHulshape, btBvhTriangleMeshShape and btBoxShape.

The problem is the same: I shoot one box into the bullet world and sometime the box seems like collide with something in the air,which is actually nothing there.
Can this has something to to with the Terrain data, I used a btBvhTriangleMeshShape as terrain, and it's big one.

I also find out when a box finally fall down on the ground, it never stops the "little shake". it just keep having this small shake. Normally it should have a little bit shake and stay still.

[Erwin Coumans]

Are you using scaling?

Can you re-create the issue in one of the Bullet demos?

If not, can you create a COLLADA snapshot, zip it and attach it?

Thanks,
Erwin

[zzcn]

Hi Erwin, thanks for ur replay.

I edited the BulletCollision and LinearMath makefiles for ibmsdk, because when I linked the three libraries for snapshot, there were always "undefined reference" errors, maybe the makefiles for ibmsdk should be updated in next release.

Anyway finally I compiled my program successfully and tied to run it and save the snapshot, but it exited with a segfault. I used ppu-gdb to backtrace, which statement caused the segfault, it's only this?
#0 0x00000000 in ?? ()
with "printf" I found out the segfault came out from this statement:

Code: Select all

converter.save("snapshot.dae");

just after the stepSimulation, at that moment there is still no dynamic rigid body in the physicworld.

I will still work on it, try to figure out what's wrong with the snapshot here.

[zzcn]

The segmentation fault came out from the getGravity() function from instantiateDom() function.

change the code in instantiateDom() function:

Code: Select all

	btVector3 btG = getGravity ();
	g->getValue().set3 (btG[0], btG[1], btG[2]);

to be like this:

Code: Select all

	//btVector3 btG = getGravity ();
	g->getValue().set3 (m_dynamicsWorld->getGravity().getX(), m_dynamicsWorld->getGravity().getY(), m_dynamicsWorld->getGravity().getZ());

then it works, but I'm confused the gravity is (0,0,0), which actually should be (0,0,-10).

After this, there are still other segfaults in save(), I will check it out later, need a break