## Drop cutters Monday

Monday, February 12th, 2007 at 3:06 pm

I’ve got quite a few distractions this week, so it’s not realistic that I will be able to completely rewrite the cutter location code by Friday to be fast, but I’ll have a go. I started working on it last night and have the initial interface of it sorted out.

The main innovation is that, rather than building a machining strategy object (eg pencil milling), and posting a surface to it, followed by posting a set of parameters to define a cutter shape, I’m going to have an intermediate object called ToolSurface which takes just the triangulated surface and the tool shape. And then that is going to be added to the pencil milling object, followed by the other parameters that it requires (eg bitangency angle).

This is an interesting change in structure because it gets round the fact that these algorithms don’t want to have anything to do with the surfaces; they only want to know where to put the tool. This is a really obvious modularization I haven’t done before.

Most of the speed is going to come from optimizing the boxing (bucketing) of the triangles in the most efficient way for the given toolshape. The speed comes from scanning as few triangles as possible.

There are several files of Danish code doing this precise algorithm which we have been relying on so far. However, after looking at it long and hard, I can’t see how to salvage anything from it. It’s full of all kinds of arrays of function pointers and is truly unnecessarily complex. It doesn’t matter for them. According to the scientists, the Danes are the happiest people in Europe by far, and no one can work out why.

### 1 Comment

• 1. Neel D replies at 16th February 2007, 5:01 am :

>> Most of the speed is going to come from optimizing the boxing (bucketing) of the triangles in the most efficient way for the given toolshape.

Does this mean you calculate axis aligned boxes or octree and then optimise droping and caluclating cutter location based on initial XY positions.