I am trying to get the circles to be flat on the surface of the body form , these circles are not oriented on the body and I can’t find out why. I am trying to do what the photo shows.
See my screenshot of what I am trying to do and also the the photo which show what I am trying to achieve with GH.
Some one’s help would be greatly appreciated.
you would need the normal of mesh as direction vector(not the global Z).
Or intersect a sphere with the basemesh.
Probably easier to scale the meshfaces and catmullclark it until it becomes round.
I appreciate your reply really but I am sorry about my lack of knowledge on GH but I really don’t understand your reply. I have posted a screenshot , perhaps you could correct it for me?
mesh n.gh (9.3 KB)
holes_distribute.gh (19.1 KB)
Here’s a way to make a surface with distributed holes using SubD that avoids having to do lots of slow booleans or cutting.
WOW! That’s exactly what I was trying to do. Thanks Daniel, I will try it and will send you the results
SO I’ve copied your script but I am nt etting the same as you show on your picture. Please see attached what I got.
Advice frm MCNeel.gh (13.2 KB)
I can’t diagnose the problem unless you also include the input geometry you are using.
Either upload the Rhino file, or in Grasshopper right click the first component with the referenced Brep and select ‘Internalise’, then resave and upload the gh file here again.
I meant something like this:
@DanielPiker 's solution is obviously nicer(the holes are round )
Sorry Daniel, it was late at night in in Melbourne. I forgot to add the Rhino file, I hope this time it’s added after following your saving advices.
Advice from McNeel 2.3dm (206.4 KB)
Advice frm MCNeel 2.gh (3.0 MB)
Have a look at this.
holes_distribute2.gh (136.3 KB)
Firstly there were some mismatched data trees in your file so the meshes were not using the correct vertices.
Also the B input of the modulus component had been changed to a different value. It was set to 1 in my file so that the point spacing wraps correctly around the circle. It doesn’t make sense to have this as any other value.
Also you had the mesh converted to a Brep with thousands of faces before the remeshing. That meant each of these surfaces was getting meshed, resulting in a mesh with millions of vertices, then it was all getting remeshed. Much simpler is to just connect the mesh to TriRemesh directly.
WOw!!! You’re obviously great at this!! Could I ask you to resent that script so I can compare to what I did wrong as with my limited knowledge of GH, I find it hard to understand your reply in a text.
Very appreciated Daniel. Thanks
The updated script is included in my last reply. See the file
In one sweep, you have thought me more than many YouTube video I’ve watched. Thank you Daniel
Nice definition. Took a few minutes to understand that you distributed the points along the circles regularly / at equal spaces. Correct?
Daniel’s post was truly helpful.!
I like this forum! Everyone is helpful.
Thanks, yes - exactly.
Simply projecting the vertices of the mesh dual polygons onto a circle gives roundish shapes but still a bit distorted
Whereas if you also redistribute the points so they are evenly spaced around the circle, it gives a much rounder boundary for the SubD (not perfect circles, but very close, and if you want even closer you can subdivide the sides to get more points first):
I also use something similar inside MultiPipe to get round sections.
Here, a SubD with 27 faces becomes a mesh with 529 faces, but
TriRemesh does not have any options set except Iters, so what criteria does it use to turn a SubD into a mesh?
TriRemesh has the ‘Length’ input for the target edge length of the mesh.
If you do not provide any input here, it makes a guess for what seems a reasonable default target edge length to give a medium density mesh based on the size of the input object’s bounding box.
The density/number of faces/edge lengths of the input geometry do not affect this default.
My comment in my other reply to the OP above about converting to Brep was more related to the initial mesh created before remeshing. Although the density of this doesn’t affect the default target edge length, it can have a big effect on how long the remeshing takes and how many iterations are needed.
In their earlier file it looked like they had converted a quad mesh to SubD, then converted that SubD to a Brep with the face packing option turned off, which results in many individual NURBS faces, particularly around the irregular vertices, and input this Brep to TriRemesh.
When the input is a Brep, TriRemesh makes an initial mesh using the Rhino mesher before remeshing, preserving the boundaries of the Brep faces. This was resulting in a mesh with 28180 faces, compared to only 2766 for the original quad mesh, with no extra detail added. Starting with such a high density mesh means the remeshing has to do many more steps to reach a reasonable density, and also makes it slower because it uses this mesh as a target to keep projecting the new vertices onto during remeshing to keep the shape, and projecting onto a complex mesh takes longer.
So by switching to using their original quad mesh as input it made the remeshing step more than 10x faster to reach the same result.
This is another informative SubD / Remeshing thread so I wondered if I could throw in a related question…
The original mesh has been sliced at the base which has resulted in some triangulation of the quads and an ugly mesh on the base. When this gets remeshed we see a rounding on the sharp edge of the base. What would be the best way to go about preserving the sharp edge? Giving the TriRemesh a Features input?
When I try to add a curve as a feature to the base of the mesh I get an invalid mesh from the TriRemesh…
holes_distribute3.gh (142.2 KB)