Archive for the ‘Otaku’ Category

Mortar Headd Engage

Tuesday, March 17th, 2015

I received this model kit for Christmas from my brother:

IMG_6196 1

I’d always been a fan of the design of the mecha in this series, but this was the first time I would build a kit. It’s made by a company called Wave, who I’ve never made a kit from before. I planned to do the best I could, since I wanted to get it looking as much like the photo on the packaging as possible.

Here’s the contents of the box:

IMG_6202

Two things stood out: firstly it had water-applied decals (yikes!) and secondly this was not a snap-together kit. The latter was unusual, since the kits I’ve made by Bandai or Kotobukiya are snap-together and have been for many years. I had thought that kits that needed gluing were restricted to military-style models, and this is certainly the first mecha kit I’ve made that has needed glue (in 15 or so years).

I briefly started with some crappy glue I just happened to have on hand before buying this stuff:

IMG_6297 1

It’s very fluid – like waterย  – and does an extremely good job. Recommended if you want to make a plastic model kit.

The Mortar Headd is assembled in 7 stages which will be put together at the end. You start with the body and waist, and very quickly I found that this was no beginners model. Parts were designed to be movable even after assembly, and very often the assembly itself was fiddly (even irritating) and required very precise glue application:

IMG_6211 IMG_6299 1

It was also apparent that they didn’t go together as perfectly as it seemed they should. I’m not sure if this was a molding or design issue, but sometimes there were hairline gaps between pieces (even after gluing) or they didn’t match together quite right. Some of the piece design was questionable as well and seemed only to increase the piece count. For instant there were cases where tabs (to insert into other pieces) were glued on separately rather than molded, or when obvious single pieces had been split into two for no apparent reason. This leg for example has about 40 individual pieces in it and was a real pain to assemble:

IMG_6376 1

Before I get to the end comments, I invite you to speculate as to how easily this kit may stand given the design of those feet? ๐Ÿ™‚

IMG_6302 1

The hands were particularly bothersome. You are given a choice of eight different styles (per hand) with many different pieces from which to assemble them. Unlike most other kits of this type, rather than simply make one articulated hand you’re supposed to choose which weapon or position you want the kit to have and then pick the appropriate hand for it. This would be ok in theory if
1) The hands were easy to switch (which they absolutely aren’t), and
2) The hands actually held the weapons they are supposed to (again, they don’t)
So one of the final steps – making and fitting the hands – ends up being one of the most frustrating.

IMG_6379

Building the kit took many hours. This was because the pieces were tiny, needed a lot of cleaning up (the connections to the runners were often positioned poorly) and because the glue – while very good – had particularly strong fumes which necessitated working in small periods ๐Ÿ™‚

But eventually the pieces were all together, and it was time to assemble the final product. Here’s a shot pre=assembly:

IMG_6382

And here he is about thirty very frustrating minutes later:

IMG_6383

During assembly the head, hands and part of the waist broke. I was able to fix the head and waist, but the thumb on the hand broke cleanly off (not along the glue line) so he ended up thumbless. All these breaks occurred because of the force required to attach the limbs via ball-and-socket joints. Again, I attribute this to poor design. It would have been vastly better (a la the Gundam model) to built a skeleton first them put the armor on afterwards.

You can see he’s still unfinished. It was time for those pesky water-applied decals:

IMG_6412

Putting them on wasn’t so bad, but it turns out they aren’t quite the same technology as I remember from my youth. To be specific, there is no adhesive in the decal binder anymore, and surface tension is not enough to hold them on to the model when the water dries. You are supposed to apply a binding agent both before and afterwards, which ‘melts’ the decal plastic onto the kit. I had no idea of this, and was quite surprised when they all started flaking off shortly after application!

But I snapped a few photos first. Here he is post-decal and with some (unimpressive) detailing using a Gundam marker. Even between these shots you may notice some decals have come off:

IMG_6420 1

IMG_6427

Don’t be fooled by him standing. It took forever to balance him and if I even thought at him the wrong way he fell over!

As you can see he’s nowhere near as impressive as the packaging, since he obviously requires a lot of detailed paintwork to look perfect. I’m happy enough with how he ended up though, given the frustrations and difficulties I had with the kit!

Last word: if you’re after a robot model kit, avoid Wave! Go with Kotobukiya (incredibly complex and detailed snap-together kits) or Bandai (slightly simpler but no less impressive snap-togethers), both of which produce easier-to-assemble models that are technically more impressive than this one.

If only Kotobukiya would get the FSS license…

How Far Can You See In The Woods (part 2)

Saturday, March 14th, 2015

If you’ve been reading the comments of the previous blog post, you will have seen Bernard coded the simulation I described. You can play with it here. This simulation doesn’t answer the original ‘field problem’, but instead the more general problem of ‘can you see your friend if you’re both standing in a forest’?

{A quick note: if it appears to crash your browser, just force-quit because the code is in an infinite loop. This happens a lot with high wood density and low tree radius. On an ipad, force-quit by returning to the home screen then double tapping the home button and swiping the browser up to close it.}

I’ve done some analysis using this early version of the simulation, and here’s a table of results:

Screen Shot 2015-03-14 at 8.24.51 AM

That’s a surface plot of the percent chance to see your friend indexed by wood density (0.1 = 10% trees) and tree radius. A few comments:

– The distance between you and your friend is randomized.
– The tree position is randomized.
– The tree radii are unphysical, and the code doesn’t seem to support non-integer (cm) values.- I used 2500 trials each, except when radius was low (percentage ~ 0) where I dropped to 250.

Interestingly you can see the percent chance increases with tree size, but decreases with wood density. You are more likely to be able to see your friend if the trees are large, and less likely if they are close together. Currently there is no upper-bound on tree size, and it seems the percent chance simply increases as they get bigger and bigger.

As for the distance question, I’m happy to report that Bernard also added metrics to help you calculate this. I’m going to pick 20% wood density and 7m tree radius (!!) as an example. Here’s a simple representational plot of one such forest complete with friends:

Screen Shot 2015-03-14 at 8.20.23 AM

In the above – generated by the simulation – the friends are far apart and can’t see each other. The obvious question is what is the relationship between distance and ability to see each other, and here are the metric results from 1000 trials with these parameters:

Screen Shot 2015-03-14 at 8.20.38 AM

We can’t read too much into these since position is randomly chosen, but on first glance it seems (in this case) the friends were more likely to see each other at about 50 meters. However if you look at the bottom plot, you’ll notice there were quite a few occasions around the 50m mark where they could not see each other. I’d estimate about 20 or so, which means only about a 60% chance (seen/total) of seeing each other at about 50m. Glancing at the two plots it is, as we’d expect, the case that the chance to see each other decreases with any distance beyond standing adjacent.

So the results are interesting, but these are early days yet. Were I to modify the current code, here’s what I would do:
– Input wood density input as an integer between 1 and 99
– Input tree radius in cm
– Output result plots as percent chances per distance – one plot, rather than two, of (times seen at that distance)/(total times separated by that distance)
– Add variable tree radii
– Add foliage transmission support- Make the map circular, and distribute the trees according to a Gaussian distribution (this is more physical) {This may be for V2.0}

If and when these adjustments are made, you may see part 3 of this post ๐Ÿ™‚

How Far Can You See In The Woods?

Thursday, March 12th, 2015

This is one I’ve been thinking about for a while: how far can you see in a forest?

pine

I’ve always been intrigued by the effect forests have on our vision. Even in forests where trees are far apart that you can’t touch two at a time, you usually can’t see too far. When Bernard and I went up to the Grand Canyon last year, the forests there are very light on underbrush and the trees have a decent distance between them and you still can’t see much further than a few dozen feet. When I was camping in January and I got up early and saw pademelons everywhere, I couldn’t see them beyond a few meters into the woods.

So I’ve been thinking, is there an equation that governs view distance in a forest? Which naturally led me to try and devise one myself.

newmexico

Once you sit down and think about it, you find it’s a bit of an open-ended problem. So I decided to start by thinking about an easier problem, and then expanding from there. So consider this one:

You stand somewhere on one side of a flat field, and your friend stands somewhere on the other side. The field is full of trees. What is the percent chance you can see your friend?

This is not a brain teaser with an easy answer, and the result will depend on many things:
– Where you stand
– Where your friend stands
– The size of the field
– The number of trees
– The size of the tree trunks

Problems with many unknowns can get difficult to solve quickly, so the first step is to eliminate some. The first two (location of you and your friend) can be expressed as the distance between you and them. The last three (field size, tree count and tree size) can be expressed as a ‘wood density’ (ie. the total cross-sectional area of the trees divided by the area of the field).

I speculate the general solution is some function of the distance between you and them, and the wood density. But how does one calculate the result?

Dense-forest2

As I teach my students, always approach a problem from extremes. The two extremes here are easy:
– If the wood density is zero (there are no trees) the chance you can see your friend is 100%
– If the wood density is 100 (the field is chock-a-block with trees) the chance you can see your friend is 0%

So we expect an answer somewhere between 0 and 100%. This may seem trivial, but there are problems in which the percent range can be much tighter and it’s useful to know we have the full 100%.

But what if there is only one tree? Consider these possibilities:

Screen Shot 2015-03-12 at 9.02.17 AM

On the left you (A) can’t see your friend (B) because a tree is smack in the middle. In the middle you can (the tree doesn’t block your view), but on the right you can’t either because the tree just blocks your view. Any general solution must account for all such possibilities (and an infinite amount more).

So how to calculate a percent chance for one tree? There is no way I can surmise to solve this via a general equation solution, so the required tool is computer simulation, specifically Monte Carlo simulation. In essence: generate a very large amount of ‘maps’ (of you, your friend and one tree) and calculate the percent chance from solving each and adding them.

For instance, if the only possible configurations were those shown above, the chance of seeing your friend would be 33.3% (only one in three maps). Of course there are many, many maps though (as many as you want actually), and it would be impossible to solve them all, so a more rigorous method is needed.

forest

Here’s how I would do it – and I welcome any theorists to give their techniques in the comments. This is (at this point), for one tree only:

1) Randomly generate your position (A) on the edge of the field
2) Randomly generate the position of your friend (B)
3) Determine the vector connecting the two of you (AB)
4) Randomly determine the position of the tree
5) Determine if the vector between A and B is blocked by the tree

This last step is trickier than it sounds, and the easiest way to do it (aside from a clever technique I discuss below*) might be to:
5a) Calculate the vector passing through the center of the tree perpendicular to the vector AB (this just requires some vector algebra)
5b) Calculate the intersection of these two vectors (more vector algebra)
5c) Calculate the distance between the point of intersection and the center of the tree (easy)
5d) If this distance is less than the tree radius, line-of-sight is blocked

The simulation would repeat the above steps many (n) times, incrementing a counter (p) by 1 every time you could see your friend. The final result would simply be (p/n)*100%

I imagine with only one tree the percent chance would be very high. But what about many trees?

Screen Shot 2015-03-12 at 9.20.19 AM

That’s only 3 possible examples (from a pool of infinity) of five trees (well, six on the left!). You can see how much more complex the problem seems to become.

Interesting though, the simulation wouldn’t change much. The only difference would be to step 4 above, which would become:
4) Randomly populate the field with trees, saving their positions in an array

And then step 5 would be repeated for every tree. You wouldn’t have to test every single tree against line-of-sight for each AB vector, you could just stop when one blocked the view.

With this modified algorithm, I’d save (into my output file) the following:
1) Position of you (A)
2) Position of friend (B)
3) Size of field
4) # of trees
5) % chance of seeing friend (output of simulation)

Tests would have to be run to find out how many times the simulation needed to be ran. One thing I learned writing my simulation for my PhD was how few runs were actually necessary. My code would have happily ran all day long simulating billions of photos (each of which required hundreds of calculations) but in the end I stopped at only 1000. I found that the variability of the results for photon counts above 1000 was essentially 0, so there was no need to run more. It would be interesting to do the above coding and plot the results vs ‘maps’ ran and see where the plot gets flat. I bet it’s lower than we’d expect.

Once the basic simulation was in place, modifications I would add include:
– Variable tree size. The wood density would decide the total cross-sectional area of trees, and you could rather easily vary the radius per tree and keep track of total area so as not to exceed the desired density
– Foliage. Trees (bushes) could have a ‘transmission ratio’, possibly linked to a secondary radius (to discriminate between trunk and leaves). So line of sight could be half-blocked for instance if you were viewing your friend through leaves (as opposed to blocked by a trunk)
– Variable field size. The field is nothing more than a construct to give some constraint to the problem. It would be trivial to instead solve the following: You and your friend stand in a forest full of trees. What is the percent chance you can see your friend?

I strongly suspect the results would show a strong proportionality between the magnitude of AB, the wood density and the chance of seeing your friend, and it’s likely an equation could be fitted to allow for a general solution.ย  It’s tempting to suppose the trivial result would simply equal wood density (ie 50% trees = 50% chance), but my gut tells me it isn’t that simple.

denseforest

One interesting consideration is the dimension of the field, and how it may affect results. I have mostly ignored it here, but it may be worth considering. Consider the following examples:

Screen Shot 2015-03-12 at 9.41.13 AM

Each permutation has 6 trees, but the first two have very narrow fields, both of which will lead to very low chances to see your friend (for random A, B positions). It’s true that the ‘wood density’ varies strongly between the first two the one on the right, and I wonder if that will be enough to correlate the results. In other words, can the exact field dimensions actually be ignored?

wood2

So lets return to the general problem, and what has caused me to think about all this: How far can you see in the woods?

It’s a much more interesting problem to imagine, but I think I may save it for another postย  ๐Ÿ™‚

About that clever technique: It occurs to me a completely different way of solving this would be to do it graphically and exploit hardware graphics techniques. For instance, make the trees sprites and draw a vector between A and B and see if there is a collision with a tree. Do this enough times and save the results. The resolution (and I don’t mean computer screen resolution) would be necessarilly less, but maybe this technique – which saves a lot of coding and vector algrebra calculations – could work?

Elektronik Muzik

Sunday, March 8th, 2015

Between Christmas and my birthday, I obtained several unusual musical instruments. Obviously it was time to put my talents to use and create music! Therefore I announce the formation of my band ‘The Ultra Man’, and the release of my first single ‘Journey to Albion’. In this entry you’ll witness the creation of this soon-to-be-chart-topping hit.

The first instrument is the drum machine, otherwise known as the ‘simple buzzer circuit’ made using components in the ‘littlebits’ circuit kit JBF got me for Christmas. This is nothing more than a 9V battery connected to a pulse generator (to vary the speed of the beep) and a buzzer. Not a traditional drum machine perhaps, but The Ultra Man is no traditional band:

The electronic bass is achieved via the Otamatone device. This is about as unusual as instruments get these days, and creates sound via a pressure pad and an adjustable echo-chamber (opening the mouth of the device changes the pitch). Here’s the mysterious Ultra Man playing it:

You can see the song coming together can’t you?

The final piece in the puzzle is the Stylaphone. This gift-from-god is like a chiptune-in-a-box, and (once again) uses electronic wizardry to create astounding sounds from the future. The stylus completes a circuit when touched to the metal keys, and as you can see here the results are nothing less than magical:

So what happens when all three instruments used simultaneously to create a song? Well readers, this happens:

Even if I do say so myself, that’s pretty special ๐Ÿ™‚

Exosuit

Sunday, February 8th, 2015

Bernard got me this for Christmas:

IMG_6113.JPG

It’s a ‘designer series’ Lego kit, which means it was designed by a fan and made by Lego after it won an Internet vote. I’d never heard of it, so it was quite a surprise. Look at the design!

IMG_6114.JPG

Lots of small pieces boded well for complexity, and the manual is very professional. Everything about this ‘amateur’ kit suggests the opposite!

That said, the first step of the instructions is the easiest step I’ve ever seen in a kit:

IMG_6119.JPG

Assembly was simple, and the final product looks amazing:

IMG_6199.JPG

It’s detailed and extremely poseable:

IMG_6198.JPG

It’s also (coincidentally?) in approximately 1:144 scale, which means it plays well with most robot kits. Here is Lego spaceman using his Exosuit to fend off a savage attack from Liger Zero:

IMG_6201.JPG

And yes, I do know Liger Zero isn’t 1:144 scale ๐Ÿ˜‰

A great kit. Thanks Santa Brother!