GIMPACT 0.3 in Bullet 2.63 preview

[Erwin Coumans]

This is work in progress and not a final 2.63 release, but for the ones who are interested in a preview of GIMPACT 0.3 in Bullet 2.63, please try out and give some feedback on this preview:

http://bulletphysics.com/ftp/pub/test/i ... eview2.zip

Thanks!
Erwin

[DevO]

Thanks for releasing this new GIMPACT version!!!
It work pretty stable now!

Some small problems remains.
It is about 2 times slower as GI 0.1 for meshes with less as about 1000 triangles.
But it is faster, sometimes more as 3x faster for meshes with several thousands of triangles, this is great!

Another problem with all GIMPACT version is the Inertia Tensor calculation.
As I understand only mesh points are use to calculate it.
So if you mesh has more point is some parts then of course this part will become more heavy as another parts.
Using Volume Integration like this is more suitable for meshes.
http://www.melax.com/volint.html
I will try to post this integration once it is ready...

Another question is how to get Tree depth from btQuantizedBvhTree class ???

What are differences between Bullets btOptimizedBvh and GIMPACs btQuantizedBvhTree ???

Thanks!

[projectileman]

Of cource, the Inertia tensor algortithm is not perfect, indeed.

Currently I'm working on an algorithm that calculates exact inertia by integrating the inertia fraction from each triangle. Really it is already implemented, but it won't be released until the next version of GIMPACT 0.4.

And, have you ever tried the convex decomposition? It will surprise you about how faster it could be. 6 times faster than GIMPACT 0.1. Also it has a better calculation of inertia.

About btQuantizedBvhTree, is not far different than btOptimizedBvh except that btQuantizedBvhTree supports Tree vs Tree collision and also it is supported in compound shapes too (btOptimizedBvh only supports trimeshes).

If you want I recommend you to integrate the Melax algorithm for calc the inertia, also I was planning to do it too.

I won't give you details about how will be GIMPACT 0.4, but I'm planning to implement Tetrahedrization, and who knows ... an improved collision system.

I want to see your test framework... colliding huge trimeshes seems too interesting for me, may we could share our experiences.

If you want to chat with me, we could meet at MEEBO. This is my Chat room
http://wwwl.meebo.com/room/gimpactroom/

Regards.

[Remotion]

Hello to all.

Here is my adaption of code from http://www.melax.com for GIMPACT 0.3.
If you want then you can use it.

regards,
Remotion

[DevO]

Thanks.

I am already using Convex Decomposition and it work well in some cases but in other cases using full meshes is more suitable.
You have added this new btGImpactConvexDecompositionShape to GIMPACT 0.3 and it work well too.
The only problem it creation is too slow to be used in my application.
Unfortunately Convex Decomposition is really slow, I am also looking for the ways to meka it faster now...


regards,
DevO

[projectileman]

I am already using Convex Decomposition and it work well in some cases but in other cases using full meshes is more suitable.

That's true. Convex Decomposition are only suitable for static solid objects. btGImpactConvexDecompositionShape is not an extraordinary thing, except that it uses the btQuantizedBvhTree class for sorting shapes internally. That could speed up the collision process.

About the little slowdown with trimeshes when comparing with GIMPACT 01, I think that it could be caused due of the Quantization/Unquantization process. May the quantized nodes use less space and are memory aligned, but I also noticed that it is a little slower. (2X ?? too much, your machine is a little strange In my 32bit pentium it doesn't happen)

[DevO]

That's true. Convex Decomposition are only suitable for static solid objects.

Why only for static meshes???
I am using it for dynamic meshes and it works well.
But as said before it is pretty expensive to use Convex Decomposition on the fly.
Probably one reason for this is slow Brute Force BestFitOBB routine.
Do some one know faster way to do it beside covariance?
Or may be just make this code using SIMD

2X ?? too much, your machine is a little strange In my 32bit pentium it doesn't happen

Well I have done most of my test on Core-2 Duo 2.4 GHz CPU in 64-bit mode.

[projectileman]

So Multi-core processors work very different.

hmmm... it seems that I need to purchase a new PC.

Also I'm starting to thinking that my laptop has a fake P4 processor... SIMD doesn't seems impressive for me... sometimes I have similar results with plain Bullet Linear Math...

[DevO]

As I know CPUs with older architectures as "Intel Core" need some cycles for most of SSE operations, in "Core" this should be more optimized.

Well I need to test this on my older laptop too and see how big will be differences there!