Question about ltog lifetime, vertex ordering, and exporting RXMesh data to contiguous GPU tensors

[will-zzy]

Hello,

I noticed that m_h_patches_ltog_v/e/f seem to be used only during the construction of the RXMeshStatic object, and they are not referenced afterward. In particular, update_host() does not appear to update the ltog mappings.

Does this imply that one of RXMesh’s design principles is to discard the original vertex/face ordering from the input .obj file and instead focus purely on local neighborhood and patch-based representations? As a consequence, the vertex order in an exported .obj file can differ significantly from the original ordering, with the exported order being determined by RXMesh’s internal patch layout rather than the input file.

On a related note, vertex attributes and face topology in RXMesh are not stored contiguously in global memory, but rather in a patch-wise layout. Therefore, it seems infeasible to directly expose device-side data structures such as m_input_vertex_coordinates and PatchInfo::fe as torch::Tensor views for vertices and faces.

However, it is still possible to perform relatively low-cost device-to-device copies to reconstruct contiguous tensors on the GPU. My current idea is the following:

(1) After each kernel that modifies topology, call cleanup() to update internal structures such as m_d_vertex_prefix.

(2) Use m_d_vertex_prefix and active_mask to scatter/gather vertex values and face connectivity into newly allocated contiguous device tensors.

(3) Expose these tensors to PyTorch for downstream computation.

I would like to ask whether this approach is considered safe and consistent with RXMesh’s intended design, or whether there are potential pitfalls I should be aware of.

Thank you very much for your time and for the excellent RXMesh framework!

[will-zzy]

Additionally, I noticed that cavity currently only supports E as the seed. May I ask whether future releases will allow the cavity operator to use vertex or face as the seed?

[will-zzy]

In cavity_manager_impl.cuh at line 1144, this function is used to add adjacent cavities in the cavity graph.

I noticed that there seems to be some logical issues:

    if (c0_id > c1_id && c0_id != MAX_OVERLAP_CAVITIES) {
        clear(c0, c0_id);
    } else if (c0_id > c1_id && c1_id != MAX_OVERLAP_CAVITIES) {
        clear(c1, c1_id);
    }

First, the maximum value of c0_id and c1_id is MAX_OVERLAP_CAVITIES. If c0_id > c1_id and c0_id != MAX_OVERLAP_CAVITIES, then both c0_id and c1_id are smaller than MAX_OVERLAP_CAVITIES, which means the function will already return in the earlier condition and will never enter this branch, thus always falling into the else-if branch.

A similar issue appears in the following code segment as well.

    // if we can prioritize based on overlapping size
    if (c0_id != MAX_OVERLAP_CAVITIES) {
        clear(c0, c0_id);
    } else if (c1_id != MAX_OVERLAP_CAVITIES) {
        clear(c1, c1_id);
    }

It seems that the intended behavior is: if the adjacency list of cavity 0 is already full, we do not want to continue adding a new cavity 1 to cavity 0’s adjacency list. Therefore, cavity 1 is deactivated, indicating that cavity 1 should be skipped in the current iteration and deferred to the next iteration.

However, this function does not seem to handle the case where both cavity 0 and cavity 1 already have full adjacency lists. In this situation, neither cavity 0 nor cavity 1 will be deactivated, even though an adjacency relationship between c0 and c1 does exist but is not recorded. Could this lead to potential conflicts or inconsistencies?