Hi guys,
I’ve been playing around attempting to procedurally generate some meshes to act as terrains, which is actually going rather well. However whilst creating these messages, I’m having to create triangles a bit irregularly, as I’d like to be able to deform the terrains by accessing their vertices.
The triangles have been created making sure that they all share the vertices in the mesh, and each ‘tile’ (2 triangles next to each other making a square) doesn’t use it’s own individual 4 vertices (I hope this is still making sense!).
The issue being, I’ve been trying to texture the mesh using UV mapping, utilising a tileSheet of smaller textures. The first ‘tile’ is textured correctly, however the following ones all use the texture next to the selected one on the tileSheet, and I’m really not quite sure why. Example :
I’m not particularly familiar with UV mapping and so this has been a bit of a struggle. However, I am very open to any alternative methods of texturing my meshes.
In Unity’s MeshFilter, the .vertices array and the .uv array are “in sync,” along with the .normals array as well. That is, if you share a vertex, you also share the UVs for it.
If you want to do tiling on a grid, you would need to add extra double verts in order to “restart” the UV coords for the next tile over at a different point in the grid.
I’m gonna give that a go as soon as Unity starts working again. As I am only creating 2 verts at a time, and then 2 UVs, wouldn’t they be in sync anyway? (Example; adds 2 verts adding to the X axis, and uses the 2 previous verts used for the other side to create the total of 4).
At any given vertex, if that vert position is shared between faces and yet is supposed to map to a discontinuity in your texture (say, go from 0.2 and jump to 0.5), then you will need to duplicate the vert position with a new UV, and use the correct one in each face that needs it.
Also, that darkening you see is probably the normals. For procedural meshing, I’ve not ever worried about normals and instead just called the .RecalculateNormals() function on the mesh when I am all done. If you share verts, it will smooth the normals across. If you have split verts (one for each face), then you will get a hard facet.
I’ve been playing around with it this morning generating 4 vertices per face - however, when I try and raise a vertice up, it’s leaving a hole in the mesh - this is because the other triangles aren’t using the same vertex, and have a different height value, right?
Is there any way to have 4 individual vertices, and not leave holes in the mesh when the height value is changed?
Probably the cleanest way to do this would be to leave your original mesh design unchanged, but introduce an intermediary step from the vertices that are shared between triangles, to the actual ones shoveled into the mesh, and during that step introduce unique vertices per face. It’s one extra pass through the verts whenever they get changed, but depending on your vert count, shouldn’t be too bad.
Like he said, the best way is to assemble your “theoretical” mesh in a class object where the vertices are shared and then duplicate all the vertices as you put them into the arrays you’ll pass to the mesh renderer. You will have to hand calculate the normals (and tangents if you use normal mapping) for this method - but it’s very doable…
Here’s procedurally generated terrain (a photo from another thread talking about some shader problems I had) I did with that method. The “theoretical” mesh all shares the same vertices, but when they’re passed to the mesh renderer, each one is duplicated according to the number of faces per vertex: http://i.imgur.com/DP5vraQ.jpg
Here’s my final assembling routine that creates the arrays to pass to the mesh renderer as an example of what you need to do: