BRAVO!!! I was wondering about a weighted average but wasn’t sure how to do it. From what I can tell, your solution works fine on both the planar and non-planar cases. I * LOVE* a simple solution! Very nice.

Still, i feel like i “cheated”.

Is like, pencil on paper, comparing a guy that finds the tangent of a circle by drawing another circle and finding the intersection, and another guy that measure distance and diameter and calculate the position of the tangent point. The latter is so uncool!

Geometrical solution is always more elegant and let you really understand what is going on.

A mathematical solution is more abstract.

I’m not a genius, i was reading this interesting thread and only at @akilli 's non-planar solution i understood that weighted average could be used

It does look like it’s correct, so the question is why? Since this all comes down to vector algebra there must be a derivation. Nice work!

Ha ha! Now that I’ve gone over it again I see how I “inspired” you. Once you look at the unfolding into one plane, it’s obvious that its the weighted average along the line. It also avoids the nastiness that @Joseph_Oster mentioned about curve direction.

Even though it seems to work fine in your code *(when you didn’t reparameterize your* `Line`*?)*, this issue of assuming that a ‘t’ value corresponds to distance has been bothering me all day.

So I wrote a slightly different method that applies the weighted average to the magnitude of a `Vector 2Pt` that moves the closest point to A toward the closest point to B. It gives the identical result, planar and non-planar, and also like yours, doesn’t care if the C curve is flipped.

weighted average_2020Aug26b.gh (12.5 KB)

Wow, and wow… I got pulled into a bunch of work stuff all day and just got back to look at all this. You guys rock!

First, Ethan, once again elegant geometric solution in the 3D version of your method --and of course it makes total sense that you just reflect each point in the line on the plane formed by that point and the line --genius!

And Riccardo --your weighted average solution is insanely good! Super simple! And a test confirms that it does seem to work in non-co-planar scenarios! You guys totally rock!

So I’m assuming that we can get away with this only because the curve is a simple straight line… in other words, Alhazen’s Problem gets much more difficult when dealing with curves and 3D spherical mirrors etc…

Again thanks everyone for your work on this!!!

WD

Hey Joseph,

I’m still playing catch up here --but are you talking about the ‘t’ value input for the “Evaluate Curve” component in Riccardo’s Definition?

I don’t think its accurate to say that he is using distance as a ‘t’ value here --the way I’m reading Riccardo’s definition, the value he is feeding into the ‘t’ input represents the ratio of the distance of point A to its nearest point on the line to the sum total of the respective distances of A and B to each of their nearest points on the line…

So in other words --if A and B are both equally distant from the line the t value will be 0.5 (and the reflection point will be exactly in the middle between them. If you move point A closer to the line the t value will diminish until it reaches zero when point A is on the line… If you move point B closer to the line the t value will increase until it reaches 1 and B is on the line… its actually quite informative to play with it and see how the values work!

Also just to note -with this method it matters which point goes in which point-input for the line segment between the two closest points on the line… if you try switching them you will see that the direction of the parameterization will be reversed (so moving A will increase to 1 and moving B will decrease to zero) and the solution will be wrong…

Anyhow --thanks again for all your work and insights into this problem!

WD

I am referring to Riccardo’s definition (@maje90), where the weighted average is used as a ‘t’ input value to `Evaluate Curve`, corresponding to distance *(without reparameterizing the ‘C’ input!?)*. The subject of ‘t’ values vs. length *(or distance when the curve is a straight line)* is more complex than I can explain, even when * Reparameterize* is enabled. In general, one cannot count on the two being equivalent, even though they are in some cases, like this one. My last post addresses that.

What issue?

A pure “Line” object (not “linear curve”) is like already reparametrized: t=0 means start, t=1 means end…

And, as a line have a direct proportion between parameter and lenght, i’ve used t as a factor of the length. (or normalized length)

I didn’t know that. Another special GH feature… But I’ve only been playing with Grasshopper for ~6 years so I still have a lot to learn.

[quote=“Joseph_Oster, post:25, topic:107649, full:true”]

Oops sorry I wrote “Ethan’s Definition” but I meant to say “Riccardo’s Definition”… everything I said above refers to Riccardo’s definition --and I edited my original post to fix that!

Basically, the value he is feeding into the ‘t’ input is not a distance but a ratio --and yes as Riccardo has said the line segment has a parameter of 0 to 1…

That’s the only issue. Unlike curves, a “line” is always *(effectively)* reparameterized AND the 0 to 1 ‘t’ value corresponds to distance along that line.

I know this is getting a bit off topic --but since it came up… does anyone know why curves are NOT automatically parameterized 0 to 1 like lines? Like for example why doesn’t a circle just default to 0-1? I use the Pufferfish “reparameterize curve” tool all the time… is there something I’m missing?

And yet *(when reparameterized)*, circles are apparently in the special family of curves, like lines, where 0.5 corresponds to their midpoint. That isn’t true for many other curves. Which is how I got in the habit of reparameterizing all curves *(including lines)* and not assuming that ‘t’ values correspond to distance *(length)* along any curve. It’s the safest assumption.

Why would you use a plugin to reparameterize curves when that option is available via right-click on so many standard components?

The equations for rolling contact are not that difficult, the real messiness is in calculating the teeth profiles for gearing.

In partial answer to my own question here is a very informative posts by David (see link below).

Most to the point:

“When Rhino makes curves it typically picks a domain from zero to the length of the curve. There is no stringent need for such a choice, except that many algorithms ‘like’ it when the physical size of a curve is roughly equal to its parametric size.”

and also:

“Certain special types of curves have an intrinsic domain. Lines are always (0,1), circles are always (0,π), arcs are always (α0,α1), where the α’s represent the start and end angles of the arc.”

Thanks again everyone for your help!

Circles are actually **0 To 2*Pi**, unless they are reparameterized.

Most importantly, and not explicitly stated in the post you cite, reparameterizing a curve does not guarantee that ‘t’ = 0.5 will be its midpoint *(or ‘t’ = 0.25 will be 1/4 of its length)*. It depends on the curve.

See what I meant by this?

The subject of ‘t’ values vs. length is more complex than I can explain.

Just to get the record straight (since I started this!): I just tested and it appears the default parameter domain for a circle is **(0, 2πr)**… AKA circumference (Unless there’s something I’m getting entirely wrong!) maybe just a typo in @DavidRutten’s original post I was quoting? … or a change since then?

And yes I totally get it about parameter not necessarily being linked to curve length or even proportional to distance… though in the case of circles they apparently are. (though not if they are made into nurbs!)

As to why use Pufferfish “Reparameterize Curve” tool --I like it because it also spits out the original parameter domain which is sometimes useful if you don’t want to actually reparameterize… but just want to know the domain… also just habit I guess…

WD

I’m kind of slow Daniel. It took me a while to realize that you posted this - I believe - because my initial diagram of the two points, regarded as foci, and their reflection in the line, is equivalent to two rotating ellipses.