Irrlicht Engine

Hi,

I have 2 questions to people who might have experience with Irrlicht and the Bullet Physics Engine (http://www.bulletphysics.com/).

I am writing a game with some friends, where the user is driving a spaceship, which is displayed with irrlicht. Now, we decided to let the Bullet physics engine do the physics.

However, for that, we would need to copy the bullet's vectors (at least) each frame into the irrlicht mesh to update the vectors for irrlicht. That would be a lot of CPU work, since we'll have lots of complex spaceships.

Do you have an idea how to share the memory between Irrlicht and Bullet? Also, which subclass of btCollisionShape (http://www.bulletphysics.com/Bullet/Bul ... Shape.html) would you suggest to store the vertices in?

Greets,
Lo

Bullet supports a collision shape that shares vertices with the graphics but it's very slow as the graphics vertices aren't usually optimized for physics and vice-versa. I suggest you just keep another copy of the mesh for physics.

However, for that, we would need to copy the bullet's vectors (at least) each frame into the irrlicht mesh to update the vectors for irrlicht.

This sounds strange to me, you only need to set the Position and Rotation unless you are doing cloth-based or destructible physics? Please look at the other examples on the forum on how to use Bullet with Irrlicht (One of them is written by the Bullet author himself Erwin Coumans).

One final note, Bullet vectors are actually SSE vectors in disguise (They hide the 4th component). So you have to be careful not to pass the address of an Irrlicht vector disguised as a Bullet vector as it may not be 16-byte aligned and will probably cause a crash.

Cheers

It's a conversion between Euler and Quaternion and then back again every frame.

Then the Euler then has to be converted to a matrix for rendering.

What the original poster was asking for wasn't unreasonable although a pure copy would be fine without the conversion and having them separate also allows you to put the game update and physics update on different threads and possibly processors.

That said until I run proper tests I can't say for certain if or if not the conversion is negligible in the grand scheme of things (I also do another transformation to use Collision Offsets that Bullet doesn't really do the way I wanted it done etc etc)

BlindSide wrote:Bullet supports a collision shape that shares vertices with the graphics but it's very slow as the graphics vertices aren't usually optimized for physics and vice-versa. I suggest you just keep another copy of the mesh for physics.

Vertex sharing between graphics and physics should be efficient in general
(as long as the x,y,z position components are consecutive). We added the striding mesh interface to Bullet for this purpose.

Do you have any reproduction case that shows any performance degradation because vertex format is inefficient for physics/collision detection?
Thanks a lot,
Erwin