Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Coat Buttons
#1
Hi there,
I've been using Obi Cloth for the last week or so and it's been great but there has been one major stumbling block I've run into, which is correctly positioning and rotating buttons on a coat. I've been able to pull particle positions from script (which was also very useful for an untied belt) but struggling to get the buttons to face normal to the surface. Any suggestions as to how to solve this problem?
Reply
#2
(27-08-2018, 06:35 AM)ncthbrt Wrote: Hi there,
I've been using Obi Cloth for the last week or so and it's been great but there has been one major stumbling block I've run into, which is correctly positioning and rotating buttons on a coat. I've been able to pull particle positions from script (which was also very useful for an untied belt) but struggling to get the buttons to face normal to the surface. Any suggestions as to how to solve this problem?

Hi there!

Why not using the mesh normal? particles themselves have no orientation, and thus no "normal" vector. They're just points in space.

cheers,
Reply
#3
(27-08-2018, 06:38 PM)josemendez Wrote: Hi there!

Why not using the mesh normal? particles themselves have no orientation, and thus no "normal" vector. They're just points in space.

cheers,

Thanks! Tried that solution, but wasn't happy with the results (Think I needed multiple sample points, unless I'm indexing vertices at the wrong place. It's using the same index as the particle, right?). Ended up removing the buttons. Actually think it's less visually noisy at typical in-game scales.
Reply
#4
(28-08-2018, 08:48 PM)ncthbrt Wrote: Thanks! Tried that solution, but wasn't happy with the results (Think I needed multiple sample points, unless I'm indexing vertices at the wrong place. It's using the same index as the particle, right?). Ended up removing the buttons. Actually think it's less visually noisy at typical in-game scales.

Nope, particle indices and vertex indices usually have nothing in common. There's always one and only one particle at the end of any edge in the mesh. However in edges where uvs, normals, vertex colors, or any other per-vertex property is discontinuous (think an UV seam), each edge ends at its own vertex. Think of the corner of a cube, where 3 faces meet: if each face has a different normal (and usually they do) then there are 3 separate vertices at the corner, but only 1 particle. Each face will reference its own "copy" of the vertex, if you will.

Therefore, contiguous mesh triangles can index different vertices. This is what mesh.triangles is used for. See:
https://docs.unity3d.com/ScriptReference/Mesh.html

So usually you have many more vertices than particles. For any vertex in the mesh topology, you can get its corresponding particle:

Code:
int particleIndex = cloth.topology.visualMap[vertexIndex];

Doing it the other way around (getting a vertex for a particle, as there can be more than one) can be done by searching in the visualMap array (which is more expensive).

Smooth per-vertex normals (which are the ones used for rendering) are calculated by a weighted average of the face normals, for all incident faces. Most commonly used weights are triangle areas, edge angles or simple arithmetic mean. Sampling is usually not a good idea. If you are curious:
http://www.bytehazard.com/articles/vertnorm.html
Reply
#5
Hi Jose, why do people prefer the triangle areas weights? I feel like I'm missing an important piece of the puzzle, so to speak.
I'm so happy with these appetite suppressants because they work like a charm.
Reply
#6
(10-09-2018, 12:19 PM)Wassink Wrote: Hi Jose, why do people prefer the triangle areas weights? I feel like I'm missing an important piece of the puzzle, so to speak.

Hi!

The link I posted at the end of the previous response does a great job at explaining it:

http://www.bytehazard.com/articles/vertnorm.html

My pitiful attempt of an explanation:

Consider a vertex where three triangles meet: one of them is fairly large, the other two are very small and have a completely different orientation. If you assigned the same weight to all three triangles, the two smaller ones would influence the normal a lot: 66% of the resulting normal would be that of those two small triangles, skewing the surface normal towards them. However one would expect the bigger triangle to "win" as it covers a lot more surface area of the model, and is visually more important.

By using areas as weights, larger triangles contribute more to the normal (in proportion to their size), and this problem is solved.

PS: quick tip: generally, the cross product of two triangle edges is used to calculate the face normal and accumulate it to each vertex. Since the length of the cross product of two vectors is proportional to the area of the parallelogram spawned by them, we can exploit this to calculate area weighted normals even more efficiently than we could by simply averaging: by skipping the normalization of each face's contribution to the vertex and only normalizing once all contributions have been added, you're area weighting for free. It's much faster and looks much better than the naive method, so what else could you ask for?. See:
https://www.iquilezles.org/www/articles/...ormals.htm
Reply