Collission Issue with Cylinders

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use attached files to reproduce failing collision between frustum and 
cylinder
2.
3.

What is the expected output? What do you see instead?
There should be a contact response for the two objects but instead there is not 
any.

What version of the product are you using? On what operating system?
Windows 7 x64, bullet-2.82-r2704

Please provide any additional information below.
I have a couple of objects in my world ranging from 3D points, cylinders, 
cones, spheres,circles etc...

When performing single click, instead of ray casting I create a rectangle of 
10x10 pixels centered on the mouse click in order to increase the selection 
area. From this rectangle I get the 4 x near and 4 x far frustum 3D points from 
opengl and create a convex. Then perform collision detection of the convex 
object and my object in this case cylinder.

What I have seen is that I can click on the cylinder and it will most of the 
times be OK, however there will be locations on the cylinder that I essentially 
get no contact.

If I click on the surrounding pixels of the one that fails, everything is fine 
so its pretty weird that in a specific location I dont get a contact while when 
click somewhere really close all is good.

There might be more shapes affected from what I remember but will have to find 
them and reproduce them.

Just as a screenshot example I am providing the frustum and cylinder collision. 
As I said, if I click on any of surrounding pixels everything is fine.

The screenshot is different from the attached reproduction case as I was trying 
to simplify as much has possible. This, I have hard-coded the frustum and 
cylinder values as that was simpler for me to provide than creating cameras 
taking care of rotations etc...

Could it be a degenerate case ?

Original issue reported on code.google.com by xstamato...@gmail.com on 1 Mar 2014 at 1:34

Attachments:

• CollisionWorldSelectionDemo.rar
• Fail.png

[GoogleCodeExporter]

Likely a known issue introduced in recent Bullet 2.82.
https://github.com/erwincoumans/bullet3/issues/34

Can you revert to old behaviour?
resultCallback.m_flags |= 
btTriangleRaycastCallback::kF_UseSubSimplexConvexCastRaytest;

Original comment by erwin.coumans on 1 Mar 2014 at 1:38

• Changed state: Duplicate
• Removed labels: Type-Defect

[GoogleCodeExporter]

That is for a single ray casting though right ?
What if you do dynamicsWorld->contactTest(frustrumCollisionObj, callback);

where callback is a class derived from btCollisionWorld::ContactResultCallback.
There is no flags to set in that case unless I am totally misunderstanding 
something.

Original comment by xstamato...@gmail.com on 1 Mar 2014 at 6:35

[GoogleCodeExporter]

I skimmed your explanation, saw the word 'ray test. with a picture of ray 
versus cylinder, hence the mis assumption. Re-opened, but cannot promise when I 
have time to look at it.  Why is the ray in the screenshot?

Original comment by erwin.coumans on 1 Mar 2014 at 6:51

• Changed state: New

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Its actually the frustrum convex hull, but because its really small in width (i 
get the pixel coords and essentialy create a 10x10 pixel rectangle centered on 
the mouse click) it looks like a ray.

I did quickly test it with ray casting though and it performs way better that 
contactTest which really misses a lot of contacts all around the area of the 
cylinder.

The ray casting also missed a couple but it seems that if you revert to the old 
behaviour as you said you get them all.

Original comment by xstamato...@gmail.com on 1 Mar 2014 at 7:09

[GoogleCodeExporter]

Perhaps GJK or EPA fails with very long thin objects, indeed. Thanks for a 
reproduction, it would be nice to fix it.

Original comment by erwin.coumans on 1 Mar 2014 at 7:30

[GoogleCodeExporter]

moved to github https://github.com/bulletphysics/bullet3/issues/53

Original comment by erwin.coumans on 30 Mar 2014 at 4:47

• Changed state: Done