Obi Official Forum
Help Holes in the mesh corners when using proxies - Printable Version

+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Cloth (https://obi.virtualmethodstudio.com/forum/forum-2.html)
+--- Thread: Help Holes in the mesh corners when using proxies (/thread-609.html)

Pages: 1 2


RE: Holes in the mesh corners when using proxies - Sewy24 - 25-06-2018

Any idea please?


RE: Holes in the mesh corners when using proxies - josemendez - 25-06-2018

Hi there,

Quote:When ObiSolver is set on LateUpdate (no Interpolation) we see one frame late?

Can you elaborate on this? is the animation one frame late, or the simulation?

Quote: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.

Fixed particles follow the skeletal animation. Skeletal animation does not support interpolation when working with physics (Unity's limitation), so these particles do not benefit from interpolation, as they are not simulated but animated.

Pretty much all of Obi is multithreaded. Interpolation typically takes less than 1% of frame time as it is a very simple operation. It works just like Unity's rigidbody interpolation: since physics are updated at a fixed frequency, it calculates what percentage of a physics update step it would take to get physics and rendering in perfect sync, then it uses this value to linearly interpolate between the last step's positions and the current step positions. For more info on physics, frame interpolation and extrapolation see:
https://gafferongames.com/post/fix_your_timestep/


RE: Holes in the mesh corners when using proxies - Sewy24 - 04-07-2018

Hello,


we put together simple scene to demonstrate our situation (will send it to the support@virtualmethodstudio.com).

In the example, there is a Cube - to simulate the player. 
We are simulating movement on simulaton rig and using our own interpolation - Lerping/Slerping over time (attached in the example) to apply smooth movement to the render rig because of networking.


Description of the scene:
a. Moving the simulaton rig in fixed update.
b. Own interpolation of the a. and copying the transforms to the render rig.
c. Cloth object position is copied from the simulation rig "bone" in fixed update.
d. Cloth simulation in fixed update with your interpolation.


Observation 1. We have to use skinned mesh with "fixed paricles" being substitued with "skin radius" set to 0, to avoid jump-following of the "fixed paricles" - not happy with that, because we cannot use "fixed particles"
Observation 2. Your interpolation seems to be dependant on "Fixed Timestep" 
- when 0.02, the interpolated cloth is working fine, 
- on lower value, the interpolated cloth is few steps ahead of our interpolation
- on higher value, the interpolated cloth is s few steps behind of our interpolation


Could you please take a look on the example and recommend setting for this setup?
The asset is great and powerfull tool.

Thanks Sonrisa


RE: Holes in the mesh corners when using proxies - Sewy24 - 12-07-2018

Reminding myself Sonrisa


RE: Holes in the mesh corners when using proxies - Sewy24 - 26-07-2018

Hello,

Could you please help us find proper setting for explained setup?

Thanks,
Kind Regards,


RE: Holes in the mesh corners when using proxies - Sewy24 - 08-08-2018

Hello josemendez,

could you at least provide us your interpolation logic (script) for us to be able to unify the delay issue? Is there a way to replace it/rewrite it with our logic?

Thanks,
Kind Regards.


RE: Holes in the mesh corners when using proxies - PvtOhOhOh - 04-10-2018

(12-06-2018, 09:14 PM)josemendez Wrote: 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:
[Image: 9zuBj4Q.png]

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.

Could Obi team add vertex color to voting system ? Use vertex color as skin channel ,that the same color in source and target mesh bind together  .This way i can sort vertices group in 3ds max or maya that has better selection tool.