New btInternalEdgeUtility has been added

[Erwin Coumans]

The problem is that I'm using compounds containing bvh mesh data as well as other primitives. I am using this hack locally to fix this problem. I suggest you at least put in the assert and that you consider redesigning things at some point in the future to make Bullet less fragile for this kind of use case. I really think a 'bvh of primitives' is the way forward, it's much simpler, more powerful, and more robust than the current collision shape system.

The btCompoundShape is indented for convex child shapes only, or recursive btCompoundShape. Anything else is not not supported.

We can look into this by adding two 'addChildShape' methods, one that only accepts a btConvexShape and another that only accepts btCompoundShape.

I updated today and now I get a segfault here

Code: Select all

  if (colObj0->getCollisionShape()->getShapeType() != TRIANGLE_SHAPE_PROXYTYPE)
                return;

I wonder why the segfault? There is a check for anything else than btBvhTriangleMeshShape in the callback. What went wrong?

Thanks,
Erwin

[sparkprime]

The shape was a triangle, the root shape was a compound object -- in other words it 'skipped over' the triangle mesh in the middle. Because the cast was not guarded it type-punned the compound to the triangle mesh and then the triangleMeshInfo pointer was garbage. I added an assert to check the root shape was a triangle *mesh*, you can see it in my patch.

The whole design of compound shapes is broken in my opinion. It allows things that don't make sense, like a compound of triangles, or a compound of compounds... What you propose with the second addChild would help I think, but I would go much further and get rid of compound shape and bvh triangle mesh altogether. They both support BVH and it's just confusing. Just have a shape in which you can put primitives (including triangles) and have it store triangles specially on the inside. Have an extra child addition API for sucking in vertex/index lists efficiently. Then there is no nesting possible so these kinds of problems are avoided and yet you can still do everything you can do now. Also the API is simpler.

[Erwin Coumans]

but I would go much further and get rid of compound shape and bvh triangle mesh altogether. They both support BVH and it's just confusing. Just have a shape in which you can put primitives (including triangles) and have it store triangles specially on the inside. Have an extra child addition API for sucking in vertex/index lists efficiently. Then there is no nesting possible so these kinds of problems are avoided and yet you can still do everything you can do now. Also the API is simpler.

The btQuantizedBvh in a btBvhTriangleMeshShape is optimized for static geometry, whereas the btDbvt in btCompoundShape can handle dynamic changes (including adding, removing or changing child shapes). And some people like the option to use recursive btCompoundShape.

We want to keep the Bullet 2.x API stable, but we consider changes for the Bullet 3.x API.

Still, our focus is not to nail down every possible mis-use of the Bullet API, so there will likely always be certain ways to intentionally mis-use the API. If you are not happy with this, it might be better if you write your own physics engine or look for an alternative,

Thanks,
Erwin

Discussion about recursive compounds is split and continued in this topic:
http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=4802

[rknoesel]

I've managed to save btTriangleInfoMap into our resource file now, with no bullet hacks, I just had to find a way to de-private the class (which is writing a bit hacky public class that looks the same as btHashMap, and just casting it). On build time I just endian swap the data and save, and on load time I use the initializeFromBuffer on the four arrays.

Just want to give a heads up to anyone else choosing to serialize the btTriangleInfoMap themselves: Make sure that the deserialized m_valueArray.m_capacity matches the original because the capacity() member function is used as part of the hash calculations. In my first attempt I only handled the size and didn't worry about the capacity, resulting in the hash lookups failing for meshes with non-power of 2 hash table sizes.

Ok, btHashMap data is now protected (not private anymore), and some more preparations for btTriangleInfoMap serialization: http://code.google.com/p/bullet/source/detail?r=2025

Thanks, this was very useful!

[Erwin Coumans]

Just want to give a heads up to anyone else choosing to serialize the btTriangleInfoMap themselves: Make sure that the deserialized m_valueArray.m_capacity matches the original because the capacity() member function is used as part of the hash calculations. In my first attempt I only handled the size and didn't worry about the capacity, resulting in the hash lookups failing for meshes with non-power of 2 hash table sizes.

Good point, we missed that one too in the current Bullet implementation of

SIMD_FORCE_INLINE void btTriangleInfoMap::deSerialize(btTriangleInfoMapData& tmapData )

So we better serialize the capacity and "reserve" this value to make sure the capacity is the same, an issue is filed.

Thanks for the feedback!
Erwin

[LEgregius]

If concave shapes may not be added to a compound, is there a way to make a compound concave shape? Also, is there a way to transform a concave shape relative to the collision object?

In 2.75, i was using btCompoundShape to do that with concave shapes, but now I get collision detection anomalies, and I want to use the internal edge tool.

[Erwin Coumans]

If concave shapes may not be added to a compound, is there a way to make a compound concave shape? Also, is there a way to transform a concave shape relative to the collision object?

If you add several convex shapes to a btCompoundShape it will easily become a concave shape.

Also, is there a way to transform a concave shape relative to the collision object?

For static world geometry, using a btBvhTriangleMeshShape, it makes most sense to just use the object's world transform.
Or is your question mainly about btGImpactTriangleMeshShape?

In 2.75, i was using btCompoundShape to do that with concave shapes, but now I get collision detection anomalies, and I want to use the internal edge tool.

What kind of anomalies/issues? Can you reproduce them in one of the Bullet demos?
Thanks,
Erwin

[obi]

I'm getting weird contacts from triangle mesh<->capsule collision. The capsule represents player and triangle mesh is our terrain. In specific case when capsule gets pushed against wall with ledge on top there will be two contacts created: wall contact (with y element == 0) and surprisingly ledge contact with normal pointing up (almost 0,1,0) positioned in the middle of the capsule. We are using bullet 2.74 with "unwanted internal edge cd removal" applied manually. Is this something that I should expect? Could it be penetration issue, or it might have something to do with unwanted internal edges?

[sparkprime]

I have noticed some strange behaviours with a compound of primitives and hulls penetrating a relatively bumpy trimesh floor, but i haven't pinned down the cause yet even in my own engine, let alone something independently testable. It's quite hard to reproduce but when it happens it's quite severe. Will keep you posted...

[David20321]

In my brief tests it looks like that could be caused by the two-sided triangles -- sometimes my ragdolls will get stuck halfway through an object because some objects are being pushed out by the correct side, and some are being pushed in by the incorrect side. In ODE this didn't happen for me because (I think) when half of the ragdoll penetrated an object, it would fix itself by pushing the intersecting objects out in the correct direction.

[edl]

One question.

recently,i patch my bullet libs with 2.75-beta2 for the PS3.after some work, I find it is hard to make PELowLevelBroadphaseSPU and PELowLevelConstraintSolverSPU work, when i open the macro
#define LLBP 1
#define LLCS 1
the program always run into a spu request loop,(after a while i find it maybe cause by some other libs used in my project), so temporary, i only open the macro USE_SPU_PARALLEL_COLLISION_DISPATCHER, only use
"BulletCollisionSpursSupport ""SpuGatheringCollisionDispatcher" for my program, then i find the ContactAddedCallback not work at all, and i didn't know how to make SpuContactResult work, and even i make it work, is it possibe to make the btInternalEdgeUtility work?

i read the following thread,i am puzzled.

http://www.bulletphysics.org/Bullet/php ... U&start=15
http://www.bulletphysics.org/Bullet/php ... SPU#p17894

[sparkprime]

here is a reproduction case for my problem, provided as a patch on the internal edge demo.

If you run the demo, the box should be (mostly) stable. Press 'n' to enable edge adjustment and the box will fly off. The demo is running at 1000hz and 1/10 speed in order to show the behaviour more clearly.

Since the forum won't allow uploads with extension '.diff' or '.patch' or '.txt' I've given up and put the patch in a pastebin

http://codepad.org/0dV8U7Np

[Erwin Coumans]

here is a reproduction case for my problem, provided as a patch on the internal edge demo.

Thanks for the reproduction case. This forum accepts zip files, see attached.

It looks like a fairly degenerate triangle mesh: very long triangles with sides thinner than the m_edgeDistanceThreshold (0.1 by default). It seems that decreasing this threshold removes the problem:

Code: Select all

btTriangleInfoMap* triangleInfoMap = new btTriangleInfoMap();
triangleInfoMap->m_edgeDistanceThreshold = 0.01f;

Would automatic detection and adjustment of this edgeDistanceThreshold for such degenerate geometry help, or does your problem also happen with better quality triangle meshes?
Is the triangle winding consistent, so that all normals point outwards?
Thanks,
Erwin

[sparkprime]

Thanks for your reply, I'll try out this fix in the whole engine and see how much misbehaviour it fixes. I'll need to come home from work first though

Certainly I've been using a lot of triangles of less than that, since that is only 10cm it's not really fair to call it degenerate. Especially if you are suggesting people use graphical meshes as physics meshes. A very large number of things in a typical 'people scale' simulation are going to need triangles < 10cm large. Fences, trees, curbs, signs, doors, posts, rails, staircases, tables, etc. I'm sure for some simulations this is too small but for the default case it should not be.

[Erwin Coumans]

Certainly I've been using a lot of triangles of less than that, since that is only 10cm it's not really fair to call it degenerate. Especially if you are suggesting people use graphical meshes as physics meshes.

Degenerate as in a 'sliver' with one side of the triangle much longer than another side.

A very large number of things in a typical 'people scale' simulation are going to need triangles < 10cm large. Fences, trees, curbs, signs, doors, posts, rails, staircases, tables, etc. I'm sure for some simulations this is too small but for the default case it should not be.

The internal edge utility was designed to make sliding along internal triangle edges of bigger surfaces such as roads and walls smooth. All of above objects will cause problems, because the size of a triangle side or distance between front and back of triangles is closer than the m_edgeDistanceThreshold.

We need a better way to only select the meshes/edges that require the internal edge utility. Possibly serialization of the internal edge data would help.
Thanks,
Erwin