Support of non-orthogonal transformation matrices.

[Beelzebub]

I am considering to switch to a different physics API and briefly looked into the bullet source to find if the requirements are met.

The btTransform class is not supporting non-orthogonal transformation matrices. Does this mean that it will not be trivial to add for example shear transformations to object instances?

Thanks for the clarification!

[Erwin Coumans]

We can't generally apply non-orthogonal transforms to object instances and their collision shapes so we can optimized parts of the collision detection pipeline.

Most collision shapes support local scaling, so they can be shared even at different scaling. Apart from rotation, translation and local scaling, the recommended way is to 'bake' any non-orthogonal transforms into triangle meshes, when using btBvhTriangleMeshShape or vertices when using btConvexHullShape.

If this is a problem, can you go more into detail?
Thanks,
Erwin

[Beelzebub]

That is really a problem because I have thousands of shear transformed object instances in most scenes here. Copying and modifying the meshes of these instances is not an option because of memory and performance.

I do understand that there is a performance penalty when considering non-orthogonal transformation matrices, but couldn't the code be branched for this? Sheared objects are very common for scenes which have a terrain for example.

[Erwin Coumans]

That is really a problem because I have thousands of shear transformed object instances in most scenes here. Copying and modifying the meshes of these instances is not an option because of memory and performance.

I do understand that there is a performance penalty when considering non-orthogonal transformation matrices, but couldn't the code be branched for this? Sheared objects are very common for scenes which have a terrain for example.

Are those static (concave) triangle meshes? If so a fork is not needed, and it would be trivial to create a btShearedBvhTriangleMeshShape. Just apply the shear at run-time (similar to the local scaling) in processTriangle:
http://code.google.com/p/bullet/source/ ... ape.cpp#44

Do you have some example assets (sheared instances) so we can try to help you out?
(Attached to this forum topic as zipped Maya, Max, Cinema4D, Blender, COLLADA, FBX file)
Cheers,
Erwin

[Beelzebub]

Are those static (concave) triangle meshes? If so a fork is not needed, and it would be trivial to create a btShearedBvhTriangleMeshShape. Just apply the shear at run-time (similar to the local scaling) in processTriangle:
http://code.google.com/p/bullet/source/ ... ape.cpp#44

Do you have some example assets (sheared instances) so we can try to help you out?
(Attached to this forum topic as zipped Maya, Max, Cinema4D, Blender, COLLADA, FBX file)
Cheers,
Erwin

Yes, the objects are static triangle meshes. Many instances in the scene can be shear projected based on their place on terrain. Imagine the stump of a tree that is placed on a slope for example. A shear projection keeps everything flush to the slope and vertical surfaces stay vertical.

Does your suggestion mean that there is just another code branch for compiling the hierarchy or does it require a significant performance penalty because the mesh has to be copied and transformed for every individual instance that is sheared?

[Erwin Coumans]

Yes, the objects are static triangle meshes. Many instances in the scene can be shear projected based on their place on terrain. Imagine the stump of a tree that is placed on a slope for example. A shear projection keeps everything flush to the slope and vertical surfaces stay vertical.

Does your suggestion mean that there is just another code branch for compiling the hierarchy or does it require a significant performance penalty because the mesh has to be copied and transformed for every individual instance that is sheared?

We can simply create a new class that solves the problem. Both the triangle mesh as well as the AABB tree can be shared among all instances. The performance impact should be minimal, because we only apply a transform on the triangles vertices that have actual overlap. This should be negligible compared to narrowphase/contact generation etc.

For this to work, we need to transform the AABB of objects that overlap with the sheered instances into the sheered local space, using the inverse sheer transform. Then, when we need to perform a narrowphase collision detection (with triangles that actually overlap this sheered AABB), we transform only those triangle vertices using this sheer transform.

If you can share some basic geometry with sheered transforms etc (in a fileformat I mentioned before) that we can use in a Bullet demo, I'm more motivated to help out with this,
Thanks,
Erwin

[Beelzebub]

This sounds promising.
I cannot provide you with data though because they are property of the company I work for.
However there aren't any special data involved anyway.

The shear projection is accomplished by getting the normal of the terrain and modifying the (OpenGL) transform matrix:
shearTransform(0,2) = contact.normal[0] / contact.normal[2];
shearTransform(1,2) = contact.normal[1] / contact.normal[2];

Thanks for the great support so far!