## Freesteel Blog

Tuesday, December 19th, 2006 at 5:15 pm

Sometimes you need to check if your calculations are working by plotting the normal vector at each point in the CADCAM model. Some people call this the hedgehog view, as opposed to the solid view, wireframe view, perspective view, etc.

Here I’ve finally managed to get the hedgehog view working for z-profile toolpaths of a tapered tool against a model that is composed of one line segment (not drawn). The hedgehog’s spike vectors are the normals to the plane passing through the contact point separating the model from the tool shape. For points of contact on the smooth faces of the tool, as opposed to a ridge, it’s the normal vector to the face at that point. It’s always perpendicular to the line.

Tapered tools are not simple shapes. I’m going to draw one in SVG at some point; the standard definition of them is a bit mixed up. Basically, you have the flat tip, the corner radius, the conical section, the corner between the top of the cone and the cylindrical shaft, and the cylindrical shaft. The last four components can make contact with the model when it is moved horizontally through space. These components can each collide with points, edges, and facets of the triangulated model (although not every component can touch every part of the model).

In the picture there are normals representing seven different types of contact point: point/corner-radius, point/cone, point/cylinder, edge/corner-radius, edge/cone, edge.cone-cylinder-corner, and edge/cylinder. I’ve not hedge-hogged the facet, but if I did there would also be: facet/corner-radius and facet/cone-cylinder-corner. It’s not hard to get the contact normal to a facets correct; it’s simply the normal vector of the facet.

That’s the basic calculation as it is operated on a single geometric element. Applying it to the whole triangulated model is easy — you just merge all the shapes together — as long as you don’t mind a lot of wasted calculations as the accurate contact values get calculated against elements that are subsequently masked by others. A huge amount of this happens, and optimizating it out makes the whole program super-complex.

I can phrase this claim more simply. Suppose you have a list of triangles:

T = {ti | i = 1, …, 1Billion}

and a function f(t) which takes each triangle, does a very complicated calculation with it, and returns a precise floating point value. All we really need is the maximal value over the set T, or:

max{f(ti) | i = 1, …, 1Billion}

So the deal is we need to go deep into the function f(t) and totally shatter our nice clean modular hierarchical algorithm in order to take advantage of the fact that we can sometimes extract, from the internal calculations of f(t), an early estimate of its final value, which lets us throw away unfinished calculations that aren’t going to be of any use to us. This is where you get bugs — when you do this too agressively and throw away too much.

The overall structure of these implementations is not elegant, and extremely tied to the way that you solve the geometric equations. It’s not possible to predict whether calculating the solution in a less optimal manner gives rise to better partial results along the way and allows for a sufficiently greater proportion of unnecessary calculations to be thrown out to counterbalance this inefficiency.

I’ll check the code in now and let the complaints flood in.

• 1. Jeff replies at 20th December 2006, 5:49 am :

Nice picture of the hedgehog view. Two questions to help me understand what you wrote.
1) what is the the maximal value over the set T? Distance from the contact point in the view along normal vetor?
2) By project sideway, where you choose the start position to try? Do you sort all the non-gouge points into polyline?

Thanks

• 2. Julian replies at 20th December 2006, 3:17 pm :

1) It’s the highest y-value for the points of contact, if you are moving the cutter sideways along the y-axis. It’s the first point of contact that matters — everything else is underneath.

2) You start far away from the model and slide the cutter inwards horizontally along an axis until you get a point of contact. You can do it from the other side too, and this will help you get a contour for a model that is just a convex core.

That’s one way to explain it. If you get two values from each triangle, where it first touches it, and where it last touches it on the other side, rather than one, you can get points on the contours inside. It’s easy to understand, but I lack the notation to explain it as simply as I can explain the {max} function. Maybe I’ll give it a go at some point.