Project Curve to Surface using Python

Hi all,

I am writing a short python script to project curves to surface and the below screenshot shows the error i am getting. Can someone help me out on this please.

Thanks


project curve.gh (6.3 KB)

hey, could you solve it and have it worked? I was actually looking for something like this

Apparently the only problem was that ‘Brep’ input needed a type hint?


project curve_2024Oct26a.gh (6.4 KB)

import Rhino.Geometry as rg

#Define the curve projection
PCurve = rg.Curve.ProjectToBrep(Curve, Brep, Direction, 0.01)

https://developer.rhino3d.com/api/rhinocommon/rhino.geometry.curve/projecttobrep

can this be used to project multiple curves onto multiple breps?
I tried it here but is returning an error. It’s working as intended with the native component toproject curves onto a brep, but it’s taking too long to compute.
GHPython_PCurve-16-10-2024.gh (10.4 MB)

62 K circles :bangbang: Wow. Error message says:

  1. Solution exception:Value cannot be null.
    Parameter name: curves

And sure enough, 132 of your circles (66 per branch) have radius = zero. That won’t work.

There might be data tree issues too but I can’t tell until you fix the zero radius circles.

A few things:

  1. As always when working with a huge number of geometry (circles in this case), it’s better to test the algorithm with small numbers first. Quicker to solve and debug.

  2. What are you going to do with the projected circles? Split Surface will surely fail.

  3. Why use project (especially Python) when you could create circles directly on the 56 planar surfaces?

This version does that. No Pyhon, no project circles to surfaces. Most of the work was in the gray group, just getting the “attractor” curve (yellow group) between the two branches of surfaces.

Split Surface is slow but works because it splits each surface with only the circles created on it. SFrames uses the ‘U’ and ‘V’ defaults (10) resulting in 121 circles per surface (11 * 11), though UV values can be increased (independently), of course.


project curve_2024Oct26b.gh (70.8 KB)

P.S. You are projecting 61892 circles. For comparison, I made some adjustments:

  • increased the ‘U’ value from 10 to 40 (41 vertically)
  • increased the ‘V’ value from 10 to 15 (16 horizontally)
  • reduced maximum circle radius from 0.049 to 0.04

The result is 36736 circles total or 656 holes per surface (36736 / 56 surfaces or 16 * 41).

However, the vertical edges between surfaces have have a pair of overlapping circles on each row, one from each of the adjacent surfaces. So it can be said that 41 * 54 = 2214 circles are duplicated. So 36736 - 2214 = 34522 and 34522 / 61892 = ~55.8% of your circles.

SrfSplit takes a full minute. You can squeeze in more holes if you like, though I wonder if that’s necessary?


project curve_2024Oct26bb.gh (71.3 KB)

Hiding the hole curves:

I haven’t got this worked out yet but it’s interesting, especially because it’s a parallelogram at arbitrary orientation, not a rectangle in a standard plane. 1311 circles instead of 656!

  1. Fair enough, I was initially doing that for the first few versions, will go back to debug, thanks for the reminder

  2. The circles are later grouped per panel, and oriented to a world xy plane, so I run them through a C# script that will turn them into a png, my end goal is to make a bitmap off of it

  3. Project was the first - and only - that came to mind to achieve another goal which was, have a consistent texture for all panels in that specific row, instead of creating a grid that per panel, I created one for all of them. The other method worked but the results were unaligned across different panels.

this one looks super cool, the previous ones are very well optimised, even though they don’t fit to my current goal, they sure are good methods to achieve this

I don’t know what that means? Sounds like we are going in different directions so doesn’t matter.

This has 48534 circles across 56 surfaces (~867 holes per surface). SrfSplit takes 48 seconds.


P.S. This doesn’t use an “attractor” like version ‘Oct26b’ yesterday. Instead, a slider (one per branch) chooses a reference edge. Doesn’t use isocurves either. In theory, it’s designed to work with any planar shape, though I haven’t tested that yet.

There are sliders for ‘Min_R’ and ‘Max_R’ (radius domain) and a slider for ‘Steps’ (rows) that must be adjusted depending on shape and size of the surfaces.


It works :bangbang: :sunglasses: With a few minor adjustments and one obvious flaw, to be fixed.

1 Like