Comments and answers for "Deform shared vertices only on a planee"
http://answers.unity.com/questions/1168690/deform-shared-vertices-only-on-a-planee.html
The latest comments and answers for the question "Deform shared vertices only on a planee"Comment by Eno-Khaon on Eno-Khaon's comment
http://answers.unity.com/comments/1169466/view.html
That's certainly an option for an approach, as well. Using a structured pseudo-randomization (i.e. noise) will return reliable values based on input, so you would definitely see identical results for each vertex in matching positions.
Relying on that alone, however, would not account for the original objective of aiming for a combined set of normals for a reliable position offset. Unless you're strictly working from a basis of pushing vertices away from a defined center (basically, supporting only spherical shapes), it may be very challenging to find a scheme which can reliably simulate the same effect you would get from modifying vertex positions based on their normals.
Either way, a noise function would provide a very reliable and reproducible displacement with greater consistency and smoothness than pure randomization would offer, so that's certainly handy to make use of.Tue, 12 Apr 2016 10:11:31 GMTEno-KhaonComment by techspy on techspy's answer
http://answers.unity.com/comments/1169091/view.html
I'm sorry about the poor formatting, I posted from a mobile phone.
I managed to get as far as using a class to store each vertex position, normals and uv data by creating a new instance of my custom class object. Beefore i got to comparing vertex values I got a suggestion from elsewhere to use a Noise function and get rid of my random float and the results were not so bad. To quote DMGregory from StackExchange, " Seed the noise lookup with the original position of your vertex. Since shared vertices have the same position, they'll get the same displacement, keeping them tightly joined."
For educational purposes, I am going to complete your suggested solution and report back my results.Tue, 12 Apr 2016 09:54:23 GMTtechspyAnswer by Eno-Khaon
http://answers.unity.com/answers/1168892/view.html
For reference, Unity's mesh optimization works by separating out numerous fields: <b>vertices</b>, <b>normals</b>, <b>colors</b>, <b>tangents</b> and <b>uvs</b> are all contained in arrays of equal size; there's one of each of those per vertex. Then, <b>triangles</b> are stored in an integer array in groups of three, with those integers acting as a guide for a corresponding vertex.
In the case of a cube shape, you'll likely have 12 triangles (2 per face, 6 faces). Beyond that, you have a choice to make with a model...
Because vertices and normals are shared 1:1, you can either have fewer vertices with rounded corners from interpolation between the normals or you can have more vertices with hard edges. Therefore, a 6-sided cube with rounded normals (to loosely resemble a sphere) would have as few as 8 vertices, a typical 24 vertices, or a maximum of 36 vertices, by having no duplicate vertices, individual faces in groups of 4, or individual triangles with 6 per face respectively.
That said, no matter the vertex count, you'll always have a 36-size array for triangles for a cube, in order to accommodate all 12 triangles.
With all of that in mind, it should be reasonably easy enough to determine which vertices share a location, but the triangle array can't help you here. Because you'll always have 36 triangle array entries on a cube, you can't tell the difference between any two variants of a cube. But if it looks like a cube and has hard edges, you can likely assume that two or more vertices share the same position.
Therefore, in order to manipulate their positions, you'll need to run through the array and find which vertices <b>do</b> share a position (i.e. v[x] == v[y]). Caching the results would likely involve an array of arrays (or a class/struct containing said array, etc.), due to the possibility of a variable array size per reused vertex position.
Once you've found matches, give them a collective normal by adding their normals together, then dividing by the number of vertices sharing the position (and normalize the result). Now, you have your new displacement normal to apply to each of those vertices shared at that position (which could also be applied to the same class/struct containing the array of vertices sharing a position).
By association, going back to another detail, this also means that any vertex in the mesh which doesn't share a position with another vertex is unique (barring extreme circumstances where the mesh has extraneous vertices with no connections). If a vertex is determined to have not shared a position with any other vertex, then you can generally assume that displacement of that vertex will not leave any holes (again, unless the mesh had construction problems in the first place).Mon, 11 Apr 2016 09:17:46 GMTEno-Khaon