Hi,

I am trying to implement an XPBD cloth simulation with the bilateral bending constraint model using RXMesh. To compute the bending constraint for an edge, I need to first access its two adjacent faces, and then assign the "bending force" to the vertices of those two faces. This procedure needs both E-F and F-V relations within a kernel. I think I need to use the query_block_dispatcher API to launch an Op::EF relation right? However, I wonder how can I get the VertexIterator associated with the faces accessed by the E-F relation.

Here's the pseudo-code to explain the computation logic better:

// bending constraint kernel
auto bending_lambda = [&](uint32_t edge_id, RXMeshIterator& ef) {
  if (ef.size() == 2) {
    uint32_t v1 = ev(edge_id, 0); // question: how to get E-V ?
    uint32_t v2 = ev(edge_id, 1);
    uint32_t v3 = 0;
    uint32_t v4 = 0;

    for (int i = 0; i < 3; ++i) {
      if (fv(ef[0], i) != v1 && fv(ef[0], i) != v2) { // question: how to get F-V ?
        v3 = fv(ef[0], i);
      }
    }
    for (int i = 0; i < 3; ++i) {
      if (fv(ef[1], i) != v1 && fv(ef[1], i) != v2) {
        v4 = fv(ef[1], i);
      }
    }
  }
  // do other computations ...
}

// dispatch E-F as the document described
query_block_dispatcher<Op::EF, blockThreads>(context, bending_lambda);

Thank you very much for releasing your great work. Any support would be much appreciated.

Dear Ahdhn, i want to consult you again whether this gpu data structure works well and conveniently implemented for the algorithms like mesh hole filling or simplification which will change the topology of the original mesh. I do not need to change the original mesh itself or related patched information at real time while the algorithm is running , but just want to save the result mesh with changed topology in a object whose class is RXMESH::RXMeshAttribute. after this algorithm, i then do partition again of the topology changed mesh to run another algorithm. though i have noticed the limitations that dynamic scene is not appropriate mentioned in your paper, but just want to confirm it again, thank you .

Dear author, recently i run the code of this project, but i tried many time that project Filtering can not launch multithread for the mesh bilateral denoising by openmesh , specifically, the function :filtering_openmesh which is called in filtering.cu file. in function body of filtering_openmesh , it is obviously that it uses openmp to run in multithread by :#pragma omp parallel for schedule(static) num_threads(num_omp_threads)
reduction(max
: max_neighbour_size).

but i attepted many times to observe 1.the time consumption in comparison with single thread by deleting #pragma。。。。。2.the cpu performance 3.the threads monitored in software "process explorer". all these phenomen indicates it runs in single thread. i do not know why it can not launch multitherad to do this job? and i am sure i have enabled openmp, macro OMP_NUM_THREADS and all possible configurations i know. In your paper, you compared openmesh implementing mcf and geodesic distance, i donot know how you switch between singlecore and multicore. Finally, my hardware running the project is briefly as below: Windows10, interl i7-10 with 16 threads, GPU2080S, cuda11.1, vs2019 and the project is the release version v0.1.0. hope to receive your answer, thank you.

https://github.com/owensgroup/RXMesh/blob/54f29b3e2b8f020a9d5e89f94002fdcc5273d124/apps/Geodesic/geodesic.cu#L88

Display this masage and exits

should read

Display this message and exit

Input file. Input file should under the input/ subdirectory\n"

should read

Input file. Input file should exist under the input/ subdirectory\n"

• Update README with better documentation on how to use RXMesh for writing applications
• Implement user-defined binary reduction operations on attributes
• Integrate Polyscope as a mesh viewer + demo
• Use memcpy_async for reading from global memory to shared memory
• Initial support for edge flip
• Add validation function to make sure that the internal data structure is consistent (useful for future dynamic changes support in RXMesh)
• API for allowing multiple queries in a single kernel

• Remove the padding of shared memory to align with 128 bytes since it does not give any performance boost.
• By default , disable polyscope on Linux
• Fix align unit test

This PR adds polyscope as a viewer. This required implementing special accessors into Attributes. This PR also implements a demo for how to use polyscope with RXMesh. It also adds another constructor for RXMeshStatic and RXMeshDynamic that accepts only path to OBJ file and uses it for apps and unit test (when possible)

This PR integrates CUDA memcpy_async to load data from global memory to shared memory. There is alignment requirements that are important to obtain maximum performance that is ignore for now and will be fixed in future PR. However, we pad global and shared memory as a starting point to support these alignment requirements

This PR introduces RXMeshDynamic as a first step to support dynamic updates. For now, the user should make sure that an edge flip does not introduce invalid configuration.

Highlights:

• Eliminate global index space and identify mesh elements using the combination of their patch index and their local index within the patch
• All query operation no longer needs to map their output to global index space
• Allocating Attributes per-patch basis instead of a single large array
• Introduce Vertex/Edge/FaceHandle to improve type safety which is used to identify different mesh element and index the mesh Attributes
• Introduce LocalVertex/Edge/FaceT to improve type safety for internal implementation of local index space
• Attributes are now managed by RXMeshStatic using add_vertex/edge/face_attribute() API
• Introduce for_each_vertex/edge/face() API in RXMeshStatic for simple operations on the mesh that do not require query operations (i.e., map operations) for both CUDA and OpenMP backend
• Introduce ReduceHandle to do reduction operations on Attribute and so reduction operation temp memory is no longer handle by Attribute itself
• Improve the documentation for most of the user-facing APIs
• Removing code related to shuffling and sorting the input mesh (it was only relevant to reproduce SIGGRAPH paper results)
• Accurately report the register usage and static shared memory used by the kernel by using the (pointer to) kernel itself instead of the prototype function
• Improve initializing the data structure by removing duplicate supporting structure that were created by both RXMesh and Patcher and by using OpenMP when possible in RXMesh

Known Issues:

• Some queries (VE, VF, and higher queries) now require more registers per thread and thus they might fail on some (less powerful) GPUs.

Small problems will be discussed.

• cusolver sparse linear solver (array/vector based solver)
• cusparse spmm spmv wrapper (both working for col major, performance analysis on going)
• Dense matrix support (supports row major/ col major now, only device access is supported for now)

if there were some patchs that made by big isolate faces(>512 & < 1024 faces), then lloyd algorithm will be dead loop. sulotion can be 2 kind:

1. set more than 2 seed for big isolate faces.
2. if a face is boundary in mesh ,then mark boundary in patch.