In other words, by selecting the two curves, I’d like to automatically generate a 10-meter line that intersects both curves at the same angle, just like the example.
Any advice on how to achieve this in Grasshopper would be greatly appreciated!
If you know how to code try to implement a bounce solver: i.e. an approach that starts from some approx position (or positions) and then moves “back/front” the Line end pts in an attempt to find some sort of solution (if exists). This obviously works using search Intervals (for the length think something like new Interval(targetLength - delta, targetLength + delta).
Use K2 (kind of "“physics engine”: the most important GH add-on by a huge margin). In fact I have a similar thingy (but where is it? that’s the big question) but is using solely C# code.
A good starting point for the solver would be to offset the curves and intersect these with the base curves. Then just “rotate” to optimize the angles. In case of non-planar curves: pipe it.
I am intrigued with the same questions asked by Inno, plus some other ones.
In your example image the matching angles are both on thesame sideof the line between the variable curves. When you say the outcome should be just like the example are you saying this same-side angle condition is required?
Asking because of a quick thought involving a tween curve between the variable curves and galapagos.
A quick test outputs a line that’s 10.000074 units in length with equal corresponding angles:
In fact I’m more or less oriented towards a Bounce solver approach (pure C#, no add-ons + way faster most notably if you have lot’s of 3d crv pairs: the general case)…
Try:
Define a Class with suitable Properties that monitor the “lines/bridges” (keep track their t1,t2 on both current/working Crvs that yield the “bridge”, plus angles, lengths, cats and dogs). Each var used outside the Class should been declared as static.
Mastermind (using Dot, Cross and the likes) a robust way to define what sort of angles we are after.
Do a first pass (say searching for candidates length). There’s various ways to attempt this (either dividing the Crvs or divide one and get the prox on the other etc etc). Obviously you should search ALWAYS using Intervals (-/+ some delta) otherwise the whole Bounce strategy goes bananas.
For each candidate “i.e. a line/bridge” do a Bounce Recursive search by using trimmed portions of the Crvs (based on candidate’s t1,t2 the Crvs Domain Lengths and some double factor > these yiled the current pair portions to work with). So in the first phase you use the whole Crvs and then trimmed portions that srink for each Bounce loop.
So each candidate should carry info (via the Class in 1) related with the parent Crvs while t1.t2 would be able to define a child (trimmed) Crv to search further etc etc. So each candidate MAY yield a List of candidates (or not).
Obviously you deal with Items of the Type defined in the Class (stored in a List) AND not “directly” with Lines/Angles/Cats/Dogs etc etc.
Maybe a faster/smarter way is to refer always to the OEM Crvs (and then define the trimmed portions using t1/t2 and the related Interval - so you measure once the crv.Domain.Length per pair). If so the Class should not monitor child/current Crvs but the delta below should srink per Loop.
BTW - the Kangaroo definition above starts from the observation that if we have a point whose closest points on each of the curves are an equal distance away, the line connecting these closest points meets the condition of equal angles with the curve tangents.
Another way we can find such a point is by offsetting both curves an equal amount (similar to what Jess proposed earlier) and taking their intersection. This reduces the problem to a 1 parameter search. Here I show how this can be solved with Galapagos:
offsetsolve.gh (11.5 KB)
(An evolutionary solver isn’t a very efficient way to solve this sort of problem though - really what we want for this is something like the bracketed root finding I showed here, but in a Galapagos like component allowing you to select a slider parameter and number fitness.)
Thank you for all the answers. I used them as inspiration to build a Python script that handles the instructions, but it ended up running slowly due to the loop-based approach.
@DanielPiker, I’m very interested in the “bracketed root finding” solution you mentioned. Could you point me in the right direction for applying this methodology to my problem?
I forgot to mention that the lines might vary in their Z coordinates.
