Tween tweak?

You could consider adding location cylinders?
So machine what you can but add dowels to the sculpture that can be used to locate it in a different orientation to allow machining difficult areas or to finish the base.
Then get the sculptor to grind off the dowels and smooth them off by himself :slight_smile:

I’m using 3 axes only so I always machine from a sized block that I flip over on dowels to locate before machining the other side. I always have a lot of sanding to do where I have overhangs that can’t be reached or vertical sections that are awkward to create a good machining strategy.

You have the advantage of 5 axis but perhaps you could machine it into a block that can be located on dowels and flipped but take advantage of the 5 axis to get into the overhangs. Just because it is a long thin piece that could become unstable.

Love the project though… it’s like next level chainsaw carving!
Hang on… just create a chainsaw attachment for the robot! :slight_smile:

The turntable is quite handy because it always orients the part in a practical way for the robot to mill.
Overhangs are dealt with by inclining the spindle, although sometimes, I need to place limits on the angle by adding some kind of smoothing function between “ideal” angle and “doable” angle.

You saw that IaaC video, right ?
Heck yeah ! :slight_smile:

Hi Daniel,

After a little tweaking (the “Length” input in the “TriRemesh” component is critical), I was able to generate excellent tween curves with no overlaps ! Thanks !
Only issue : since the output’s tree is flipped (Branches correspond to “layers” of resulting tween curves, and not by set of input curves), I’m having the following issue :
since all the bits of curves are not joined properly, I get the wrong number of output curves, and it messes-up the “Flip matrix” operation.

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.)

1 Like

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 :crazy_face:

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 :slight_smile:
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:

5 Likes

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.

6 Likes

Not what I was trying to do here, but sometimes the bugs you encounter with this can be fun:

3 Likes

I just woke-up from transe after looking at this… how long have I been away ?
:smile:

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.

1 Like

Fantastic.
Meanwhile, I had found this simple hack :

1 Like

It works great, but the data is flipped again :confused:

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.

This “B” seems to pose a problem.
220506_IMG_Gradient fail.3dm (155.3 KB)

'kind of nice, though…

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