Help Holes in the mesh corners when using proxies

[Sewy24]

Hello,

first of all, great asset!

I am currently trying to integrate Obi cloth to our project and I am dealing with this problem:
- 1. When I create a box-like mesh on the pic1, and using proxies to simulate only one side, there is a little distortion of lengths at the corners (any bigger angles) pic2. 

- 2. When I create the same box-like mesh in the curved shape (in proxy, I simulate the "inside"), in simulation, the edges are unwelded and there are holes at the corners ((any bigger angles)  pic3 (only example, it can happened next to the pinned or next to the unpinned as well). This is always happening on the same position (until re-initializing, then it can move somewhere else)
(Both meshes are not skinned.)

- 3. When applying the same to the trenchcoat from your demo (switching the Skinned Mesh Renderer to Mesh Renderer to have the same state) there are no holes (only distrotion from 1st bullet occures)

The 1st bullet is not much an issue so far (though if you have solution for the edge distortion, It would be perfect)
2nd bullet is a big issue as you can see, we cannot use it in that state. It's best visible on the curved meshes.

Please, do you have any idea, where the problem is? The meshes are basic and were created in 3D max - box and extruded half-cylinder .
All cloths have the same Solver and same parameters.

Thanks!

[josemendez]

Hello,

first of all, great asset!

I am currently trying to integrate Obi cloth to our project and I am dealing with this problem:
- 1. When I create a box-like mesh on the pic1, and using proxies to simulate only one side, there is a little distortion of lengths at the corners (any bigger angles) pic2. 

- 2. When I create the same box-like mesh in the curved shape (in proxy, I simulate the "inside"), in simulation, the edges are unwelded and there are holes at the corners ((any bigger angles)  pic3 (only example, it can happened next to the pinned or next to the unpinned as well). This is always happening on the same position (until re-initializing, then it can move somewhere else)
(Both meshes are not skinned.)

- 3. When applying the same to the trenchcoat from your demo (switching the Skinned Mesh Renderer to Mesh Renderer to have the same state) there are no holes (only distrotion from 1st bullet occures)

The 1st bullet is not much an issue so far (though if you have solution for the edge distortion, It would be perfect)
2nd bullet is a big issue as you can see, we cannot use it in that state. It's best visible on the curved meshes.

Please, do you have any idea, where the problem is? The meshes are basic and were created in 3D max - box and extruded half-cylinder .
All cloths have the same Solver and same parameters.

Thanks!

1.- This distortion is unavoidable, as it is a byproduct of barycentric skinning (which is the type of skinning used by Obi). Proxy vertices at the edge of a simulated triangle will be distorted inwards or outwards when the simulated triangle bends. The best way to minimize it is to make sure the simulated mesh sits in the "middle" of the thick mesh (as opposed to one side). This requires using a separate simulation mesh though, not just simulating part of the proxy mesh.

2.- Can you provide your mesh, so that we can see what's the cause of this? (you can send it to support(at)virtualmethodstudio.com)

3.- Well, it mostly depends on how your mesh is built. As mentioned, distortion is unavoidable and will always occur though.

[Sewy24]

Hello Josemendez,

thanks for the reply, I've sent you asked meshes.
Distortion is thing we can probably live with .

Cheers

[Sewy24]

Hello Josemendez,

any info about the holes caused by the simulation?

Thanks

[josemendez]

Hello Josemendez,

any info about the holes caused by the simulation?

Thanks

Hi there,

I took a look at your skinmap, the problem is that you're using only 1 skin channel for the whole thing.

Automatic skinning is performed by a combination of normal orientation and proximity. Target vertices are skinned to the closest source triangle that has opposite orientation, but this is not always the one you'd expect. In particular, symmetric meshes often have vertices in one side that accidentally bind to vertices on the opposite side.

This is why skin channels exist: they let you specify which parts of the target mesh should bind to certain parts of the source mesh, and mask out the rest. For instance, target vertices in channel 0 will only bind to source vertices in channel 0. In general, if a vertex exists in multiple channels it will bind only to vertices that share at least 1 channel with it. This is explained here:
http://obi.virtualmethodstudio.com/tutor...cloth.html

In your case (and in the trenchcoat mesh case too) the easiest solution is to divide the skinmap in two channels: one for the left side of the mesh, and a second one for the right side. This ensures no vertex from one side binds to a vertex on the opposite side (which is what caused the "gap" in your mesh). Some screenies of the appropriate skinmap set up and the result:

Target:



Source:



Result:

[Sewy24]

Hello,

thanks for the reaction,

Automatic skinning is performed by a combination of normal orientation and proximity. Target vertices are skinned to the closest source triangle that has opposite orientation, but this is not always the one you'd expect. In particular, symmetric meshes often have vertices in one side that accidentally bind to vertices on the opposite side.

This is not intuitive at all, was missing info like that in the docs (btw. some ob the pages are outdated).


I have followed your instruction (images in attachment), however, this sadly didnt eliminate the hole problem. It can be visible on your image as well (please see attachment Josemendez.png - higlighted in yellow).

[josemendez]

Hello,

thanks for the reaction,


This is not intuitive at all, was missing info like that in the docs (btw. some ob the pages are outdated).


I have followed your instruction (images in attachment), however, this sadly didnt eliminate the hole problem. It can be visible on your image as well (please see attachment Josemendez.png - higlighted in yellow).

Hi,

Sorry, I didn't notice the small gap in my screenshot.

This is still caused by the same reason: that vertex is being bound to a different triangle than the other triangles in the corner, due to its different normal direction. You could either fine-tune the skinmap to force it to bind to a particular triangle (good if you wish to preserve creases, but can be tedious work), or (which is usually easier) smooth out your model's normals so that all vertices in the same position have roughly the same normal, so they automatically bind to the same triangle (which is what the trenchcoat model does).

See the result of doing this in your mesh, no gap at all:


Going into details: Obi's automatic triangle skinning works by using a voting system: for each vertex, all triangles near it are assigned an error metric based on:

- Similarity between triangle and vertex normal (this one is what confuses automatic skinning in your particular case)
- Distance between the vertex and the triangle, along the triangle's normal.
- Barycentric coordinates of the vertex projection on the triangle. Vertices whose projection is closer to the triangle's center get a lower (better) score.

Then, the vertex is bound to the triangle which scored the lowest error. However this can mean that the chosen triangle is not the closest to the vertex, but the one with the most similar orientation, or viceversa. Different weights are assigned to all three criteria, so this usually ends up choosing the best triangle. However under certain circumstances it will not, and that's why skin channels must be used to "direct" the voting system so that it ignores problematic triangles.

Why not just binding to the closest triangle? well, this would not work in multi-layered meshes, self-intersecting meshes, etc.

[Sewy24]

Hi Josemendez,

as we need to preserve creases, we will choose the path "tedious work" . 
I have tried it and it works like charm, thanks for the hint!


Thanks you for the technical info, we have discussed it internaly and would like to know:
Is it possible to adjust (simplify) the skinning algorithm for giving better results, if we provide it only simple thick meshes without multi-layers and self-intersection?

• The idea is to use this different algorithm for simple meshes (as described before) - this should give 100% correct skinning for this meshes.
  
• For more complex meshes use the default provided algorithm and fine tune it by hand.
  

Kind Regards,

[josemendez]

Hi Josemendez,

as we need to preserve creases, we will choose the path "tedious work" . 
I have tried it and it works like charm, thanks for the hint!


Thanks you for the technical info, we have discussed it internaly and would like to know:
Is it possible to adjust (simplify) the skinning algorithm for giving better results, if we provide it only simple thick meshes without multi-layers and self-intersection?

• The idea is to use this different algorithm for simple meshes (as described before) - this should give 100% correct skinning for this meshes.
  
• For more complex meshes use the default provided algorithm and fine tune it by hand.
  

Kind Regards,

Hi!

I'm thinking about exposing the weights used by the current skinning algorithm. This way you could prioritize distance/orientation/barycentric criteria. In your case, using 100% distance, 0% orientation and 0% barycentric would yield perfect results automatically as it would completely ignore normals (orientation) and barycentric coords of the projection. I will look for a way of doing this in the next release.

[Sewy24]

Great stuff! Any idea of when it could be? - days/weeks/months/years is enough



We came across another issue though. 

1. When ObiSolver is set on LateUpdate (no Interpolation) we see one frame late?
   
2. When ObiSolver is set on FixedUpdate with Interpolation, fixed particles are not interpolated - this leads to all simulated particles working as charm, but fixed are jump-following parent object.
   
   

How does the Interpolation work - is it multithreaded?, is it interpolated using the current and the last frame?