GIMPACT v 0.2 Released

[projectileman]

Hi,
After a long time I've released the last update for GIMPACT.

This version is a total refactored from the previous (0.1). Works closely with the Bullet engine, and some of the new features are:

- More realistic and robust collisions.

- Support two side collision on both faces for a triangle. This is useful for non solid shapes, like deformable cloths .

- Works more closely with Bullet. It uses Bullet types and uses some bullet collision algorithms.

- C++ object oriented.

- Generic Bounding box Tree structure for colliding large sets of shapes (Compounds and Trimeshes) ; works similar to the btOptimizedBvh, but it has the capability of collide two Tree sets. Also supports Primitive Vs Node Collision for improving performance.

- Trimeshes work closely with the btStridingMeshInterface objects. Data won't be duplicated anymore, and many Bodies can share the same trimesh.

- Deformable Trimeshes.

- Extensible design.

I hope that it will be integrated to the Bullet SVN soon.
Please visitg the project page:

http://sourceforge.net/projects/gimpact/

You can download the lastest here:
http://sourceforge.net/project/showfile ... _id=515891


Regards!
Att:

Francisco León Aka Projectileman[/url]

[DevO]

Hi,

thank you very much!!!


I have tested it a bit in my system and it works well.

The only problem was Margin, it is set by default to 0.1 but in my system most object are 1.0 sized so this was too much.

After adding this to btGImpactMeshShape all problems seems to be solved.

Code: Select all

virtual void setMargin(btScalar collisionMargin)
{
	int i = m_mesh_parts.size();
	while(i--)
	{
		m_mesh_parts[i]->setMargin(collisionMargin);
	}
}

Regards,
DevO


EDIT2:

So I have setup 90 chained tori every with 416 triangles!

With GIMPACT 0.1 it runs with 15ms every frame and the chain is not beaked!

With GIMPACT 0.2 it runs with 40ms every frame and the chain will beak sometimes.


GIMPACT 0.1 will also create twice as many contact manifolds as 0.2 but still run faster and stabler.
This is strange....
Any idea???

DevO

[projectileman]

Hi DevO.
Thanks for your feedback.
About GIMPACT v0.2 performance...

So I have setup 90 chained tori every with 416 triangles!

With GIMPACT 0.1 it runs with 15ms every frame and the chain is not beaked!

With GIMPACT 0.2 it runs with 40ms every frame and the chain will beak sometimes.


GIMPACT 0.1 will also create twice as many contact manifolds as 0.2 but still run faster and stabler.
This is strange....
Any idea???

I felt it so. I think that it happens because GIMPACT_0.2 uses the GJK algorithm for triangle-triangle collisions, which could be slower and is more fragile for interpenetrations (In the chain you must set a bigger collision margin for avoiding break it out) .

However, there is an alternative low level collision method in GIMPACT_0.2, which is more similar to the previous GIMPACT implementations.

Just comment the line
#define BULLET_TRIANGLE_COLLISION 1 in the file btGImpactCollisionAlgorithm.cpp, and it will uses the other low level collision algorithm.

Please tell me how it works. I like to see your demo.

Att: Francisco

[Erwin Coumans]

With GIMPACT 0.2 it runs with 40ms every frame and the chain will beak sometimes.

Can you please provide a reproduction case for those tori inside the Bullet moving concave demo? It would be good to sort out this issue.
If you approve, we can include this in Bullet as a test case.

Thanks a lot,
Erwin

[DevO]

Thanks for you reply!

Unfortunately commenting out
#define BULLET_TRIANGLE_COLLISION 1
does not improve performance significantly.


Bigger collision margin will only increase distance between meshes but not prevent inter penetration.

I am using integration of Bullet in modeling software to create this scene, so the demonstration in Bullet moving concave is a bit difficult.

Does Blender support GIMPACT 0.2 ???
If yes then it must be easy to create some torus meshes and build small chain from it.

Of course it is possible that I am using GIMPACT 0.2 no in correct way but this was based on GIMPACT documentation!

[DevO]

Hello,

I have also done the same test with Bullet 2.56 ant it still do not work like GIMPACT 0.1.
But the collision looks different now!!!
I think there must be still another problem in new GIMPACT 0.2 integration...

[Erwin Coumans]

Can you be more specific?

Does GIMPACT 0.2 still fail in Bullet 2.56 release? And if so, how does it fail exactly?

Or is it just a performance issue? If so, can you give some performance comparisons?

Thanks,
Erwin

[DevO]

Yes in my test GIMPACT 0.2 still fail and do not collide as excepted.
The performance in my test on 64-Bit CPU is ~4 times slower as GIMPACT 0.1

I have simple scene with 5 torus chains and in every chain there are 18 torus
.
With GIMPACT 0.1 the chains can be rolled without any breaks.
With GIMPACT 0.2 the chains always break after some simulation frames.


Even in simple scenario with one rotated kinematic torus and one dynamic torus the bodies jitter and interpenetrates!

EDIT:
After many test this looks like problem with body CollisionMargin...


EDIT 2: The collision in GIMPACT 0.2 occur on distance = margin from actual triangle!
The chain only remains if Margin is as big as Torus pipe.
But in this case the simulation do not looks anymore plausible of course!

[DevO]

In GIMPACT 0.1 margin seems to be used to increase Bounding Box but not Triangle vs Triangle collision, is this correct?

In GIMPACT 0.2 margin seems to be used to do Triangle vs Triangle collision but not Bounding Box intersection????


Simple test:
Create static GIMPACT 0.2 Box 2x2x2 !
Create static GIMPACT 0.2 Box 1.5x1.5x1.5 above firs box !
Run simulation with time-step = 1/60!

The small box will collide with big box on distance 0.2 and jitter on it !

With GIMPACT 0.1 the boxes will near touch each other!

[projectileman]

Hi.

GIMPACT 0.1 could be faster but it has the limitation that it only support solid shapes ( Collisions on both sides of the triangles were forbiden, restricted only to the front side on each triangle). It carries problems with some shapes with wrong triangle winding order. Also it makes difficult simulating deformable meshes.

The GIMPACT 0.2 supports collision on both sides from the triangles because it uses the Bullet GJK algorithm for each triangle. But this method deppends of collision margins for avoid interpenetrations because triangles are not solid.

However GIMPACT 0.2 has been released with a bug, please take a look to this threat

http://continuousphysics.com/Bullet/php ... =5112#5112

There is a line which has to be mofified in the file gim_box_set.h, may it could solve the most problems here.

[DevO]

Hi,

thanks for you reply!

I have made my last tests with new Bullet 2.56 and fixed GIMPACT 0.2
but it unfortunately still do not work like version 0.1 .

May this support of both sides collision with triangles makes problems in simulating solid shapes.
For now Bullet is great for simulating solid not deformable shapes and
GIMPACT 0.1 is very well for it too.


But in my case I can not use GIMPACT 0.2 becouse the solid collision is not as stable as in version 0.1.

If default margin 0.1 is used then all collisions occurs on really great and visible distance because shapes are usually 1.0 unit big.
But smaller margin make things not much better.

I am not sure may be this a but in version 0.2 or may be this version was not created for solid shapes?

GIMPACT is great collision detection library and version 0.1 works great and fast with Bullet!!
Except some rare cases below...

The wrong triangle winding is not a big problem problem because it can fixed for most shapes and in most cases.

Is it difficult to make GIMPACT 0.1 like collision detection in version 0.2 available too???

regards,
DevO

[projectileman]

You are right DevO. If you need solid trimesh collisions, the GIMPACT 0.1 method is more well suited for this problem.

And yes, there is a way for make GIMPACT 0.2 working as same as GIMPACT 0.1.

So you must follow these steps.

1) Replace the code in the file gim_tri_collision.cpp with this code

Code: Select all

#include "GIMPACT/core/gim_tri_collision.h"


#define TRI_LOCAL_EPSILON 0.000001f
#define MIN_EDGE_EDGE_DIS 0.00001f


class _GIM_TRIANGLE_CALCULATION_CACHE
{
public:
	GREAL margin;
	GUINT clipped_count;
	btVector3 tu_vertices[3];
	btVector3 tv_vertices[3];
	btVector3 temp_points[MAX_TRI_CLIPPING];
	btVector3 temp_points1[MAX_TRI_CLIPPING];
	btVector3 clipped_points[MAX_TRI_CLIPPING];
	GIM_TRIANGLE_CONTACT_DATA contacts1;
	GIM_TRIANGLE_CONTACT_DATA contacts2;


	//! clip triangle
	GUINT clip_triangle(
		const btVector4 & tri_plane,
		const btVector3 * tripoints,
		const btVector3 * srcpoints,
		btVector3 * clipped_points)
	{
		// edge 0

		btVector4 edgeplane;

		EDGE_PLANE(tripoints[0],tripoints[1],tri_plane,edgeplane);

		GUINT clipped_count = PLANE_CLIP_TRIANGLE3D(
			edgeplane,srcpoints[0],srcpoints[1],srcpoints[2],temp_points);

		if(clipped_count == 0) return 0;

		// edge 1

		EDGE_PLANE(tripoints[1],tripoints[2],tri_plane,edgeplane);

		clipped_count = PLANE_CLIP_POLYGON3D(
			edgeplane,temp_points,clipped_count,temp_points1);

		if(clipped_count == 0) return 0;

		// edge 2

		EDGE_PLANE(tripoints[2],tripoints[0],tri_plane,edgeplane);

		clipped_count = PLANE_CLIP_POLYGON3D(
			edgeplane,temp_points1,clipped_count,clipped_points);

		return clipped_count;
	}




	//! collides only on one side
	bool triangle_collision(
					const btVector3 & u0,
					const btVector3 & u1,
					const btVector3 & u2,
					GREAL margin_u,
					const btVector3 & v0,
					const btVector3 & v1,
					const btVector3 & v2,
					GREAL margin_v,
					GIM_TRIANGLE_CONTACT_DATA & contacts)
	{

		margin = margin_u + margin_v;


		tu_vertices[0] = u0;
		tu_vertices[1] = u1;
		tu_vertices[2] = u2;

		tv_vertices[0] = v0;
		tv_vertices[1] = v1;
		tv_vertices[2] = v2;

		//create planes
		// plane v vs U points


		TRIANGLE_PLANE(tv_vertices[0],tv_vertices[1],tv_vertices[2],contacts1.m_separating_normal);

		clipped_count = clip_triangle(
			contacts1.m_separating_normal,tv_vertices,tu_vertices,clipped_points);

		if(clipped_count == 0 )
		{
			 return false;//Reject
		}

		//find most deep interval face1
		contacts1.merge_points(contacts1.m_separating_normal,margin,clipped_points,clipped_count);
		if(contacts1.m_point_count == 0) return false; // too far

		//Normal pointing to triangle1
		//contacts1.m_separating_normal *= -1.f;

		//Clip tri1 by tri2 edges

		TRIANGLE_PLANE(tu_vertices[0],tu_vertices[1],tu_vertices[2],contacts2.m_separating_normal);

		clipped_count = clip_triangle(
			contacts2.m_separating_normal,tu_vertices,tv_vertices,clipped_points);

		if(clipped_count == 0 )
		{
			 return false;//Reject
		}

		//find most deep interval face1
		contacts2.merge_points(contacts2.m_separating_normal,margin,clipped_points,clipped_count);
		if(contacts2.m_point_count == 0) return false; // too far

		contacts2.m_separating_normal *= -1.f;

		////check most dir for contacts
		if(contacts2.m_penetration_depth<contacts1.m_penetration_depth)
		{
			contacts.copy_from(contacts2);
		}
		else
		{
			contacts.copy_from(contacts1);
		}
		return true;
	}


};



bool GIM_TRIANGLE::collide_triangle_hard_test(
		const GIM_TRIANGLE & other,
		GIM_TRIANGLE_CONTACT_DATA & contact_data) const
{
	_GIM_TRIANGLE_CALCULATION_CACHE calc_cache;
	return calc_cache.triangle_collision(
					m_vertices[0],m_vertices[1],m_vertices[2],m_margin,
					other.m_vertices[0],other.m_vertices[1],other.m_vertices[2],other.m_margin,
					contact_data);

}

2) In the file btGImpactCollisionAlgorithm.h comment the line 29 where is the define : #define BULLET_TRIANGLE_COLLISION 1

3) Assign a 0 value collision margin for trimeshes by default. In the file btGImpactShape.h in the line 390 assign m_margin = 0.0f

With these steps I hope you can make GIMPACT 0.2 working as same as before.


By default GIMPACT 0.2 uses the Bullet GJK collision system for colliding triangles but it could be changed for using the alternative low level collision system. The file gim_tri_collision.cpp just contain the old low level routine for colliding triangles.

Currently I'm making some research in better collisioin algorithms, for example searching methods for Tetrahedrization for decompose trimeshes in convex shapes. May be you can suggest a better approach.

About your Chain sample, Can you send me that demo? Thanks.

Good luck.

Att: Francisco León.

[DevO]

Hello León!

Thanks for this!!!
This seems to make GIMPACT-0.2 behavior just like GIMPACT-0.1 !
Unfortunately GIMPACT-0.2 is still about 4 times slower as 0.1 !

Please look at this demo GimpactTestDemo_DevO_09.18.2007.zip
Replace btGImpactShape.h with on from this ZIP and look how it works then.

With old btGImpactShape.h you can see really big distance if torus collide another torus.
With new the collision is not more stable.


@Erwin: Can you please add this Demo to the next Bullet release!?


DevO

[projectileman]

Thanks a lot DevO.

That helps me improving the GIMPACT library.
Currently I'm refactoring the bvh collision algorithm for getting better performance even than GIMPACT 0.1.

So thanks, that saves me time.

[DevO]

Well if you need some other examples just ask for it.

Wit system are you using for testing ???
I am working on Win64 and this example run 2x faster if compiled for x64.

Suggestion, can you please add GIMPACT 0.1 like collision to 0.2 !?
May be as separate class, so it can changed during runtime for comparison!

Or even select right way for specific model, Torus with 0.1 like system and Plane with 0.2 like system.


So as I understand collision in GIMPACT 0.1 and 0.2 work like in the picture below.
Is this correct???