Great, glad it helped.
For the output data structure, is this better for what you want?
interpcrvs_flat.gh (13.5 KB)
(I like the chainsaw robot, has anyone put an axe on a robot arm yet? It would be fun to see it swinging and hacking away, though I imagine rather challenging to control with the momentum and variability in how the wood splits each time. Probably requires rescanning between each stroke.)
OK, I managed to get my data orgered with a lot of head scratching and tree-climbing.
Here’s the difference between tween (white) and heat transfer (orange) :
The downside of this method is that it will produce more uneven milling depths :
Maybe I should tween between “tweens” and “heat gradient” curves 
There was a discussion about chiselling a mesh to make a sculpture that I thought could be great for a robot with a chisel on the end.
An axe on a robot would be a challenge to program!
Ha ! It’s the second time this week someone point me to Laurent’s post.
Yet, this could be achieved with a spherical end-mill, right ?
I like the idea of using a chisel as much as any other lad, but…
By the way, I suppose that the analogy is closer to a gouge than a chisel.
I think actually chiselling with a robot in real life would be very tricky too.
It seems that unlike milling where you can know in advance that the material removed is going to be fairly closely that swept out by the path you programmed for the tool, with each chisel cut exactly what comes off would vary depending on the grain (even more so with an axe, plus the added challenge of keeping things steady with that much mass swinging around).
Milling something that looks as though it was chiselled/gouged seems like it would be easier though.
@osuire for the spacing - I think in general if the inner contour and outer contour are both fixed, there’s no way to tween between them with smooth closed curves in a way that gives even spacing, because you have to fit the same number of curves through the narrow gaps as the wide ones.
Do you actually need the outer curve to be the outer boundary though? If not, then offsets might be better
Well, something looks a bit hard to chew with my input data, for this new version …
Sending the curves via PM…
I’d figured that one out 
If you look a bit closer at my image, you’ll see that the tween on the outside (near the bark, I guess) follows the shape of the tree more closely.
Therefore, there will not be that very deep milling pass as with the “heat gradient” curve.
Something “in between” would be fine…
Giulio Brugnaro did a PhD on adaptive robotic carving as part of the InnoChain grant, very cool work:
For making the contours more evenly spaced, it might make sense to include the other part of that heat script (I took those lines out in the scripts posted above because I didn’t realise it was relevant here).
The method for geodesics that was my original inspiration there uses the heat flow to get a field with the right gradient directions, then keeps these directions fixed while adjusting the magnitudes to get even spacing. With the iterative approach I was taking though, we can also choose to let the directions change during the second part, meaning they sometimes get a bit more ‘wiggly’ in order to achieve more even spacing.
Not what I was trying to do here, but sometimes the bugs you encounter with this can be fun:
I just woke-up from transe after looking at this… how long have I been away ?
Here’s that spacing version.
heat_spacing.gh (84.5 KB)
Note though that more even spacing does come at the cost of reduced smoothness.
For some curve sets the spacing optimised one might have isolated islands with saddle points in between, while the purely smoothed one has only simple loops.
Fantastic.
Meanwhile, I had found this simple hack :
It works great, but the data is flipped again 
Hi Daniel,
How can I stop this from popping up each time I open the definition ?
After this, it also asks for the .gha file.
They are both in my GH libraries folder already…
EDIT : I just saved the definition after having redefined the paths, anf I’m fine.
You need to give the ‘coldpoints’ input as a list. When they are on 2 separate paths it generates 2 different solutions, one for each hole.
When they are a single list it solves as a combined thing
