## Free orientation passes in the tool surface

Tuesday, August 20th, 2013 at 1:16 pm

Sometimes you get a feeling when you start an idea that you’re going to spend the rest of your life debugging it to make it work.

The idea behind Adaptive Clearing just worked the first time I implemented it. The theory behind it is fundamentally sound. Trajectories in 2D are unambiguous, and you know when they come close and cross.

That’s not the case with the development of this strategy. TO make it easier I forced very fine subdivision onto the tool surface, that archives to about 80000 edges in 52Mb. It’s far too big for my WebGL visualizing development environment to render all at once, so here is part of it.

Then I attempted to make a few tracking algorithms. So far I have no positive results for tracking the grooves of this impellor.

In fact, tracking across the polygons within this faceted manifold has not been obvious. Here’s what’s happening:

I have the tool surface (blue) into which an interlinked system of rods (grey) are embedded. These define polygons. I attempt to track a path through it (red) from one rod to the next across each polygon. The difficulty is understanding the direction.

Suppose I go from point a to point b across this polygon.

In 2D I can pick a direction vector and cut the polygon in half: the sign of the dot product between the clockwise perpendicular vector and the vector to each vertex separates the vertices into two halves. The zero point on a rod whose ends are on different halves is what I aim for.

It might seem like an obtuse way of doing it, but this is a stable calculation that’s going to hold even for an ugly polygon with thirty thousand vertices, some of this are exactly in line with the direction vector.

On a polygon in free 3D space, I have to cut with a plane (green) rather than a direction vector. The plane is defined by its normal n (so that part is similar to the 2D case) which separates the nodes that are to the left and to the right of this plane.

The problem I’m having is that this plane can spin round on the axis between points a and b and still represent the same direction — although when it comes to seeking to follow the grooves of the part, the orientation of this plane effectively defines down and into the part.

The exact orientation you choose defines your up and down, into and out of the part. You could alter this by 45 degrees one way or another, and it would hardly make a difference, although the exact line in the groove that was considered “deepest” would vary. If you take away gravity it’s hard to define what it means to follow the the bottom of a valley.

Deciding I could get it good enough, I moved on to the second part: make a new path, offset from the first by a fixed distance. Initially I tried this using a force field with an acceleration.

```path1 = {sequence of points and connecting edges following a groove}

path2 = {path that tracks in parallel to path1 a distance s to the side}

p = current final point of path2
v = direction from second to last point of path2 to p

p1 = closestpoint(p, path1)
= point in path1 of closest approach to p

va = (p1 - p) * ((|p1 - p| - s) / |p1 - p|)
= [vector that pulls p in the direction of p1 when the two are more
than distance s apart, and pushes away when closer]

nextv = v + va * delta
nextp = p + vnext * [distance to other side of polygon]
path2.append(p)
```

This goes all over the place and doesn’t work. If you think about it, when p is at exactly at the offset distance, there is no force applied to it enabling it to follow path1. So will constantly be overshooting, sometimes by so much that it goes to the other side. This approach could only work if done with a very small stepover — small delta and either small polygons or steps that are sub-polygon.

How did I get this sort of thing to work in the Adaptive or scallop machining algorithms, I wondered.

Turns out you need your second path to follow a boundary condition.

```As above, but with p on a polygon:

q0, q1, ..., qn

where p is on the line q0q1 and

|closestpoint(q0, path1) - q0| > s
|closestpoint(q1, path1) - q1| < s

[the polygon goes clockwise and path2 is to the right of path1]

Then find i such that

a = |closestpoint(qi, path1) - qi| < s
b = |closestpoint(qi+1, path1) - qi+1| > s

and set:

m = (s - a) / (b - a)
nextp = a * (1 - m) + b * m

so that:

|closestpoint(nextp, path1) - nextp|= s

approximately enough.
```

The result, subject to lots of glitches and paths getting reversed when the polygons are too misshapen, is like the swirls on a fingerprint.

This is sort of what I was hoping, though it doesn’t look quite so good now I have seen it. Each offset gets more and more out of line with the channel the initial pass followed.

So I am back to thinking that these channel passes are the most important thing, defining the ideal passes which everything else fills out from. Kind of like pencil passes with scallop offsets. Except maybe it can be done with a little more flexibility as to the distance of the offsets to spread them out more evenly.

How am I going to work out what’s up and what’s down? I think I’m going to have to fill in these little polygons between the rods with surfaces made up from tool projection sample points along interpolated vectors and hope this gives me some features to follow.

As if the data structure isn’t complicated enough already.

### 1 Comment

• 1. Freesteel&hellip replies at 9th September 2013, 11:58 am :

[...] my work attempting to create five axis toolpaths using tracking methods, I’ve fallen back to the more conventional techniques used to create 3-axis toolpaths of [...]