I think your accumulate_rotations will access two past the end of rots. My
equivalent code looks like this:

let(len = len(path),
    n = len - 1,

    tangents = [tangent(path, loop ? n : 0, 0, 1),
                for(i = [1 : n - 1]) tangent(path, i - 1, i, i + 1),
                tangent(path, n - 1, n, loop ? 0 : n)],

    rotations = [for(i = 0, rot = rotate_from_to([0, 0, 1],

tangents[0], tangents[1]);
i < len;
rot = i < n ? rotate_from_to(tangents[i],
tangents[i + 1]) * rot : undef, i = i + 1) rot],

The third section of the C style loop gets executed before the test
condition.

On Fri, 1 Feb 2019 at 17:14, Ronaldo Persiano rcmpersiano@gmail.com wrote:

A slightly more readable and more complete version:

//
// Calculate the unit tangent at a vertex given the indices before and
after. One of these can be the same as i in the case
// of the start and end of a non closed path.
//
function tangent(path, before, i, after) = unit(unit(path[after] - path[i])

• unit(path[before] - path[i]));
  //
  // Generate all the surface points of the swept volume.
  //
  function skin_points(profile, path, loop, twist = 0) =
  let(len = len(path),
  last = len - 1,

    tangents = [tangent(path, loop ? last : 0, 0, 1),
                for(i = [1 : last - 1]) tangent(path, i - 1, i, i + 1),
                tangent(path, last - 1, last, loop ? 0 : last)],
  
    rotations = [for(i = 0, rot = rotate_from_to([0, 0, 1],
  

tangents[0], tangents[1]);
i < len;
i = i + 1,
rot = i < len ? rotate_from_to(tangents[i - 1],
tangents[i]) * rot : undef) rot],

    missmatch = loop ? calculate_twist(rotations[0], rotations[last]) :

0,
rotation = missmatch + twist
)
[for(i = [0 : last])
let(za = rotation * i / last,
t = orientate_r(path[i], rotations[i])
)
each transform_points(profile, za ?  m_rotate([0, 0, za]) * t : t)
];

On Fri, 1 Feb 2019 at 17:42, nop head nop.head@gmail.com wrote:

Yes I made my tangents units to simply rotate_from_to. My version currently
looks like this:

//
// Computes the rotation with minimum angle that brings UNIT vectors a to b
// the code fails if a and b are opposed to each other unless a third vector
// is specified to break the ambiguity.
//
function rotate_from_to(a, b, c) =
let(axis = unit(cross(a, b)))
axis * axis >= 0.99 ? m_transpose([b, axis, cross(axis, b)]) * [a,
axis, cross(axis, a)]
: a * b > 0 ? m_identity(3)
: assert(!is_undef(c), "path
doubles back on itself")
rotate_from_to(a, b + c / 1000);

I am still experimenting with different ways to decide the first rotation.

Why do you dot axis with itself before making it a unit? I don't really
understand how that test works. The dot product of a and b gives the cosine
of the angle between them does it not? +1 if coincident and -1 if opposed.

A very odd thing happened today. I spent the morning trying to speed up the
code drawing my ribbon cable but none of the optimisations made significant
difference. It was stuck at 11-12 seconds. I went for a walk, came back and
tidied up my variable names to be more meaningful and it suddenly runs
twice as fast in 5-6 seconds. No idea why as I didn't change anything
significant.

On Fri, 1 Feb 2019 at 20:18, Ronaldo Persiano rcmpersiano@gmail.com wrote:

Not sure if this is useful to the current discussion, but this is my
version of "rotate_from_to" that I think is pretty robust.

function normalize(v) = v/norm(v);

// return a(any) unit vector which is orthogonal to the input
function get_orthogonal_vector(v) = v.x == 0 && v.y == 0 ? [0,1,0] :
normalize([-v.y, v.x, 0]);

function angle_between_vectors(v1,v2) = acos((v1*v2)/(norm(v1)*norm(v2)));

// rotate from vector v1 to v2
module rotatev(v1, v2) {
    //echo("v1", v1, "v2", v2);
    a = angle_between_vectors(v1, v2);
    v = (a == 180) ? get_orthogonal_vector(v1) : cross(v1, v2);
    //echo("a", a, "v", v);
    rotate(a=a, v=v) children();
}

On Fri, Feb 1, 2019 at 2:50 PM nop head nop.head@gmail.com wrote:

Nice. I will wait your conclusions before updating my repository.

The test axis*axis>0.0001? checks whether the vectors a and b are (almost)
collinear. We don't need that axis be unitary. As a and b are unitary, the
cross product norm is equal to the sin of their angle.

A very odd thing happened today. I spent the morning trying to speed up the

Sometimes, I have a goblin around here too...

aligned in a vertical line once the initial few tangents are all equal.

I don't have any redundant points in my paths, so there will never be three
co-linear points. If the first two are in a vertical line then the third
one is not.

This is what I don't like about the fixed flip method:

[image: image.png]

These are three point extrusions of an L shape, going downwards, rotated to
8 orientations around z. The yellow ones start with a vertical segment so
get a fixed starting position. The grey ones have a very slightly off
vertical segment so they flip one of four ways due the minimum rotation.
This is what I mean about discontinuity of behaviour. A very slightly
different path gives a completely different result.

With my perturb in the direction of the second tangent method I match the
flips.

[image: image.png]

However this is totally different to what happens when the path goes
upwards as it then always starts at or close to the identity.

[image: image.png]

This is what happens with a Frenet-Serret style starting frame.

[image: image.png]

The shape of the sweep is now invariant under rotation and there is no
special case for straight down. There are no discontinuities of behaviour.
I.e. a small change in the sweep path never makes an abrupt change of shape.

On Fri, 1 Feb 2019 at 18:10, nop head nop.head@gmail.com wrote:

Because  [[1,0,0],[0,-1,0],[0,0,1]] is arbitrary, you can just as easily
flip it three other ways and be just as valid, and other nearly vertical
paths do, and so a minute variance in a path pointing almost straight down
cause a big change to the results, which I don't like.

Using FS means there is a single valid result and I can predict what it
will be.

On Sat, 2 Feb 2019 at 13:14, Parkinbot rudolf@digitaldocument.de wrote: