draco_encoder: Segmentation fault while encoding a simple OBJ file (52 vertices, 100 triangles)

[yvoronov-artec]

./draco_encoder breaks down while encoding 'model_mesh.obj' with default options.

OBJ file is attached here (remove .txt extension and make it .obj) - model_mesh_obj.txt

Here is the stack trace:

#0 0x00007ffff728d0ad in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x000000000069063b in draco::DataBuffer::Read (this=0x9cef20, byte_pos=-12884901888,
out_data=0x7fffffffde80, data_size=12) at /home/artec/projects/draco/core/data_buffer.h:47
#2 0x00000000006ccb59 in draco::GeometryAttribute::GetValue (this=0x9ce9c0, att_index=...,
out_data=0x7fffffffde80) at /home/artec/projects/draco/point_cloud/geometry_attribute.h:94
#3 0x00000000006cc9f7 in draco::SequentialNormalAttributeEncoder::PrepareValues (this=0x9cab60,
point_ids=...)
at /home/artec/projects/draco/compression/attributes/sequential_normal_attribute_encoder.cc:44
#4 0x00000000006b4dd5 in draco::SequentialIntegerAttributeEncoder::EncodeValues (this=0x9cab60,
point_ids=..., out_buffer=0x7fffffffe180)
at /home/artec/projects/draco/compression/attributes/sequential_integer_attribute_encoder.cc:83
#5 0x000000000072de1f in draco::SequentialAttributeEncoder::Encode (this=0x9cab60, point_ids=...,
out_buffer=0x7fffffffe180)
at /home/artec/projects/draco/compression/attributes/sequential_attribute_encoder.cc:42
#6 0x00000000006b3151 in draco::SequentialAttributeEncodersController::EncodeAttributes (this=0x9ca8f0,
buffer=0x7fffffffe180)
at /home/artec/projects/draco/compression/attributes/sequential_attribute_encoders_controller.cc:61
#7 0x0000000000641733 in draco::PointCloudEncoder::EncodeAllAttributes (this=0x9cf570)
at /home/artec/projects/draco/compression/point_cloud/point_cloud_encoder.cc:104
#8 0x0000000000641552 in draco::PointCloudEncoder::EncodePointAttributes (this=0x9cf570)
at /home/artec/projects/draco/compression/point_cloud/point_cloud_encoder.cc:83
#9 0x00000000006412d9 in draco::PointCloudEncoder::Encode (this=0x9cf570, options=...,
out_buffer=0x7fffffffe180) at /home/artec/projects/draco/compression/point_cloud/point_cloud_encoder.cc:44
#10 0x00000000006201d0 in draco::EncodeGeometryToBuffer (encoder=0x9cf570, options=...,
out_buffer=0x7fffffffe180) at /home/artec/projects/draco/compression/encode.cc:51
#11 0x000000000062070f in draco::EncodeMeshToBuffer (m=..., options=..., out_buffer=0x7fffffffe180)
at /home/artec/projects/draco/compression/encode.cc:120
#12 0x000000000061e5be in (anonymous namespace)::EncodeMeshToFile (mesh=..., options=..., file=...)
at /home/artec/projects/draco/tools/draco_encoder.cc:136
#13 0x000000000061efd9 in main (argc=5, argv=0x7fffffffe618)
at /home/artec/projects/draco/tools/draco_encoder.cc:232

[ondys]

Thanks for the report. Can you please try it again using the latest version in the master branch? There were some updates and fixes pushed in today. I could not reproduce the error on my end. If it still crashes, please let us know your OS / compiler setup. Thanks.

[yvoronov-artec]

Ondrej, it is better now, thanks. No crashes.

However, there is still a problem. I converted original OBJ model to DRC and back. Original model has point normals but does not contain triangles normals, while the output model does both. And all the normals are the same, which is quite strange. See for yourself (again, remove .txt extension and make it .obj) - model_mesh_out_obj.txt

[yvoronov-artec]

And as for this part:

    // Texture index not provided but expected. Insert 0 entry as the
    // default value.
    out_point_cloud_->attribute(tex_att_id_)
        ->SetPointMapEntry(vert_id, AttributeValueIndex(0));

Generally, one can make 0 as default value in SetExplicitMapping() call. So making kInvalidAttributeValueIndex = 0 does the trick.

Another idea could be using a map instead of a vector for indices_map_ or just checking for kInvalidAttributeValueIndex before compression.

Thanks!

[ondys]

The problem actually is that the .OBJ has defined vertex normals but they are not assigned to any points on the faces. In this case the normals should be completely ignored and we are going to fix this.

Otherwise, as far as I know, there is no concept of per-face (triangle) normals in .OBJ files.. all the vertex normals defined as vn XX XX XX are just values that can be associated to any point through the face data. If you want the normals to be associated with the vertices then they would have to be specified on the faces as well .. e.g. the first face would be:

f 37/1/37 14/2/14 34/3/34

[yvoronov-artec]

My point is to have normals (vn ...), but to have it apart from triangles, just in the same order as points. So in this way normals are associated with points sequentially. So normals should be preserved as values, but with no assignment to faces.

Generally, we have point normals and triangle normals, the later being different from the former. OBJ file can contain much more normals than points, so faces are associated with high order normals (which numbers are more then the point count). Currently we omit triangle normals for simplicity, however, we'd like to preserve point normals.

[ondys]

I'm not sure if we are going to add support for such a special use case ourselves (unless there is a broader demand), but in general Draco library should be able to handle this (you can for example add multiple attributes of type GeometryAttribute::NORMAL and use one for point normals and for triangle normals). If you have direct control over the structure of your .OBJ, you should be able to modify the Draco's existing obj_decoder pretty easily to support your scenario (or you can encode your input directly using our API).

[yvoronov-artec]

I close this issue while making the separate question about normals.