How to read position coordinates of a non-manifold mesh

[afabri]

In this gist I read a drc file and I want to write the xyz coordinates of the vertices of the first face. The output looks correct for a 2-manifold mesh encoded as .drc file, but the output is wrong for a non-manifold mesh (I produced it with the encoder that converts a ply to a drc file, giving it three triangles that share an edge).

For the two .drc files in drcFiles.zip the output is:

afabri@malevich /cygdrive/c/cgal/git/BGL/test/BGL
$ ./VC2017/draco.exe data/nonmanifold.drc
6.10352e-05 1.00006 0
6.10352e-05 0 0
6.10352e-05 0 1.00006
afabri@malevich /cygdrive/c/cgal/git/BGL/test/BGL
$ ./VC2017/draco.exe data/opentet.drc
0 0 0
0 0 1
0 1 0

I would be glad if anybody could point out what I am doing wrong.

[ondys]

With default settings, Draco automatically splits non-manifold vertices to ensure the resulting surface is manifold. What this means in practice is that the output (decoded) mesh is going to have more vertices than the input mesh. If you want to preserve the non-manifold connectivity you would need to explicitly select different encoding method (MESH_SEQUENTIAL_ENCODING) .. this would preserve the non-manifold connectivity but the compression rate would suffer a lot

[afabri]

I understood this. With my mesh consisting of three triangles sharing an edge, I have 9 corners.

The question is how to get the coordinates of the vertices u and v, because that are the wrong coordinates you see in the output above: 6.10352e-05 1.00006 0.
So something in my logic
draco::CornerIndex ci(i); // with i=0,1,2 for the corners of the first triangle
draco::VertexIndex vi = ct.Vertex(ci);
draco::AttributeValueIndex avi(vi.value());
const draco::PointAttribute *const att =
mesh->GetNamedAttribute(draco::GeometryAttribute::POSITION);
std::array<float, 3> value;
att->ConvertValue<float, 3>(avi, &value[0]);
must be wrong.

[ondys]

When the mesh is non-manifold CornerTable creates extra vertices that do not correspond to the position values directly.

you may want to try to change the second line in your code to:

draco::VertexIndex vi = ct.VertexParent(ct.Vertex(ci));

This should give you the "parent" vertex index. For the newly created vertices (due to non-manifold splitting), the parent is the original vertex before the splitting.

Alternatively you can retrieve the position via PointIndex. In Draco, every face is defined by a triplet of PointIndex (that is each CornerIndex is mapped to one PointIndex). For every attribute the PointIndex may be mapped to a different AttributeValueIndex.

If your input is CornerIndex you should be used the following code to retrieve the attribute value:

draco::CornerIndex ci(i);
draco::PointIndex pi = mesh->CornerToPointId(ci);
const draco::PointAttribute *const att =
mesh->GetNamedAttribute(draco::GeometryAttribute::POSITION);
std::array<float, 3> value;
att->ConvertValue<float, 3>(att->mapped_index(pi), &value[0]);

note the called to att->mapped_index() that gets you the matching AttributeValueIndex for the given PointIndex

[afabri]

Thank you all for your replies. But I only realize now, that when you duplicate vertices, you at the same time slightly change the coordinates. Is it documented how? Is it a random permutation, or do you shrink the triangle with the goal (hope) to not introduce self-intersections?

[ondys]

The splitting itself should not affect the coordinate values. When a vertex is split into multiple vertices the positions of all newly created vertices should be exactly the same as the position of the original vertex. Position coordinates can be changed during encoding because of quantization (essentially snapping to a nearest value on an integer grid), but that should affect all non-manifold vertices equally (that is if they had the same position before quantization, they should have the same position after quantization)

[afabri]

When you run the tool draco_encoder -i nonmanifold.ply -o nonmanifold.drc, followed by draco_decoder -i nonmanifold.drc -o nonmanifold.obj you will see that there is a problem either in my usage, or in the tools, or in the encoding/decoding. I created an .obj as it is in asciii.
nonmanifold.zip

[ondys]

When I run it through our pipeline I got the following result:
nonmanifold_dec.obj.zip

The result looks ok to me. Both vertices on the non-manifold edge share their respective coordinates. That is, coordinates of vertices 0 and 3 are exactly the same and coordinates of vertices 2 and 4 are exactly the same as well.

The slight offset of some vertices from their original values is caused by quantization and it has nothing to do with non-manifoldnes of the input geometry

[afabri]

Got it. So i have to understand the consequences of quantization better. It is somehow surprising that a coordinate of 0 becomes 0.000061.

[ondys]

Yes, the quantization range is computed based on the maximum extent across all dimensions. In this case the maximum range is defined by the X axis with values -1.0 and +1.0. The "problem" is then that the quantization uses an even number of integer values (e.g. 0-255) where 0 would represent -1.0 and 255 1.0. This unfortunately means that the mid-point value 0.0 cannot be represented exactly.