New Quad Remesher - Additional Parameters in RhinoCommon / Grasshopper Call?

[robert_vier]

Hey,

absolutely great work on the new QuadRemesh command, thank you so much.
@Trav @scottd

Are there particular reasons why not all options of the Rhino-Interface are exposed in the API?
Or am I missing something?

For example, symmetry or guide-curves would be awesome.

I know it is WIP, just trying to understand and see if there are chances in the future.

Kind Regards
Robert

[chanley (Chris Hanley)]

this would be awesome!

[Trav (Travis Serio)]

@robert_vier the simple answer is we’re still not finished adding features to this command. For example I have multi-axis symmetry in the works so before we make RhinoCommon wrappers for all of this stuff we need to get the functionality settled in. They will become available as we progress a bit further and we’re making sure to build it in a way that it will be available to the SDK’s.

[Terry_Chappell]

@Trav,

I would like to try Quad Remeshing the bases of the meshes that I use for measuring the volumes of piles on construction sites. The mesh was created from drone photos and a photogrammetry program. The only documentation for the parameters is what I found in Rhinocommon:

QuadRemesh(self: Mesh, parameters: QuadRemeshParameters) -> Mesh

but this is a little too cryptic for me to figure out how to code the options that I see on the form when I select QuadRemesh from the Toolbar:
Target Quad Count
Adaptive Size
Use Surface Edges
Symmetry Axis
Guide Curves
Detect Hard Edges
Convert to SubD

Edit: I found details on the parameters at:

https://developer.rhino3d.com/wip/api/RhinoCommon/html/T_Rhino_Geometry_QuadRemeshParameters.htm

So it looks like I have enough to give it a try soon.

Regards,
Terry.

[Trav (Travis Serio)]

@Terry_Chappell

Looks like you found what you needed to get started. I tried to be as descriptive as I could in the QuadRemeshParameter class info but if any of it’s confusing just shout. You’ll also find several Mesh.QuadRemesh() overloads on the Mesh class.

https://developer.rhino3d.com/wip/api/RhinoCommon/html/Methods_T_Rhino_Geometry_Mesh.htm

There are several different methods based on whether or not you’re supplying guide curves, re-meshing a mesh or static functions for re-meshing a brep input as well as similar async versions for multi-threading. I may have went a little overkill but tired to add lots of options for developers to use. I also just recently switched over the QuadRemesh command to use these same API calls as well so anything you see the command doing is happening through RhinoCommon.

You can also find a grasshopper definition at the bottom of the post linked below that contains a script using the RhinoCommon methods. It should also help to get you started.

Rhino 7 Feature: QuadRemesh

QuadRemesh, a new feature in Rhino 7 WIP for Windows and Mac, lets you create a quad mesh from mesh and NURBS geometry. Quad meshes can be: Converted to SubD objects (which can be converted to NURBS) Used in rendering and animation products Used for CFD and FEA analysis For finding principle curvature of forms [image%20(2)] QuadRemesh found the principal curvature of this face, with the help of the guide curve feature. Next Steps: Download Rhino 7 WIP for [windows8logo] Windows or [fin…

-Trav

[matled (Matteo Ledri)]

Hi all,
This topic is a bit old and Rhino7 is not WIP anymore but it’s the only one that looks relevant to my problem, so I will try here before opening a new topic.
I’ve done some tests with Quad Remesher, and I cannot obtain the same mesh if I use 3 different way to call the mesher:

• the GH component
• the same GH component called from python with ghcomp
• Calling the Quad Remesher using Rhino common in python

Using the same settings (apart from TargetEdgeLength set to 0 in RhinoCommon, that is not present with the other options) I get 3 different meshes, and also the computing time is very different.
Attached a simple example.
Is it a known problem or I am doing something wrong with the settings?

QuadRemesherProblem.gh (41.1 KB)

[matled (Matteo Ledri)]

After more investigations (and some additional forum search) I’ve managed to get the same mesh by using the GH component and the RhinoCommon call. The problem was due to the GH component not accepting brep input and converting to a mesh on the fly, that could probably cause a different input than the RhinoCommon call. If I mesh in advance and pass the mesh to both, then the resulting Quad remeshing is the same.
The problem with the ghcomp call in python is still there, but I’m sure it’s due to the fact that I’m not passing the settings correctly to the QuadRemesh function.
If I use this:

qms = ghcomp.QuadRemeshSettings(
target_count=30000,
adaptive_size=0,
adaptive_count=True,
hard_edges=True,
seam_edges=0,
symmetry=0,
guide_curves=0)
qms.TargetEdgeLength=0

mesh = ghcomp.QuadRemesh(mesh=body,guides=None,settings=qms)

I get an error: Quad Remesh: input 3 settings. error: Data conversion failed from Goo to Quad meshing settings

If I do:

mesh = ghcomp.QuadRemesh(body,qms)

It meshes but it skips the settings

[Trav (Travis Serio)]

RhinoCommon has more control over quad remeshing Breps than the GH component. The results will definitely vary if you’re passing in a brep since the GH component is creating a simple mesh from the supplied brep.

[clivecarter]

Quad re-mesh and guide curves ~ a small Grasshopper inconsistency?

I AM re-meshing a model where I don’t need or want guide curves.
The regular controls in Rhino for Quad Remesh Detailed Options, include an option for curve influence, “None”.

In Guide Curves, in the Grasshopper equivalent, there is no option for None.
If Approximate is not checked, then the definition will not run.
Should there not be a corresponding None option in Gh?!