Tried to open OBJ file with 1 million vertices, it crashed with segmentation fault.

[rajkr09]

The Buddha.obj model has 1 million vertices. It could not open. Also i recompiled by enabling 64 bit Scalar and Index, but still it failed.

It failed at Line 103 in Properties.h file on the Assert statement. adialmesh: /home/rajkumar/eclipse-workspace20/radialmesh/src/algorithms/../Properties.h:105: pmp::PropertyArray::reference pmp::PropertyArray::operator [with T = pmp::SurfaceMesh::VertexConnectivity; pmp::PropertyArray::reference = pmp::SurfaceMesh::VertexConnectivity&; sizet = long unsigned int]: Assertion `idx < data.size()' failed.

I tried to the print the idx and data_size. idx :543521 data :543522 idx :543522 data :543523 idx :543523 data :543524 idx :4294423771 data :543524

Suddenly the idx is incrementing to a higher value. Not sure what the problem is? You can download the buddha.obj from https://casual-effects.com/g3d/data10/

[rajkr09]

Looks like obj loader is having issue beyond certain number of vertices. When i tried to add 1 million vertices directly, it got added without any issue.

[thovide]

Hello, I looked at the obj file and it contains weird vertices indexes for the faces definitions : they're negative. I don't know if it's in a way or another in obj format specification, but the PMP code doesn't support it : the negative number is put in an unsigned int, creating a huge interger... I tried to fix on my side by adding an abs call in SurfaceMeshIO.cpp: vertices.emplace_back(abs(atoi(p0)) - 1);

With this fix, you can open the file, but it's not good, it looks like the vertices of the faces are not the right ones. Those negative indexes must have a specific meaning, I'll try to dig more into this...

[thovide]

Just found the info :)

https://en.wikipedia.org/wiki/Wavefront_.obj_file

Vertex indices A valid vertex index matches the corresponding vertex elements of a previously defined vertex list. If an index is positive then it refers to the offset in that vertex list, starting at 1. If an index is negative then it relatively refers to the end of the vertex list, -1 referring to the last element.

Each face can contain three or more vertices.

[thovide]

So this code fixes the issue case 0: // vertex { int idx = atoi(p0); if (idx < 0) idx = mesh.n_vertices() + idx + 1; vertices.emplace_back(idx - 1); break; }

[rajkr09]

Thank you

[thovide]

On the same site, the bmw model also raises an issue, this one related to texture management. I'm not sure to understand why texture management is done at halfedge side in SurfaceMeshIO. I've the feeling that it should happen at the vertex layer. Anyway, I wasn't able currently to fix the issue by implementing the same kind of fix as above...