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?

[Ahdhn]

I just noticed that I had not replied to this issue. Sorry for the delay. There are a few points raised here and I will try to address them clearly.

Indexing

All details about the different index spaces in RXMesh are documented here: https://ahdhn.github.io/RXMeshDocs/rxmesh/indexing

There are three index spaces in RXMesh:

1. PatchID + LocalID: This is what a Handle stores. It is simply a tuple of the patch index and the element (vertex/edge/face) local index within that patch.
2. Linear ID: A compact 1D index space over all mesh elements. The documentation explains how it is computed.
3. Global ID: The index as given in the input .obj file.

In general, the Linear ID is different from the Global ID. Also, the Global ID should not be used with RXMeshDynamic, since we do not maintain it in the dynamic case (as you noted).

If you are using RXMesh alongside other data structures or libraries, I recommend treating RXMesh as the main mesh container (the backend) and using Linear IDs for interoperability. Linear IDs are supported on both host and device while Global IDs are only available on the host.

Contiguous memory

This was a somewhat lazy implementation on my side, since it did not affect device-side performance. However, it does have several downsides including the ones you pointed out: difficulty exposing attributes and topology as PyTorch tensors and the cost of multiple cudaMemcpy calls (one per patch).

I have recently updated the implementation to use a single buffer allocation for both attributes a89fe76 and topology aef161f

One thing to note is that PatchInfo (ev, fe, and the active/owned masks) is over-allocated in RXMeshDynamic to allow patches to expand before triggering a split.

With this updated layout, along with m_d_vertex/edge/face_prefix (accessible through the Context), you should have enough information in contiguous buffers to reconstruct both attributes and topology efficiently.

As mentioned, I am actively working on exposing RXMesh to PyTorch without sacrificing performance so there should be more updates on this soon.

Cavity

I am happy to support additional cavity seed types. Please feel free to open a separate issue with the specific seed types you would like to see.

I promise to look into the implementation of the CavityManager you pointed above. I will reopen the issue to remind myself :)