Green green green.

Visited a friend's place today for a birthday party, and spent some time in the gardens photographing some plants.

Originally I brought my LX5 (together with my R05!) along as I planned to go to Belair National Park after the party, but I was rather worn out from interacting with people. I'm glad I had it with me, as I think it did a marvelous job!

The lighting was touch-and-go, and I waited to shoot the shots I wanted only when the sun ducked behind the clouds. I love the exaggerated perspective, with the LX5's macro focusing, at the 24mm equiv it was bare millimeters from the subjects.

Smashing up crates! Roar!

Not feeling like dealing with buying PSN cards, and with the crapola internet connection I got at home at the moment, I decided to pass on FFX for vita and got the Ratchet and Clank trilogy for my vita instead.

Damned, damned good fun, though some of the mini-games take forever to win. I'm constantly amused by the amount of crates left all over the levels.... desert? Crates. Futuristic city? Crates. On a spaceship? Crates. Inside the sewer... you guessed it. Crates.

The controls don't seem to be re-mappable, which is highly annoying when the strafe control is mapped to the rear touchpad.  Not that it matters, not like there's much to assign to; there are only one pair of L/R buttons on the vita.

Maybe FFX when I'm done here.... thankfully these games do not appear to take too long to complete - I'm at the last boss on the first game in about 11-12 hrs in? Bloody difficult boss, wish I had more in-game currency to buy the health bonuses.

Houdini: Extracting Transforms

When you get an animated sequence, and want an object to match that animation (note: In this case we are talking about rigid animation, not deforming characters), sometimes you need to fuss with positions and orientations. One way is to extract the transforms between the rest and target positions, and the difference can be used on other objects which then move the same way as the target positions.

Actually, extracting transforms may not be the best term, but that's what's stuck in my head...

The solution is from the Matrix and Quaternion FAQ, Q40.

And the hipfile can be downloaded from the forums: http://forums.odforce.net/topic/7223-extracting-relative-transforms/page-2

Perturbation Search

Finally got around to posting a video of my experiment as described by my previous description. It definitely achieves my goals of locating a fit individual faster, but it definitely does not search as far a field as a true GA.

I was thinking about this, and solution spaces that contain many optimum solutions. The approach above simply uses the first agent that has a solution and attempts to improve on the solution. This solution, will be located "nearby" in the search space. Every generation without an improved result increases the search area by increasing the range of perturbed values.

If it goes on long enough, this will simply devolve into a purely random search.

I'm also pondering if I were to extend the random search; instead of using the first found individual to lookup a best result, we can continually use the random search, and every individual found put through the perturbation search. That could help locating another optimum solution in a different space.

Interesting questions, however I want to explore other such stochastic search methods. Onwards!

Genetic Algorithm-like algorithm thoughts

So I'm working on an idea that I came up with that _seems_ to work - a way to quickly optimize results around the local optima, and it seems to work. It is no longer a genetic algorithm, but something that will give a *local* optimal result faster, but will take longer to locate solutions in another space.

First, I begin with a broadband random search for an agent of a certain fitness; in my test case, it is to locate an agent that will complete the course under 10 seconds. Once this agent is found, the algorithm will optimize in the local space.

This is not done via crossovers; it is even simpler. The next generation of agent simply starts with the fittest agent of the last generation, and the control values are jittered by a certain delta. This delta is increased when a new generation does not find any fitter results, and is reset to a low value when a new fitter agent is found.

In my tests, the results are quite striking. The modified genetic algorithm yesterday required over 360 generations to find a really fast result; the method mentioned above located an even faster agent under 100 generations.

While running the simulations, the spread of the delta got me thinking about the number of agents looking for a solution.

When the delta is small, the X number of agents cover a certain search region; when the delta gets larger, but with the same number of agents, there are many "spots" where we are blind to the results; there are far more problem space versus agents to run them.

Hence, it is in my opinion that for my particular problem space, with a limited number of agents, the rate of increase of the delta should be smaller, so as to allow the agents more time to search before casting the net wider.

On the other hand, due to the algorithm searching in a very local space, it will take *forever* to relocated to another area with a more optimal solution space (if such a space exists).

I will probably spend another day exploring this, but I want to explore neural networks next :)

Exploring Genetic Algorithms 2

Finally got my prototype working yesterday, and here is a run as it optimizes the agents. Basically once it finds a first suitable candidate, it checks the surrounding for answers, before moving further afield in search of possibly better solutions.

This has given me ideas to possibly make the algorithm locate results faster... but we'll see when I get to coding it.

Classical Guitar

I wish I had my tripod, this view isn't very flattering... :-/

Ah well XD

Adelaide Zombie Walk 2014

The Adelaide Zombie Walk hosts thousands, if not more people dressed up in zombie gear for a fun afternoon of zimbie-ing and at the same time raising funds for a good cause. More details here.

I missed the earlier portion of the walk, I think it started earlier than the stated time and only caught the massive crowds on their way back to Rymill park. Which is sad, as I'd scoped out some places along the path that would look great in a photo but oh well.

At the very least, I got a small video above, and some shots below. Enjoy!

Exploring Genetic Algorithms

The last month I've been spending a short while each day coding up an exploration into Genetic Algorithms. Being the King of Procrastination, I've decided to blog about what I've completed over the weekend, and my next steps.

So, basically my problem is the optimal selection of values for agents to traverse a short course in the shortest time. Several parameters are available, such as maximum forward speed, maximum rotation speed, length of the lookahead sensors, spread of the sensors etc.

We can probably figure out what a good setting is, but the GA will allow us to explore this big problem space on its own, and perhaps evolve a solution that is not logical, but will work very well.

I got the GA working on Monday, and, depending on the run, is able to seek out solutions to the problem. One of the lucky runs found a really fast solution, but the exploration space was not as focused as I liked.

One of the reasons is the way I generate the next generation of agents; they are simply created from roulette wheel selection of the fittest, but it seems like I need to look more carefully into the roulette function as the random function I am using _may_ be more gaussian than uniform distribution, so there is a bias to which parents are chosen. More checking is needed.

While I was pondering about this, I have decided to try a more "directed" kind of GA:

First, I will allow the GA to run, and then choose an "elite" agent, one that fits a certain set of parameters. In my case, my target is to have agents complete the course under 5 seconds (the GA I have now, evolved agents that did it in 4.6 seconds). So, I'll just evolve them as before, *until* I get an agent that can not only complete the course, but can do it under 10 seconds.

(Assuming the GA's run is not soo lucky it gets under 5 seconds on the first run. As the first generation is randomly generated, I've seen some really fast results on the first generation... but I digress.)

This "elite" agent is then kept on, and used as a starting point for future generations. It does not directly enter the pool, but will be used as the one of the two agents to be mated for the next generation. Talk about some serious polygamy here.

The current elite is only replaced by one of its descendents when the descendent has a higher fitness score i.e. faster.

This of course leads to a more localized search of the solution, since it will evolve around the elite agent. To search further, mutation is probably the only way to jump to another possibly more optimal area.

At the moment, my mutation rate varies depending on the spread of the scores of the agents; if the agents have similar scores, the mutation rate jumps to a higher one, in order to search further. If the scores are wide spread, lower mutation will occur.

The theory I have right now is to have a low mutation rate once an elite agent is found, so the GA will explore the nearby solution space for more optimum solutions. As time goes on, the mutation rate will increase if no improved solutions are found; this will, in theory, allow the GA to gradually search further afield. Perhaps, even after X number of generations, the elite idea can be dropped and the GA can go back into the original exploration of the space without being "led" by an elite agent.

Faking RBD/Smoke collisions.

I've never got the default rbd/fluid collisions to work as expected when I've got a rbd object moving through a slow moving/static density field. Think of Balamb Garden flying through a cloud bank. What usually happens is the fluid forms a thin shell around the rbd object, and you can clearly see the rbd object "eat" through the density.

What I really want to see is the smoke part around the rbd object. Usually what I do for cases like these are to use various forces (field force etc) together with keyframing to push the fluid out of the way at the correct time.

Have a shot at work where I want to improve on this, so tried some stuff and this result seems quite usable. Can't wait to test it at work!

City Birds

A very short clip recorded along the Torrens Linear Park, just behind the Adelaide Zoo. A whole bunch of birds in the trees, just as a storm was coming in. I reset the R05 when installing the new batteries, and forgot to switch over to 48/24, and recorded with 44/16. But it still sounds great.

The diy windmuff generally works quite well, and the low frequency wind rumble - it was very, very windy - appears to be well under control.

I also recorded another bit - not uploaded - of the long grasses rustling in the wind, and the wind muff did prove its worth then.

Other things I should remind myself is to test the limiter - some poor sounding peaks were captured, the limiter _should_ help but you never know.

Long Weekend, FF8.

Long weekend! Woot! Slept in then went to the Central Markets for lunch and bought some food for the week. There's just so much there to try out, I am thinking of going there again tomorrow for breakfast.

Went out for a stroll in the evening along the river torrens, but decided I wanted to finish FF8! Been playing an hour or two daily and finally made my way to the last boss last night, but got insta-killed by Griever's final attack, Shockwave Pulsar. Blargh.

Tried again today and read some hints ^_^ and junctioned the characters properly and BOOM! Took it all the way to ultimecia, and she didn't even have time to cast apocalypse before she died. Must admit I was using the Auras that I had on Squall. Even though I don't have the Lionheart, just the Cutting Trigger gunblade, his limit breaks do massive damage. I'm guessing the ease of the win was simply proper junctioning, low levels (squall was lvl 41, Zell and Rinoa were just breaking 30) and abusing the limit breaks/aura spells.

The story is just sooo complex and confusing, and I had to read a storyline synopsys to understand exactly what was going on. Next up is FF9... slowly working my way up to the X an XII remasters :3

Roland R05 First Impressions

About two weeks ago, I was trawling ebay for either a Sony M10 or Roland R05 and this came up. Lightly used, and at a good price, and decided to go for it. My Zoom H1 has been plagued with the poor battery life issue - and this is my 2nd zoom h1 to have developed it - and I really wanted something that plays nice with rechargeable batteries AND has a metal tripod mount. The R05 ticks all these boxes. I'm rather in the mood to write, so here's my first impression of my new toy.

First, the build quality is great. It's lightweight, but has a good heft. The the casing is supposedly aluminum, and the sides are made from a more grippy material, providing a really confident grip when handling it.

There are two inputs, one for line-in, one for mic, both 3.5mm, located between the two built-in microphones. The SD card slot is also located there, and it comes with a 2GB card. The opposite side of the R05 has a slot for a lanyard if you so wish to carry it that way.

The menus are very straightforward, though I had to check the meaning of some technical terms. The file format, bit rate and sample rate are all contained inside the menu system, which I find good as I really just want to record 48/24/wav and not accidently ops set it to  96/24. Batteries, as mentioned above, can be set to NiMH, perfect for use with Enerloops.

No speaker on this little boy, so headphones are required. That said, the speaker on my H1 is near inaudible outdoors, so headphones - probably iems to block the ambience - would be needed.

Input levels are set via +/- buttons on the front face. Unlike the Zoom H1, the record button needs to be pressed twice to fully engage the recording - one to arm the device into standby mode, and another press to begin recording. I would have preferred the way the H1 does it, by having the monitoring to be going on all the time, and only requiring one button touch to begin recording.

Another recording feature I hope will be good to use is the limiter. This is engaged by a hardware switch on the reverse side of the R05, and, if you prefer, the is an option in the menus to use AGC instead of the limiter. Another switch engages the variable low pass, though I'm unlikely to use it. The final switch at the rear chooses the high or low gain for the mics.

Lots of other features are available that I don't have a use for the moment - "rehearsal mode" samples the current input levels and sets the input gain to a suitable level - there is a reverb built in - playback with variable speeds, and many, many other functions.

There is one thing that I am looking forward to test this weekend - how stereo omnis on the R05 compare to the H1's XY co-incident mics in terms of the stereo field.  I also quickly spent some time sewing together a quick wind muff for the R05.

I accidentally trimmed a little too much off the sides - the sides of the R05 are supposed to be covered too but oh well. I've got like loads of fur left over, if this doesn't do well I can build another :)