Great to hear this has been useful.
I’m actually just finishing up a very long overdue rewrite of this-
Great to hear this has been useful.
Spectacular, can’t wait!
Do you think some of this meshmachine output could be used as an interim step to feed better inputs to QuadRemesher? I don’t know if you saw this other topic O posted last week, but ReForm seems to be doing some kind of pre-triangular meshing before they fire up their quad mesh solver here and the results look really impressive:
I was wondering about this - I think it might help sometimes.
Here’s a quick test - quadremesh directly from Brep on the left, and from triangular remesh on the right.
Yeah! Can you point us to a good GH script for this? And we’ll start testing it in our stuff right away! We pretty much stopped using quadremesh and doing retopo completely manually these days.This approach might change that.
@scottd @Trav what do you think of this?
I haven’t shared this new triangular mesher yet - only recently got it working really well for tough cases like the one pictured above.
(all the other triangular remeshers I’ve tested have problems with sharp tapering features like this - they either eat away the sharp features, or give a result that looks okay at first glance, but has hidden slivers and non-conforming triangles along the creases, which is no good for FEA or quadremesh)
I’ll get a version out for testing soon.
Using the triangular remesh seems to only slightly improve the quadremesh result. We’ll keep looking at this though.
That makes sense. I’m wondering if this tri meshing could be useful for other things too, especially if you can create adaptive levels of detail to it. The areas where meshes fail the most, or are too slow to be used interactively today for our design workflows are:
- edgesoftenting & shutlining
- mesh booleans. We want to have responsible and reliable live booleans, like what you show on those screenshots, but you can move the operand objects and they just update.
Also, one of the ugliest limitations of QuadRemesh is that it doe snot take orderly/symmetrical/uniform geometry seriously. For example why isn’t that top circular cap a clean radially symmetric part?
Could you send me the Brep model (and the triangular model for comparison…) ?
I’m the developer of QR, and I would like to fix this.
NB: My goal is to avoid the users to have to create triangular before doing the QR. There are already things in QR to avoid this but, as we can see in this example, not enough…
Sounds good. I didn’t save the model above, so I recreated something similar:
QuadRemesh_tests.3dm (791.3 KB)
For Brep models, do you recommend setting the patch boundaries as guide curves in addition to setting Use Surface Edges?
Actually the first time I tried to recreate it, I must have used a slightly sharper curve for the extrusions, and for this model I couldn’t find any combination of inputs for guide curves/detect hard edges for QuadRemesh that would keep the sharp corners/edges when initialising from a mesh (starting from either default Rhino mesh or my isotropic triangular remesh).
QuadRemesh_tests2_sharper.3dm (746.9 KB)
If you set “Use Surface Edges” at “strict” it’s not recommended to set patch boundaries as curves (it’s useless and could disturb the algorithm).
If you set “Use Surface Edges” at “smart”, QR tries to choose which patch boundaries should be used or ignored. So in this case, you should try “strict”.
Have people seen this, it is new?
I didn’t know I needed this gmsh adaptation for grasshopper, thank you.