Hi,
Is it possible to operate a quad-remeshing with homogeneous quadrilateral faces (around the same area, quasi-parallel edges) using Compas ?
Would the libigl or gmsh extensions provide something similar to the QuadRemesh algorithm available in Rhino7 ?
hi,
there is currently no such function in COMPAS, but there are quad (re)meshing
functions available through compas_singular, which is a package based on the PhD research of Robin Oval.
the function in compas_libigl (except for quad planarization) deal exclusively with triangle meshes. not sure about igl itself…
the GMSH mesh model of compas_gmsh has a “recombine” method, which recombines a triangle mesh into a quad mesh…
Hi,
I hope you won’t mind me bumping this thread as I’m considering again the possibility to create quad meshes with compas in Grasshopper.
I have both the latest version of compas and the compas_singular package installed on my machine. When running 02_decomposition_discrete_planar.py from the example folder (the one shown here), the following line:
# build decomposition mesh
coarsemesh = decomposition.decomposition_mesh(point_features)
throws this error:
Runtime error (KeyNotFoundException): dictionary is empty
Traceback:
line 54, in boundaries, "C:\Program Files\Rhino 7\Plug-ins\IronPython\Lib\site-packages\compas_singular\datastructures\mesh\mesh.py"
line 154, in branches_boundary, "C:\Program Files\Rhino 7\Plug-ins\IronPython\Lib\site-packages\compas_singular\algorithms\decomposition.py"
line 174, in decomposition_polylines, "C:\Program Files\Rhino 7\Plug-ins\IronPython\Lib\site-packages\compas_singular\algorithms\decomposition.py"
line 210, in decomposition_mesh, "C:\Program Files\Rhino 7\Plug-ins\IronPython\Lib\site-packages\compas_singular\algorithms\decomposition.py"
line 27, in script
It seems the problem occurs within the boundaries function in the mesh.py file. Specifically, inside this snippet (from line 46 to 64):
boundary_edges = {}
for u, v in self.edges():
if self.halfedge[u][v] is None:
boundary_edges[u] = v
elif self.halfedge[v][u] is None:
boundary_edges[v] = u
boundaries = []
boundary = list(boundary_edges.popitem()) # <--- line 54 throwing the error
while len(boundary_edges) > 0:
w = boundary_edges.pop(boundary[-1])
if w == boundary[0]:
boundaries.append(boundary)
if len(boundary_edges) > 0:
boundary = list(boundary_edges.popitem())
else:
boundary.append(w)
return boundaries
My guess is that line 54 is trying to pop() an element from the dictionary boundary_edges which, in this case, seems to be empty.
This is weird because neither outer_boundary nor inner_boundaries (provided as arguments when constructing the triangulated mesh) is empty. They both contain the vertices coordinates provided in the example JSON file. Same thing for point_features.
Could you help me figure out what’s going on?
Ok, two issues I’m seeing after reviewing the source code:
The delaunay mesh trimesh in the example returns without faces and edges.
There seems to be an indexing mistake inside the boundary_triangulation function in triangulation.py. At line 64, trimesh_face_circle() from compas.datastructures returns a nested tuple and Mr. Oval (the author) select the first tuple instead of the center coordinates inside that tuple.
The correct line should be:
centre = trimesh_face_circle(delaunay_mesh, fkey)[0][0]
The SkeletonDecomposition decomposition in the example returns a delaunay mesh instead of a SkeletonDecomposition object. Specifically, line 75 in decomposition.py should return a SkeletonDecomposition object:
return cls.from_vertices_and_faces(*mesh.to_vertices_and_faces())
However, I don’t know how to overcome this issue
It is very strange because yesterday I had all this working fine without any change in the source code. It is beyond my why it suddenly stopped working.
Finally got it working but, good lord, compas_singular is a mess in its current state.
Please correct me if I’m wrong but it appears to me that the latest version available with pip install is only an incomplete draft of a future version, designed to be more robust and to work with the recent versions of compas. As a result, one would have to downgrade to the latest working release and modify it in order to get it up running with the current edition of compas.
This is the process I went through:
follow the installation instructions archived here. If compas is installed in a specific conda environment, open that environment first:
conda activate yourenvironmentname
pip install compas_singular
find the location of compas_singular:
open the algorithms folder and replace the triangulation.py file by this one. Add another [0] at the end of line 64 (see my previous post)
open skeleton.py in compas_singular/datastructures/skeleton/ and add another [0] at the end of every call of trimesh_face_circle(self, fkey)[0]
open decomposition.py in compas_singular/algorithms/decomposition/ and add another [0] at the end of every call of trimesh_face_circle(self, fkey)[0]
By now, the example files should be working.
Questions to @robin-oval:
I notice that compas_singular is not stable. Very often decomposition.decomposition_mesh(point_features) fails to output a coarse mesh in a single run (multiple attempts are necessary). I suspect the initial random jittering of the vertices required to compute the delaunay mesh to be the cause. Have you considered a workaround to prevent this behaviour?
Nearly all meshes outputted by compas_singular lack homogeneity. Most quad faces are irregular in area and distribution because of the layout assigned by the medial axis. Would there be a way to process the outputted “raw” coarse quad mesh in order to “free” it from this constraint? If so, would you mind providing an example?
Would you mind briefly explaining what is the purpose of point_features and polyline_features when constructing a coarse quad mesh?
In an online lecture given to MPDA BarcelonaTech a couple of years ago you expressed your intention to provide compas_singular as a pluggin (a “toolbar”) for Grasshopper. Is this still on the agenda?
Please don’t give up, we’re counting on you!
hi,
compas_singular is indeed not very well maintained at the moment.
will try to address this asap.
perhaps add the changes you had to make to the issue tracker of the package so it easier to assign someone to have a look…
thanks!
