Larger Tri-Mesh triangles can be walked through.

[GoogleCodeExporter]

Create a TriMesh like:  (pyramid) Object A
vertexList
Microsoft.Xna.Framework.Vector3[16]}
    [0]: {X:1.78321 Y:1.78321 Z:-1.783479}
    [1]: {X:1.78321 Y:-1.78321 Z:-1.783479}
    [2]: {X:-1.78321 Y:-1.78321 Z:-1.783479}
    [3]: {X:-1.78321 Y:1.78321 Z:-1.783479}
    [4]: {X:0 Y:0 Z:1.783479}
    [5]: {X:0 Y:0 Z:1.783479}
    [6]: {X:0 Y:0 Z:1.783479}
    [7]: {X:0 Y:0 Z:1.783479}
    [8]: {X:-1.78321 Y:-1.78321 Z:-1.783479}
    [9]: {X:0 Y:0 Z:1.783479}

indexList 
{int[256]}
    [0]: 0
    [1]: 1
    [2]: 2
    [3]: 3
    [4]: 0
    [5]: 2
    [6]: 4
    [7]: 5
    [8]: 6
    [9]: 4
    [10]: 6
    [11]: 7
    [12]: 4
    [13]: 2
    [14]: 1
    [15]: 4
    [16]: 1
    [17]: 5
    [18]: 5
    [19]: 1
    [20]: 0
    [21]: 5
    [22]: 0
    [23]: 6
    [24]: 6
    [25]: 0
    [26]: 3
    [27]: 6
    [28]: 3
    [29]: 7
    [30]: 7
    [31]: 3
    [32]: 8
    [33]: 7
    [34]: 8
    [35]: 9
    [36]: 9
    [37]: 8
    [38]: 2
    [39]: 9
    [40]: 2
    [41]: 4

and a box with halfextents 0.2  Object B

Rotate the tri-mesh 180 degrees on any horizontal axis

Box can move through the solid surfaces where there is no vertex near. Except 
for the rectangle base which is facing towards 'up'.

What version of the product are you using? On what operating system?
r9

Please provide any additional information below.
It looks like the box(Object B) is only colliding with the verticies and edges 
of Object A but missing collisions on surfaces facing 5 out of 6 directions 
where Object B isn't coming into direct contact with a vertex.

(object A)Tri-mesh, w/0 mass, with less space between the vertices work better 
because the RigidBody with mass(object B) collides with the vertices and edges 
even though it fails to collide with the surfaces.

Original issue reported on code.google.com by dcoliva...@gmail.com on 15 Apr 2011 at 2:02

[GoogleCodeExporter]

Another way to say it is...    you can drop a smaller object through the inner 
part of a large triangle in some directions in a Tri-Mesh.

Original comment by dcoliva...@gmail.com on 15 Apr 2011 at 2:05

[GoogleCodeExporter]

See attached picture.

Original comment by dcoliva...@gmail.com on 15 Apr 2011 at 2:11

Attachments:

• Tri_mesh_passthrough.jpg

[GoogleCodeExporter]

Thanks Dan, just building this in c++ bullet to test.
can you confirm the collision flags and masses that you have for for objects A 
& B please?

Thanks

Original comment by xexu...@gmail.com on 15 Apr 2011 at 1:52

[GoogleCodeExporter]

A is the Pyramid.  It's 0 mass.    Static Rigid Body.
B is the cube.   It's 1.25000083

Here's a video of the results.

http://www.youtube.com/watch?v=kAYcFdpVhIU

The collision flags are the default collision flags.

Original comment by dcoliva...@gmail.com on 17 Apr 2011 at 7:00

[GoogleCodeExporter]

Thanks . can you try with the updated MathUtil.cs

Original comment by xexu...@gmail.com on 17 Apr 2011 at 9:14

[GoogleCodeExporter]

I did update as requested.   The following video demonstrates that it is not 
currently resolved. http://www.youtube.com/watch?v=-HYoQN_t_WM

Again, the avatar is represented by a capsule.

Original comment by tera...@gmail.com on 18 Apr 2011 at 12:14

[GoogleCodeExporter]

Another video, this one, pretty close to succeeding... 
http://www.youtube.com/watch?v=pX6yfQP9AhU

Original comment by dcoliva...@gmail.com on 19 Apr 2011 at 8:14

[GoogleCodeExporter]

http://www.youtube.com/watch?v=bdZF1el3ttM , This tube was unstable, but 
successful

Original comment by dcoliva...@gmail.com on 19 Apr 2011 at 8:14

[GoogleCodeExporter]

Thanks. still looking at it, spent a while last night trying to narrow down the 
conditions. First fix for MathUtil seemed to resolve the issue when the initial 
pyramid was yawed 180 deg. current situation is pitched down 90 deg (falling 
and colliding on the square base of the pyramid). I need to try it with some 
other collision shapes to try isolate issues. Can be fairly painful debugging 
this as the c++ floats and c# ones are always 'slightly' different so a lot of 
noise to check through.

Original comment by xexu...@gmail.com on 19 Apr 2011 at 8:18

[GoogleCodeExporter]

Here's a successful video of a (SphereShape)sphere going down the inside of a 
set of hollowed out (TriangleMeshShape)tori with the circular path twisted.
http://www.youtube.com/watch?v=P5EN-d4C1d0

Looks like the angular velocity on the sphere isn't quite right in the video 
while in the tori..  but the issue hasn't been isolated specifically to the 
physics engine (EX, That could be an issue with the integration code)

Original comment by dcoliva...@gmail.com on 20 Apr 2011 at 2:11

[GoogleCodeExporter]

Did some more testing last night on the pyramid/cube collision fail. Can 
re-create it, but not pin it down yet. Tired sphere/pyramid, capsule/pyramid 
and cylinder/pyramid and they seemed to collide correctly. Will keep you 
updated.

Original comment by xexu...@gmail.com on 20 Apr 2011 at 8:22

[GoogleCodeExporter]

Original comment by xexu...@gmail.com on 24 Apr 2011 at 9:19

• Changed state: Accepted

[GoogleCodeExporter]

I'm still studying this issue.   Just a FYI.    So far, it looks like the line 
that's going 'awry' is:

if (AabbUtil2.TestTriangleAgainstAabb2(triangle,ref m_aabbMin,ref m_aabbMax))

inside TriangleMeshShape.cs NameSpace 
BulletXNA.BulletCollision.CollisionShapes.FilteredCallback.InternalProcessTriang
leIndex.

We know it's trying to compare an AABB to a triangle.    The issue is the test 
is returning false on some faces.   The test occurs when the avatar's CapsuleZ 
is within the AABB of the object..   which is proper..   but returns false when 
it should return true.

Original comment by dcoliva...@gmail.com on 3 Jun 2011 at 4:25

[GoogleCodeExporter]

After studying this, It's looking more like an integration code problem.

The last 9 triangles are copies of the 4th triangle.

Original comment by dcoliva...@gmail.com on 3 Jun 2011 at 5:41

[GoogleCodeExporter]

btshapeArray = new TriangleIndexVertexArray(IndexCount / 3, indexels, (3 * 
sizeof(int)), VertexCount, vertexels, 3 * sizeof(float));

to

btshapeArray = new TriangleIndexVertexArray(IndexCount / 3, indexels, 3, 
VertexCount, vertexels, 1);

and that seems to fix most of the issues.    There's still an issue or two on 
some of the more complex objects... and, for the most part it seems to be 
working well.

Original comment by dcoliva...@gmail.com on 3 Jun 2011 at 6:26

[GoogleCodeExporter]

Thanks Dan. 
I need to go through and standardise the whole use of stride counts in the 
various parts of the code as it's rather 'organic'

I think that for now I'll support float arrays and Vector3 arrays / 
objectarrays for vertex data and just int types for index data. 

Would this fit in with the way you use it, or are there other forms of data 
you'd like to use?

Original comment by xexu...@gmail.com on 3 Jun 2011 at 12:34

[GoogleCodeExporter]

I tend to use float[]/int[] where float[] is a lookup array, int[] contains a 
strided/ordered index and a vertex is composed of 
<float[int[x]],float[int[x+1]],float[int[x+2]]> and a triangle consists of 
x=tri*vertex. 

I note, that that isn't always the most optimal way to manage it memory-wise.   
Some people prefer to use a smaller bit space because of simplicity when 
dealing with a data format or limited memory space.

To ensure compatibility with native c++ libraries, I tend to create the arrays 
and pin them in memory so .NET doesn't move them around.   

My Current snippet looks like:
IMesh mesh = Mesher.CreateMesh(shapeData);

float[] vertexList = mesh.getVertexListAsFloatLocked(); // Note, that 
vertextList is pinned in memory
int[] indexList = mesh.getIndexListAsIntLocked(); // Also pinned, needs release 
after usage
mesh.releaseSourceMeshData(); // free up the original mesh data to save memory

int VertexCount = indexList.GetLength(0) / 3;
int IndexCount = indexList.GetLength(0);

ObjectArray<int> indexels = new ObjectArray<int>();
for (int i=0;i<IndexCount;i++)
{
    indexels.Add(indexList[i]);
}

ObjectArray<Vector3> vertexels = new ObjectArray<Vector3>();
for (int i=0;i<VertexCount;i++)
{
    vertexels.Add(new btVector3(vertexList[i * 3], vertexList[(i * 3) + 1], vertexList[(i * 3) + 2]));
}

btshapeArray = new TriangleIndexVertexArray(IndexCount / 3, indexels, 3, 
VertexCount, vertexels, 1);

(I came up with this quick set of loops to enter the array data into the object 
array list that the constructor for TriangleindexVertexArray is expecting.)

Original comment by dcoliva...@gmail.com on 3 Jun 2011 at 2:21

[GoogleCodeExporter]

A few tri-mesh videos: 
http://www.youtube.com/watch?v=bHSnIswAZ8U <-- sphere traversing tri-mesh course
http://www.youtube.com/watch?v=ubNawFkLMCM <-- obligatory 'run through wall' 
test.
http://www.youtube.com/watch?v=de73aywRxWQ <-- 112 cube boxstack test.

Original comment by dcoliva...@gmail.com on 4 Jun 2011 at 12:14

[GoogleCodeExporter]

Updated MathUtil.cs - fixes the fallthrough - at least in my testbed. Can you 
give it a try when you get chance please.

Original comment by xexu...@gmail.com on 5 Jun 2011 at 8:19

[GoogleCodeExporter]

For the most part, this seems to be resolved for TriangleMeshShape.

I noticed another issue, however that might be related where it doesn't apply 
enough resolution force to keep the objects apart and one falls through the 
other.   Note that this is cubes and spheres on the inside of a hollow half 
sphere concave tri-mesh.

This may be worthy of a separate bug.   Let me know.

Here's a video of it in action:
http://www.youtube.com/watch?v=Ty0R-7eI4Lk

Original comment by dcoliva...@gmail.com on 7 Jun 2011 at 6:05

[GoogleCodeExporter]

yup , if you put that as a separate issue that would be good thanks. as ever if 
you have any details on the models / collisions objects that would be handy as 
well.

ta

Original comment by xexu...@gmail.com on 8 Jun 2011 at 4:00