Vertices are moved to zero about xatlas HOT 9 OPEN

@PerspectivesLab Here's an outline of the way xref should be used. It's basically the original index of each output vertex - it tells you where to get the data for an output vertex from the input mesh.

// Example below assumes that YourMeshClass::operator[] accesses vertex data.
const YourMeshClass& inMesh; // Your source mesh for xatlas to process.
YourMeshClass outMesh; // The new mesh that we'll create below.

// Create/generate xatlas::Atlas*.
xatlas::Atlas* atlas = xatlas::Create();
// Setup chart/pack options, add inMesh data to atlas.
// ...
// Generate charts.
xatlas::Generate(atlas, chartOptions, packOptions);

// Construct outMesh from inMesh data + xatlas generated data.
xatlas::Mesh& atlasMesh = atlas->meshes[0]; // Could be per submesh.
outMesh.setVertexCount(atlasMesh.vertexCount);
for (uint32_t outVertexIndex = 0; outVertexIndex < atlasMesh.vertexCount; outVertexIndex++)
{
	xatlas::Vertex& vertex = atlasMesh.vertexArray[outVertexIndex];
	uint32_t inVertexIndex = vertex.xref; // Index of input vertex from which this output vertex originated.
	outMesh[outVertexIndex] = inMesh[inVertexIndex]; // Copy data from the input mesh to the output mesh.
	outMesh[outVertexIndex].lightmapUV = { vertex.uv[0] / atlas->width, vertex.uv[1] / atlas->height };
}
outMesh.setIndexData(atlasMesh.indexCount, atlasMesh.indexArray);

from xatlas.

Any invalid geometry (e.g. zero-length edges) can't be atlased. Vertex::atlasIndex will be -1 and so Vertex::uv will be (0,0). I'm guessing that is what is happening here. Do you see (0,0) vertices in the output of the example or viewer? They skip invalid vertices when rasterizing the atlas texture.

from xatlas.

I do not see them in the viewer and that was why I was not understanding it proper. Ok, so I shall check the atlas index and place them next to the closest valid vertex. This is a little inconvenient as I cannot assume that the UVs will be perfectly clear as they may be generated with all sort of mapping. I will work this issue around then.

from xatlas.

@AlbertoFrancoDD it looks like you're not taking into account that ComputeCharts() may increase the vertex count of the input mesh. Some shared verts may need to be duplicated and put into separate charts, so you need to construct new mesh data with these extra vertices (using xatlas::Vertex::xref to copy other vertex attributes into the new mesh data).

from xatlas.

@john-chapman IS there a way to block this? I need the mesh to stay consistent with the cuts that were performed by the artist, I cannot change the input mesh.

from xatlas.

The output mesh is exactly consistent with the input mesh - all other vertex data is unchanged, xatlas just needs to duplicate some vertices so that the generated charts will have unique UVs. I don't think there's any way to avoid this, but it shouldn't be a problem.

from xatlas.

I met the same problem. No idea why xatlas wants to split the left part and the right part into two charts.
I am wondering whether this is a way to specify the vertex-chart relation manually, and all the vertices belonging to the same chart would just take the same rigid moving, even there are so-called "invalid vertices".

from xatlas.

can you guys provide an explicit example in c++ @john-chapman on how to re create a new mesh based on xatlas::Vertex::xref ?
thx

from xatlas.

@john-chapman thank you, your help is highly appreciated !

from xatlas.