New btInternalEdgeUtility has been added

User avatar
Erwin Coumans
Site Admin
Posts: 4182
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: New btInternalEdgeUtility has been added

Post by Erwin Coumans » Sun Feb 28, 2010 9:54 pm

sparkprime wrote: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
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: New btInternalEdgeUtility has been added

Post by sparkprime » Mon Mar 01, 2010 12:21 am

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.

User avatar
Erwin Coumans
Site Admin
Posts: 4182
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: New btInternalEdgeUtility has been added

Post by Erwin Coumans » Mon Mar 01, 2010 12:51 am

sparkprime wrote: 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
Posts: 17
Joined: Wed Feb 25, 2009 2:18 am

Re: New btInternalEdgeUtility has been added

Post by rknoesel » Wed Mar 03, 2010 5:05 am

JaZzBrE wrote: 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.
Erwin Coumans wrote: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!

User avatar
Erwin Coumans
Site Admin
Posts: 4182
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: New btInternalEdgeUtility has been added

Post by Erwin Coumans » Wed Mar 03, 2010 8:48 pm

rknoesel wrote: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
Posts: 26
Joined: Tue Oct 14, 2008 1:34 am

Re: New btInternalEdgeUtility has been added

Post by LEgregius » Thu Mar 04, 2010 4:41 pm

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.

User avatar
Erwin Coumans
Site Admin
Posts: 4182
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: New btInternalEdgeUtility has been added

Post by Erwin Coumans » Sat Mar 06, 2010 4:09 pm

LEgregius wrote: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
Posts: 6
Joined: Tue Aug 16, 2005 9:06 am
Contact:

Re: New btInternalEdgeUtility has been added

Post by obi » Wed Mar 10, 2010 12:59 pm

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
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: New btInternalEdgeUtility has been added

Post by sparkprime » Wed Mar 10, 2010 4:15 pm

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
Posts: 17
Joined: Sat Mar 13, 2010 10:08 pm

Re: New btInternalEdgeUtility has been added

Post by David20321 » Wed Mar 17, 2010 12:52 am

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
Posts: 16
Joined: Tue Jul 08, 2008 7:28 am

Re: New btInternalEdgeUtility has been added

Post by edl » Sun Apr 11, 2010 7:00 am

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
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: New btInternalEdgeUtility has been added

Post by sparkprime » Wed Oct 06, 2010 2:55 pm

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

User avatar
Erwin Coumans
Site Admin
Posts: 4182
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: New btInternalEdgeUtility has been added

Post by Erwin Coumans » Thu Oct 07, 2010 12:54 am

sparkprime wrote: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
Attachments
InternalEdgeDemo.zip
(3.96 KiB) Downloaded 278 times

sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: New btInternalEdgeUtility has been added

Post by sparkprime » Thu Oct 07, 2010 7:07 pm

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.

User avatar
Erwin Coumans
Site Admin
Posts: 4182
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: New btInternalEdgeUtility has been added

Post by Erwin Coumans » Thu Oct 07, 2010 8:52 pm

sparkprime wrote: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.
sparkprime wrote: 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

Post Reply