Sorry, it told me I'd posted too much in a 24 hour period to post again...
(and incidentally I just found a bug in something so I have re-released a new version. I refactored some of my code, and failed to test whether the capaing play command worked properly).
Good question. I used Zennode during the development process, before I'd made a working routine myself. I guess the main reason to build my own was to climb a personal mountain (so to speak), but also that if I released it (as I've done) then people wouldn't need to download another component on top of what they already would need. Unfortunately trying to sort out a node builder algorithm was working out to be hard than I'd assumed. I even looked at Zennode's code to see if I could borrow the algorithm and Pythonise it, but the writer of that tackled the surrounding stuff different to how I'd already done it. So I couldn't just shoehorn it in.
What I ended up with was some code that could build node trees in one direction quite easily, but when it would often choose to go another direction it would then ignore intermittent nodes until it hit a point where it couldn't safely assimilate them into the pyramid. In the end I realised that since my whole sector layout was in a grid I could limit the node collection to rows, then do the top level nodes of each row after that. I even had it spitting out SVG files so I could see what was going on (you'll find the code uncalled in the app, but still enabled). I had intended on letting it build campaign maps in SVG, but realised that this process was really slow, so thought better of it (and one of the campaign map parts is left unfinished in the code as the map ends up upsidedown (you know, positive screen integers go the opposite direction to positive cartesian ones), I never got back to righting it, but the node map was right way up).
You'll find all the node building stuff in the geometry.py module, with the builder object itself towards the bottom. To extend it to cater for any map you need to make one critical change to the subsector production. I could get away with my Sector objects creating just one subsector, because all sectors are occlusion safe. You'd need to have it calculate any breakups of Sectors into subsectors with no occlusion issues before unleashing it on any map. The second problem is then to get it choosing the best subsector to outside the one direction/dimension, without it overlapping and excluding nodes that it shouldn't. This will be doable... probably by someone with a bigger brain than me. You'll find a section in the geometry.NodeBuilder._getBestIndexesToAggregateNext method where I initially had code for non neighbouring collection (thinking nodes that overlap or are disjoint). As the neighbouring aggregations were working well I just cut my losses and got that working for the whole map. There's a lot of redundant code left over because of all the experiments I ran trying to get non-neighbouring nodes to aggregate safely into one big pyramid.
Feel free to extend or improve my code. I release it open source so that, if people find it useful, they can borrow/use it. I'm all for free/libra software :-)
At some point I'd still like to Pythonise the Zennode algorthim just for BSP's, but before I do that I want to C++ise my own algorithm then call it with ctypes to see if it improves speed. Will make a good experiment just for the fun of it.
