Common World Matrix

Jack
Posts: 59
Joined: Thu Aug 31, 2006 11:51 am

Common World Matrix

Post by Jack »

I am full of ideas :D

1)
PHY_IMotionState is used to copy World Matrix to/from Bullet. It is not good. Why not to mantain Common World Matrix for both renderer and Bullet? Instead of PHY_IMotionState Bullet could accept pointer to something like WORLD_MATRIX.

Code: Select all

struct WORLD_MATRIX : public Matrix4x4
{
void Lock();
void Unlock();
some other useful methods...
};
Renderer (in most cases) does not need you pass separate QUATERNION, POSITION. It only has to waste time to convert QUATERNION to matrix, put it all together...
Both Renderer and Bullet want to access World Info directly (without useless conversions and copy operations). Is not it?

2)
It is also good to pack normal and inverse matrices into one matrix4x4. If we put:

matrix4x4 m;
m._14 = -dot(m._line1, m._line4);
m._24 = -dot(m._line2, m._line4);
m._34 = -dot(m._line3, m._line4);

then

mul(m,v) gives us inverse transform of vector v. And we do not need to transpose something...
Keeping all in ONE matrix could increase performance (espesially using SIMD operations).
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Post by Erwin Coumans »

Please upgrade to Bullet 2.11, there is no PHY_MotionState anymore!
There is just a m_worldtransform in the btCollisionObject (and therefore in the derived btRigidBody class).

I don't want to add any dependency in memory layout between physics and graphics matrix. It's up to the user to synchronize them. A good optimization, which is not in Bullet at the moment is to only synchronize 'active' objects. That reduces the work to less then a handful of objects usually.

Sharing the reference is not so useful for performance: in the end, it is all about reducing cache misses and optimizing code loops. Right now, Bullet is not optimized yet, but I will pack the data per simulation islands and perform collision detection and constraint solving on packed data. This is very cache friendly. Then, synchronizing the transforms only when it is necessary (based on active islands) should make it very fast.

But I agree, we should add SIMD sooner or later. I got contribution of Win32 SIMD classes, we can merge that into LinearMath.

Thanks for sharing the ideas!
Erwin