Pytorch3d: Mesh IO from edge array?

[aluo-x]

Pytorch3d allows the conversion of mesh faces to a packed edge representation, but not the otherway around.

Currently I have been working on rendering a mesh constructed from an edge array of shape (E, 2) or (2E, 2) depending on if the graph is directed or not. One possible problem is that normals are no longer canonically defined, but this could be fixed in post processing.

The problem then reduces to finding a set of faces of shape (F, 3) from an edge array. Another problem is that certain edges may not belong to any face, and they must be discarded. Ideally the implementation is vectorized (or CUDA).

The problem is the same as finding the set of 3-cliques, or the set of length 3 cycles. Looking into this issue:

• networkx provides a brute force implementation enumerate_all_cliques which is very slow and overkill.
• graph-tool provides the C/C++ based all_circuits, which has a python interface
• CuGraph provides the triangle_count. triangles function, which returns a scalar (not useful)
• Gunrock provides the Advance operator, but does not provide a python API. But theoretically with a 3 step Advance, you can extract the set of faces. I think?

I think a vectorized implementation should be possible, possibly via bit operations/out product on the adjacency matix. Was wondering if such functionality could be added to pytorch3d's Mesh IO?

[gkioxari]

Hi @aluo-x! Our meshes data structure is defined with verts and faces. If I understand correctly, you want the ability to define them with verts and edges and from that be able to define faces (if any). We don't have support for the latter case. I think that's a tricky definition, as a set of verts and edges doesn't necessarily define a mesh, triangular or of higher degree of connectivity.

It does sound like an interesting problem to find from a set of edges the set of faces. I can also see how that can be extra tricky especially for batched heterogeneous inputs and for E>5000 (which is what I believe is a medium sized mesh). I'd suspect that this would benefit from some CUDA/C++ source implementation if you don't want the conversion to be the bottleneck here. It's not in our current agenda to add support for this, but if you end up implementing it and want to integrate it with PyTorch3D I am happy to review your PR!! :)

[aluo-x]

I agree it is a tricky problem in many aspects.

For my code, previously the backwards pass of the diff render was the bottleneck, however now it seems like the edge -> face conversion is the bottleneck.

Closing this for now. If I end up writing a speedy implementation I will be sure to submit a PR.

[gkioxari]

Great! Let us know! Good luck with your project!