Real-Time Physics Simulation Forum 2006-09-30T15:10:13+00:00 https://pybullet.org/Bullet/phpBB3/app.php/feed/topic/567 2006-09-30T15:10:13+00:00 2006-09-30T15:10:13+00:00 https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=1985#p1985 <![CDATA[Common World Matrix]]> 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

Statistics: Posted by Erwin Coumans — Sat Sep 30, 2006 3:10 pm

]]> 2006-09-30T11:33:48+00:00 2006-09-30T11:33:48+00:00 https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=1979#p1979 <![CDATA[Common World Matrix]]>

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: 

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).

Statistics: Posted by Jack — Sat Sep 30, 2006 11:33 am

]]>