The direction of curves on surface

hi guys, i want to create some curves on surface . but i can’t control the direction of them when i use the CrvSrf command. does anyone know the problem? what can i do?

Post your code.

Oh well…


crvOnSrf_2019Aug3a.gh (20.4 KB)

thanks a lot!!

hi Joseph I used your gh.but the outcome is a little different from what I expect. I still want to use the “Crvsrf” command. and I think there is something wrong with the “uvP”. I don’t know how to solve the problem. Would you like to help me check my gh? thanks !!!

CrvSrv.gh (31.0 KB)

CrvSrf (Curve On Surface) will not generate curves that cross the seam, so the best alternative I can think of is this:

crvOnSrf_2019Aug9a
crvOnSrf_2019Aug9a.gh (15.1 KB)

It finds the shortest CrvSrf and replicates it by rotating it around the center. Good enough?

P.S. Turns out that a bit of post-processing is necessary (yellow group below) to really take advantage of this idea.

  • Loft the list of curves from Rotate to change the seam before…
  • SrfSplit the re-lofted surface.
  • Use the start point from one of the edges of each split piece (doesn’t matter which of the four edges) to sort AlongCrv, then List Item with the ‘I’ output to get the split pieces in sequential order.
  • Otherwise, Dispatch yields funky results because SrfSplit leaves them a little mixed up.

crvOnSrf_2019Aug9b
crvOnSrf_2019Aug9b.gh (17.5 KB)

1 Like

Just for fun… Applying logic similar to that used here:


crvOnSrf_2019Aug10a.gh (43.9 KB)

This gets very slow as the number of segments is increased. Using eight segments as shown, the cyan group shows ~19 seconds on the Profiler and the light green group adds another ~14 seconds. Using 32 segments as shown below takes ~20 minutes!

Using ‘vertices’ instead of ‘midpoints’ (light green group):

The light green group cuts the holes and could be skipped; the blue surfaces are available as the ‘A’ output of Dispatch in the cyan group.

wow it solve my problem. thanks a lot. this is really a good way. But when i replace the circle to ellipse, it doesn’t work again. just like you mentioned the issue is curves can’t cross the seam. So i find another way from the forum. it use the “relative item” component to solve the problem. it works well.

CurveoncylindricalsurfaceusingRelativeitem_reV3.gh (11.7 KB)

1 Like

CrvonSrf_2019Aug14.gh (19.6 KB)
image

I wanted to try to color up @jiangying4692’s solution, but the seam is causing problems, which @Joseph_Oster was able to avoid with his solution.

I was wondering (and it had come up in another post of mine), is it possible to join the white surfaces to the blue if they share two vertices? I feel like it can work, but I just can’t wrap my head around it.

Check attachment.


CrvonSrf_re.gh (23.2 KB)

1 Like

Check this as well.


CrvonSrf_rev2.gh (29.8 KB)

1 Like

Naturally, the model that relied on a surface of revolution won’t work when that assumption isn’t met, though the first method I suggested in this thread works fine, adding in the re-loft (using rebuilt pulled curves) to get “natural” seams, following the isocurves:


CurveoncylindricalsurfaceusingRelativeitem_reV3_2019Aug15a.gh (32.8 KB)


CurveoncylindricalsurfaceusingRelativeitem_reV3_2019Aug15b.gh (29.0 KB)

Thank you @HS_Kim, that was an interesting solution to the problem. However, I was hoping for the method that I mentioned before, to match up the surfaces by their shared two vertices. The previous post I had mentioned is here: Expanding boundaries to evenly fill space - #20 by jasongberger

If you look it over, I was hoping that I could combine rectangles to make one larger rectangle. It may be possible for two adjacent rectangles to share a common midpoint, but have unequal sides. Now that I think about it, I suppose I could cull out any joined rectangles that have more than four sides… but I’m still curious to see how (and if) it would work.

Also, is there any advantage to using subset list over list item?

You can also use Brep Topology.


CrvonSrf_reV3.gh (15.4 KB)