issue with softbody vs. custom concave shape

[gjaegy]

Hi,

I'm encountering an issue with Bullet internals, and I'm not sure what the best way to resolve it.

Basically, the issue is related to the collision between a rope (softbody) and a terrain, for which I've derived a class from btConcaveShape, overriding processAllTriangles() etc.

This derived class works well for rigid bodies, however, with soft bodies, I came across an issue.

Initially, I figured out each triangle of that custom concave shape gets turned into a convex hull made of the extruded triangle. This convex hull shape is then cached in btSoftBodyTriangleCallback::m_shapeCache.

However, my issue is that my terrain is huge (the Earth). The key used to index each triangle derived convex hull shape is made out of a single 32-bits integer, with 10 bits for the part ID, and the remaining 22 bits for the vertex ID.

This is clearly not sufficient for my purpose (we would need at least 64-bits if not more).

So, my initial (easy) solution was to call btSoftBodyTriangleCallback::clearCache() after each call to my custom class processAllTriangles(). This works, however, the performance penalty involved by the following line is huge (linear search):

Code: Select all

m_softBody->getWorldInfo()->m_sparsesdf.RemoveReferences(tmp->m_childShape);  //necessary?

Looking at the code, at a first glance it seems this line could potentially be removed and replaced by a regular call to btSparseSdf::GarbageCollect().

However, this doesn't really work, as in the case a new temporary triangle convex hull is being allocated at the same memory location as a previous destroyed shape, we might end up with a false positive test result in btSparseSdf::Evaluate() (since

Code: Select all

(c->pclient == shape)

would return true, as the pointers are the same, and the SDF of the previous shape with the same address will be used). This case would not happen very often, but it will (especially with some custom allocators).

So, right now I don't know how the solve that problem. I understand it's not straightforward.

The options I can see:
- increase the number of bits used to index into btSoftBodyTriangleCallback::m_shapeCache, although the ever growing scheme of that cache worries me a bit
- find a solution to make RemoveReferences() more efficient
- ?

Does anyone see any better way of tackling that problem ? Thanks a lot !

[drleviathan]

Every system has its limits and you are adventuring outside those of the softbody collision system. Meanwhile, if you constantly invalidate the softbody cache (which was probably introduced to speed things up) then it would not be too surprising to suffer consequences of poor performance.

Since you've already overridden the shape for the terrain, perhaps you would not be too shy to override the softbody cache (and/or collision system) to use a 64-bit keyed cache.

Meanwhile, I can't help but question the wisdom of using one giant shape for the Earth. Would it not be possible to break it up into a manageable set of smaller parts? Perhaps break it up such that 10-bit part-ID and 22-bit vertex-ID are sufficient.