(appologies for image size, blogger thinks its acceptable to convert a 60KB gif to a 500KBpng....)
I was wondering where all the heap space was going- above was a kinda cool looking bug. Its what hapen if the street front of a house becomes reall small. Its interesting that as we take the voronoi to the limit, it creates very 'straight skeleton'-like structures for us...

...a bit more work tinkering with internals and I have a system that gives everybody a garden. The very cool thing in this next grab is that most houses are rectangular. I never told it to do this, it seems to be a fairly fundamental geometric thing - if you want a house near a straight street, then the best shape for it is a rectange. Note the neat way the voronoi deals with the corner cases with minimal effort...!

What we have is a parameters for distance from all other houses, another for distance from the street, which is added to (optionally) on one front to create a front of the house.

Am now really confident in the project. I only have a weeks coding left, but feel it now produces results that highlight the effort thats gone into the mathsay bits. I've also done the analysis on my grades from bristol and it looks like that as long as I pass this I'll get the degree I was aiming for. wooo!

Wont be up to much tomorrow or this weekend. The hippyfest that is the cambridge folk festival is in town... (photos here)

Overview of process so far. I gotta go and plan how to create the houses & roofs nicely!:


Right dissapeared at the end of last week due to lack of ait conditioning and an enthusiastic dentist who decided it would be better to remove four teeth than two...

First up concave tesselation. Basically it works!:

Got stuck on some borderline cases tho. Spent a while looking at it....

... then I got fed up with all that I went on a leak hunt. I found a couple of cases where hashtables of geometry (so that when you click on something we can select the correct waterfall) weren't emptied. This ment 100's of megabytes of geometry that wasn't removed from memory. Creating multiple cities would bring my modest machine to its knees. Tis much better this way.
You can get memory leaks in Java!.

For future reference this is the best way i've found to clear up after a JMonkey swing window. Not sure its leak proof, but isn't too bad:

protected void onQuit()

ListIterator lit = rootNode.getChildren().listIterator();
while (lit.hasNext()) lit.next(); lit.remove();


// the might be to blame for inter-display reactions? (also in MagicWindowMonkey)


for (Texture t: textures)TextureManager.releaseTexture(t);

eventDispatch = null;
geometryToWaterfall = null;
geometryToInPlug = null;
geometryToOutPlug = null;
toUpdate = null;

Next up was some more bug fixing on the Straight Skeleton:
  • If there are still incompleted parts of the puzzle/points still to be processed - these are disguarded, and the appropriate edges added to the output. We might get these edges on a symetrical shape where one point is left between two edge collided pairs on either side.
  • Secondly the steepness of parallel lines' bisectors examined. I think (this should be proved by someone with better abstract thought than me) that more than two fast bisectors cannot co-exist in one active list (see inset)/


First up was a series of test on the concave Voronoi. As you can see it tesselates the enron logo nicely, even with the point on the trunk added last. I expected problems here because it has to trace around the edges to find all the points for the trunk points

Lol, you know when your in trouble when you come to find references for your work and the top google hit is yourself. I think this should be known as the (Ian) Hoyler effect due to the number of his courses where the top hit for a subject is his own website.

Some more testing (I forgot to switch assertions on this morning) and the convex voronoi needed polishing a bit:
Its to do with getting double readings when a bisector enters or leaves a shape due to rounding errors (particularly common in parametric form equations ive noticed....). While the algorithm could be fooled into giving the wrong output, I dont think that case will come up (famous last words I'm sure). "I'm only an undergrad, I'm not paid enough to fix this...."


Here are the diagrams of what was causing a problem on friday with upside down buildings - i'd forgotten that I find the normal of a plane by taking a cross product of its edge-vectors. This only works on a convex polygons without 180 degree (non) bends. I ended up just using trial and error - creating the transform, finding its area and flipping the normal if the area's not positive. I've asked Neill if theres a better way, but I'm fairly any solution would be O(n) in the number of edges, so I cant be far off.

By my contorted time scale I've got 3 weeks left of programming to go (given myself a bit more after last week). I'm a bit dissapointed Ive done so little, but I guess thats how software development goes. I was amazed to find the number of line of code I write each day is only about 500. Feels like a lot more. Lets hope that having my wisdom teeth out on thursday doesn't slow this down any more.

Spent the rest of the afternoon hunting the above borderline bug in the straight skeleton procedure:


First up I got the Vornoi running on dots with regular intervals. This was just a case of breaking many borderline conditions. The diagram below gives the most explainable, but there was also much fiddling 'until it worked'. I'm never happy in these situations, you never know when you might hit the exact case that make it fall over!-

I wrote a lot of code to clean up the Voronoi output. Something that finds the size of a polygon/block and if its smaller than some limit merge it with a neighbouring block. Heres an output of the block map (finally some real results) the cool thing is you can just keep hitting a key and it generates another. I'm supprised how good the voronoi it looks without any tinkering, I was expecting to have to do a lot to make streets look like streets etc...
You can see where some blocks have been randomly merged into their neighbours and where some that were too small also got merged, for example the hammer shape in the middle of the above pic. Solid results at last :)

Every five attempts at running it crashes with a mysterious 'zero length edge' message while shrinking the blocks, I'm about to go and look into it....


Here's a post dated blog entry for monday! I got the different block pattern generators working together. So here are some examples of the kind of block patterns we get out:
As you can can see the mixed one looks really authentic! The only problem is my Voronoi tesselator really doesn't like evenly spaced blocks at an angle, I guess thats tomorrows job.

I also fixed up the straight skeleton to create bevelled edges. This will be used to shrink the edges of the blocks away from the road centres to create a road network:

This got me caught up in fixing a lot of the guts of the sity program to create flat panels in the correct locations!