Yeah, it’s backwards - you were using t to get X & Y, which is why I wanted to rearrange for t, so that I could instead supply X & Y - but cycloids don’t really work like that - you end up with either “x / r = t - sin(t)” or “y / r - x / r + Cos(t) - Sin(t) + t - 1 = 0” - not super useful.
What was interesting though is that the equation for Y gives us a height (1-Cos(t)) - so if we say this is our Z (height) - then we can map it onto a circle (x = Cos(t), y = Sin(t))
z = 1-Cos(t)
x = (R + z(t)) x Cos(t) = (R + (1-Cos(t)) x Cos(t)) (I called it K as shorthand that it’s a constant)
y = (R + z(t)) x Sin(t) = (R + (1-Cos(t)) x Sin(t))
However the fun part happens because we’re not supplying a linear t - we’re pulling it off a variety of other geometry (grid, radial grid, torus) giving us more complexity and way less control - however if we supply regular values, we get something much more readable - a cycloid around a circle:
I’ve been watching this thread for a few days, I just wanted to play with cycloids as well
edit: it’s not a proper epicycloid though
and just thinking further, I guess that means that you could apply this to an arbitrary curve provided you could generate aligned PFrames - so for the precision you’re talking about, we can see in Martin’s screenshot that the X distribution is not even, which is why I think the rolling wheel approach struggles
Oof, I’m close with it - I just have one puzzle left that I’m drawing a blank on.
I’ve got the uneven distribution done, which is great, because it always identifies the kink in the curve, regardless of the number of points (within reason). The key is to use the curve length rather than the domain (since the latter can get stretched, Curve Parameter Space – Bugs for breakfast )
Using the axes of the PFrame we can get the cycloid curve. However, getting the cycloid curve to be the same length as the original curve is still problematic:
i.e when the radius is 0.846, it generates points for 0.846 of the curve - and you would think, well easy enough, just multiply the length by 1/x (in this case 1.182) - however that still leaves a tiny incomplete tail - I’m drawing a real blank on how to rearrange this so that it divides the whole curve (and I have a horrible feeling that the answer is actually based on rearranging for t)
Agreed. But not so sure about Kangaroo. And I bet Leibniz and Newton would have appreciated this thread – and argued about it! (“ex ungue leonem”, the lion is recognized from his claw)
Having struggled with this for awhile (too long considering I have no use for it), it’s easy to see why PFrames(plural) or Range or Series are so attractive, not only for precision but because it looks better.
When the ‘Count’ slider is set to two, ii creates lines.
When the ‘Count’ slider is set to three, ii creates planar curves.
When the ‘Count’ slider is set to four, ii creates 3D curves.
The slider connected to Dom allows part of the curve to be used (SubCrv)
That “path generator” could use Data Output to pass the curve.
I was fooling around with purely cosmetic changes and thinking about how to avoid that “one manual setting (‘maxD’ slider in blue group)” (which is bogus and bothered me) when I made a horrible discovery - the ‘top’ and ‘inside’ modes fail to isolate segments between peaks properly while ‘bottom’ and ‘outside’ modes appear to work as expected?!
Can you see the problem? The yellow segment is easy to see.
I still don’t have a solution but do have a clue (theory) about why this might happen? Easiest to see on the ellipse-based path in the earlier post, ‘inside’ mode… When the cycloid curve is “inside”, the PFrames tend to converge (overlap), whereas they spread apart when “outside”.
To some extent this also happens in “top” mode since the “ellipse” droops downward, making the PFrames converge, whereas they spread apart in “bottom” mode.
Just a theory. The same happens with random paths but is more difficult to see.
As intriguing and challenging as this problem has become, I suspect the arbitrary path is more complex (and impractical?) than what Galileo considered. I might get back to it but have other things to do. Before I go, I’ll post and explain what I have.
Increasing ‘Count’ hides some problems but not all. It doesn’t affect the number of peaks, which is solely a function of path length and the circumference (radius) of the rolling wheel.
The main improvement in this version is how the number of points between peaks is determined (components in the light yellow group, in the white group on the right).
Otherwise, the basic functionality is the same as the version in my second post, ten days ago.
Here’s how the points from the expression could be mapped to an organic curve optimized to a length of a multiple of two pi assuming the wheel always stays upright…
