## Freesteel Blog » Shedloads of code

Sunday, September 21st, 2014 at 3:51 pm

Lot’s of stay-down linking work going on. Sometimes I worry it’ll never work. While Becka has been caving, I’ve been working through the weekends in the empty bedrooms of Bull Pot Farm, (occasionally interrupted by horrible hangovers).

Here’s the checkin changes of a beast of a file.

It’s like building a dry stone wall: I can’t remember any of what I’ve done; I only know what move is next. It’s an incremental procedure. New problem cases crop up, and you go away, have a cup of tea and come up with a solution, and keep repeating in the hope you don’t run out of ideas before it gets fixed.

The basic steps of the algorithm are as follows:

Form the connection between the start and end (hopefully wrapping the right way round these circles which I have artificially knocked out from the allowable area).

Then pull the trajectory tight. (Actually it’s a recursive split at the point of greatest deflection and reconnect algorithm; nothing is “pulled”.)

Cut out and insert some more circles where the trajectory is “pulled” against the stock to push it away.

Apply the “PullTight” algorithm again.

It’s not very fast at the moment, but there is potential. The main characteristic is that it only computes the stock in the areas it needs to as it goes along, rather than finding out the entire cleared area first and solving the connection problem in that space.

This requirement explains why there’s unlikely to be any code around that I could reuse; most people would design this algorithm by starting with an explicit polygonal definition of the free area. I’m beginning to hate writing so much special code like this. It’s good to ponder whether there could have been another way.

Oh, and I did go caving down Magnetometer Pot last Saturday 13th September. The cave is an example of your basic tunnel with lots of randomly distributed spheres, varying from beach-ball size to bean bag size, subtracted from the walls.

It was very wet, which was fine by me, though I hadn’t realized we were on one of Becka’s black book (“Not for the faint-hearted”) tick-off missions, which involved going through a ridiculously tight squeeze and then ten miles of the aptly-named “Rough Crawl”, which was like picking your way through a hawthorn hedge lengthways. I’m sure an afternoon with a lump-hammer could sort this place out.

The camera doesn’t go underground, I’m afraid, so here’s a picture of me in the carpark after the caving trip.

And here’s someone over-doing it slightly with his ladder coiling technique.

On Sunday I sat in the car and read a book about Tom Peters (the wind was in the wrong direction for Whernside) while Becka and Neil climbed the aven at the far end of Eastern Front in Large Pot and killed it. The only hope now is for the other aven to break through to the surface to admit a Wednesday evening digging party easy access to attack the 10m high boulder choke at the end of the passage with hammers and scaff poles for a couple of years. That’s long term. The only other dig I know is in Ireby 2.

Meanwhile, Becka has discovered a new game for Thursday nights: a no rule game of canoe polo in the docks in the dark. I think this could evolve into a new sport of canoe rugby (similar to underwater rugby) given enough time.

All hopes and dreams are looking forward to Monday the 6th of October. Big juicy announcement/rant coming up then.

I must, must, must finish my work first.

• 1. PeterK replies at 2nd October 2014, 2:38 am :

Hey, I desire access to the zslicer for linux, but the link isn’t there (seemingly intentionally), and the email below is bogus (hopefully unintentionally).

-Peter

• 2. anders replies at 7th October 2014, 5:19 pm :

Julian:
Better still, write a few blog-posts explaining clearly the ideas behind z-silcer!?!
That way enthusiasts will write an open-source algorithm.

I think I mostly understand the axial tool projection stuff, but exactly how the basic radial tool projection functions are used together with an area model to produce waterlines is still a mystery. There must be some topology-oriented ideas here where correct connectedness of the area-model is more important than numerical stability of the cutter-projection function in corner cases.

Peter:
my opencamlib has a waterline function – if that is roughly what you are looking for: