[Solved] Softbody mesh has seams

[turanszkij]

I have implemented bullet physics into my game. I use softbodies for cloth simulation and it worked nicely in some cases. I generate softbodies from traingle meshes with btSoftBodyHelpers::CreateFromTriMesh however, in my latest model, there are seams in the mesh while running the simulation.
The mesh normally:

a.png (117.49 KiB) Viewed 7434 times

The problem:

b.png (162.35 KiB) Viewed 7434 times

I also noticed that these seams occur along texture seams in the mesh. Seams also occur where my normals are per face. In these cases, I generate extra vertices (making extra faces) into the model for the extra information, and I think this causes these problems. How should I tackle this, or how is it usually tackled? Does the order of the vertices matter here or should I add some extra parameters while generating the softbody?

An earlier demo video with some working meshes:
https://www.youtube.com/watch?v=yLQXmm5Q5zs

[Flix]

It's been a long time since I last used btSoftBodies... (BTW: I stopped using them mainly because they don't seem to go to sleep AFAIK, and collisions are not reported through the normal collision manifold processing (still AFAIR)).

I haven't read a single line of the code you posted (lazy me ), however I remember that what you're experiencing it's absolutely normal.

It depends on how graphic meshes are processed: a vertex that is has 2 different texture coordinates or two different normals (or two different "everything") is actually turned into two vertices with the same position coordinates before going to the graphic card. This has some consequences:
1) the number of vertices grows if you use them for physics (sometimes a factor of 2x or 3x!). That can limit peformance.
2) the connection (topology) of the mesh changes, leading to the behavior you're experimenting (cloth slicing).

In the case of soft bodies, the trick is write some piece of code that:
1) removes duplicated vertices creating a reduced set of single vertices/indices to feed Bullet.
2) makes a map between the full set of (possible duplicated vertices) and the new set of single vertices.
This way you can still forward the changes to the "old set", preserving texture coordinates.

P.S. Since Bullet calculates the normals for you, it's not good to keep per vertex normals IMH: just keep per-vertex textures if needed (trying to minimize them if possible).
P.S.2. This topic is not Bullet-specific (every physic engine is affected).
P.S.3. Nice videos .
P.S.4. Nice console

[Edit:] Found a very old post of mine on this forum with the same topic (I was using Ogre at that tme ): http://www.bulletphysics.org/Bullet/php ... it=mapping. Actually it's a bit old, but I remember that the best way to map vertices was:

In order to achieve step 1, you could for example move the double vertices to the end of the mesh (updating the indices and reoptimizing them at the end by shuffling them with an Ogre API method). This way you have a mesh that you can more easily split to feed the Ogre engine and update back from Bullet to Ogre (by assigning to the last vertices the correct values).

I believe this is one of the easiest way of doing it (although it is NOT easy at all IMO), because you can just use a std::vector< unsigned short > to map the last vertices of the mesh with the "single" ones at the beginning and you don't need to use any std::map<> at all.

Hope it helps.

P.S. If you mesh has multiple submeshes, you need to move all the vertices to the "shared vertices" area, updating the indices, before starting step 1.

Unluckily the code I used to perform these steps has probably gone lost when I lost my Window partition some year ago (I' using Linux now...). So I cannot share it Sorry.

[turanszkij]

Thank you Flix, I will try to implement your idea, to keep a separate mesh for physics and link the vertex positions/normals with the renderable mesh. I was hoping for some setting in the api which helps with this issue. I tried deleting th uv-map from the mesh and that way it works perfectly, however, I can't map a texture to it that way (in a gpu-efficient way).

[Flix]

I was hoping for some setting in the api which helps with this issue.

Well unluckily there's no universal way to define a "graphic mesh". These's a more universal way to define a "physic mesh" (= vertices + (triangle) indices). What I mean is that any graphic engine/program can define vertices and attributes (texcoords, normals, tangents) in a different way (for example separate arrays for positions,normals,texcoords, or a single array of vertex structs with one position, its normal, its texcoord, its tangent, and so on).

The methods you want to write depend on your own "graphic mesh" logic (they won't work for all kind of graphic meshes, although a small degree of generalization can probably be achieved using tamplates).

I will try to implement your idea, to keep a separate mesh for physics and link the vertex positions/normals with the renderable mesh.

I remember I split the algo into two parts, because removing duplicated vertices, without any mapping, can be helpful for static rigid bodies as well.

P.S. the order in which vertices/indices appear in graphic buffers may affect gpu-efficiency (you can probably rearrange the "singleVerts part" to regain some degree of gpu-performance, but I guess the "duplicated part" will be less efficient in most cases).
P.S.2. I remember that writing that piece of code was not as easy as I had expected it to be... I'm not sure I would be able to rewrite it today
So if you need an advice from me: don't hurry and do a lot of testing.
Bye.

[turanszkij]

OK, I managed to solve the problem by keeping a physics mesh for soft bodies and mapping relevant vertex positions to the graphics mesh. It was dreadful to debug I can tell this, finally it is over, thank you for the ideas.