Can I have Instructions?

Whenever anybody asks me this question, the answer is generally 'no'. I'd rather spend my time building something new than behind my computer slaving away using some CAD-software.



However, sometimes it can be time well-spent. As you may have read, I've been designing aircraft for Lego Monster's Project Intrepid. What complicates the collaboration a bit is that currently we don't live in the same country any more, which means that even if I had the time to build dozens of aircraft models in a few months time, they'd be nowhere near their aircraft carrier. That makes making instructions worthwhile. The two aircraft types of which we intend to have the largest numbers are the Vought F4U Corsair and the Curtiss SB2C Helldiver

LDD or MLCad/LDraw
Two different types of CAD-software are commonly used by LEGO-fans. LEGO's own LEGO Digital Designer and LDraw using Mike's LEGO CAD (written by Michael Lachmann) adding a graphical user interface (GUI) for editing the files. LDraw contains a library of parts (in .dat-files) and uses its own file format (.ldr files) to determine where the parts are placed, how they are oriented and what colour they have in your model. The LDraw parts library is maintained by volunteers and includes a truly staggering amount of different parts, both old and new. A separate program, called LPub reads the .ldr files and turns them into instructions. LDD can also produce instructions, but its part library is far more limited even though with the release of the LEGO Universe game many new parts and colours have been added.
Both of my aircraft models use some rare (transparent clear tiles) and old parts (old-style finger hinges, for instance) that I suspect aren't available in LDD. Furthermore, when I dabbled with digital LEGO a few years ago I used MLCad for a bit, so I had some familiarity with the program. Below you see a screen-shot of MLCad displaying my Helldiver model.





Much has been written about LDraw and it is not my intention to write an extensive 'how-to' on making instructions. Instead I will share a few things that I ran into and the way I solved them on my way to making instructions.

Hacking LDraw files.
Making the instructions involves two main steps: making a digital version of the model in MLCad and then making images of each build step to go into the final instructions using LPub. MLCad offers the option of adding step commands between adding parts. Obviously, when making instructions for your model you need to think about how to work through it, layer by layer, for instance, in order to make sure that every part you add in each new step is supported by an existing structure and is visible in the instruction images. The STEP-commands are read by LPub when you start making the instruction booklet. Perhaps I am doing something wrong, but this doesn't seem to work all that well. No matter where I add the steps in MLcad (placing a STEP command in the LDraw file), when more parts are added later they can end up pretty much anywhere in the file. This makes a complete hash of things, with parts floating in mid-air because their supporting construction is to be built at a later step. Not good.



However, LDraw's files are set up such that you can actually read them. The file is a list of the various commands and the colour, coordinates and orientation of each part. LPub reads this from top to bottom when making the instructions. By swapping the order and adding step-commands yourself in a text editor, you can easily fix things. It takes some getting used to, but I found that once I got the hang of it, I could do it very quickly, by switching between the text editor in which I had the file open, MLCad to identify the parts, and LPub to show me how my actions affected the instructions. MLCad also allows you to add commands to rotate your model such that the part you're working on will be visible in the instructions, using a handy pop-up window that gives you a preview. These too can be manually adjusted in the file to optimise the result.
Further advantages of having human-readable files is that if you are having a bit of trouble lining two parts up in the graphical user interface, you can simply change the coordinates in the file. It also allows you to change colours quickly and I also manually edited the files to quickly mirror structures. For instance, if I have a right wing and want the matching left one, as a first step I would invert the sign of the appropriate coordinates in the file. You can see an example for the horizontal tailplanes of my Helldiver, with an image and the corresponding LDraw code underneath. The 3rd, 4th and 5th column are the x,y,z coordinates of the part (obviously the location of the origin of the part relative to the shape of the part is set in the .dat file for the individual part). If you compare the 5th column in both files, you'll see that I have inverted the sign (of the z-coordinate), thereby mirroring the part locations. Since the tailplane uses a few left/right wing plates, they had to be replaced by their mirror images (54383.dat and 54384.dat are the 3x6 wing plates). Some parts will need to be rotated (which can be easily done using the GUI) or replaced by their mirror images, which is simply a matter of changing a number. It might seem complicated, but it's much faster than 'building' the left wing from scratch, especially if you then have to manually edit that file again to place the step commands in their proper locations. Manually hacking the file, this one took me about five minutes.

Using sub-models
One important tip I can give you is to split your model into smaller sub-models.

Unless you have a massive screen to work on (I don't, I use a laptop), large models will be very small on your screen and will be awkward to work with. Using separate sub-assemblies also means you can use separate small .ldr files which are far easier to manage (and to edit) than big ones. When you finally reach the step of making the instructions, the sub-assemblies can also be done separately, much like LEGO themselves do for their instructions. Here is a sample page of my Helldiver showing one of the tail-planes as a sub-assembly.

Using LPub to make the actual instruction booklet
Like MLCad, LPub also adds its own commands to the .ldr files of your model. This can be very handy, because you manually edit things yourself. Back before LPub4 came out this was the preferred way of doing things! Fortunately, in LPub4 you can edit things graphically. However, if you mess up or LPub crashes -which it does occasionally- you may end up with files that you can't run any more. So, here's a top tip: make a backup of all the .ldr files of your model in a separate folder/directory before you start serious work in LPub.

When you first run an .ldr file of your complete model through LPub, every single step including all the steps taken in sub-models get their own page. For my Corsair this lead to 159 pages and for the Helldiver the number was a whopping 207. Perhaps this works if you build with your computer handy, but if you want a print-out it obviously isn't practical. Lpub allows you to group multiple steps on the same page and even in multiple columns. You can put sub-assemblies in a separate little box (a 'call-out', as illustrated in my sample page). All of this makes the instructions a lot more compact, but also much easier to work with because it is easier to keep track of what sub-assembly you are building at any given time. Some people use LPub to export images and then use some other desktop publishing package to turn the whole thing into a booklet. Since I am making these primarily for private use, I felt sticking to LPub would be good enough and I am happy with the end result. LPub also allows you to add a bill of parts (a list of every part use in the model, with a picture), although with more than 600 parts in both of these models, the resulting picture becomes too big for a page. Fortunately you can scale the size of the part images LPub uses to make the thing smaller. I also added a front cover (an image file I made using a different program) to make the whole thing look more like a little booklet. Making the booklet for the Helldiver took about 6 hours, but I learned a lot in the process. After this experience, I turned to the Corsair and turned its instructions into a reasonably neat 27 page booklet in less than two hours.

Sharing the instructions
I only made these instructions so that Lego Monster and I can build multiple copies. However, I do feel that if I have them anyway, it would be nice to offer other people the opportunity to build the models as well. I am not doing this for a profit. If you are interested in your own free copy of either the Helldiver or the Corsair, you can download the .pdfs by clicking the images below (they should take you to mediafire.com, a file sharing website). A word of warning: these are not simple models and they require fairly large numbers of parts that aren't readily available in large numbers.



In the last few years I've heard of a few cases where people took the trouble of making instructions, only to have other people start selling them claiming that 'you can't steal what is free'. In case there are misunderstandings about this, I'm releasing my instructions with a Creative Commons License Attribution-NonCommercial-NoDerives. In other words, you can distribute them freely, but they should be attributed to me, and they cannot be used for commercial purposes or modified.

Happy building!

Weathering

This morning Bruno Vaiano asked a question in the flickr military group that got me interested. Real military vehicles often have a weathered or somewhat dirty look, certainly the all white vehicles often used by UN units, and Bruno asked about ways to recreate this effect in LEGO.

Short of using dirty bricks or using paint, I felt this is something hard to do using just LEGO bricks. The only weathering that I've done involved my F-14A Tomcat, where the two colours I used lie close together (blueish grey and old grey) and the effect is so subtle you'll be hard pressed to see it in a picture.


John Lamarck answered with an interesting method that does involve making your bricks dirty. He burns the end of a cork using a candle (an excellent excuse to open a bottle of wine) and rubs the cork onto his LEGO leaving a fine layer of soot behind on the bricks. According to him it can be removed using a tooth brush and some water.

I'll take his word for it, but the result looks pretty good. The aircraft itself is a model of a Junkers EF-112, an aircraft designed during WW-II that never flew. It was John's entry for this years flickr military build contest and ended up winning him a well-deserved third prize in the 'Alternative Reality WW-II" category.
Try this method at your own peril. I will not be held responsible for you burning the house down playing with flames and corks after drinking a bottle of wine!

Building helicopters

About two weeks ago I started writing a new blog post about the results of this year's flickr LEGO military build contest, before getting bogged down by work and not finishing it. For those of you who haven't seen the results, they were announced early in June. I may revisit it in the future, but when thinking about this blog this morning I decided I was more interested in writing about a very different subject.

A lot of people build fictional helicopters out of LEGO. Many of them are really nice, but browsing flickr and being a member of the flickr military group, I've also seen lots that in my opinion could be a lot more realistic if the builders had a somewhat better understanding of how real-world helicopters work.
I wrote a somewhat rambling post about this on flickr about a year ago, but this time around I'll illustrate the points I was trying to make with pictures of LEGO helicopter models, both of fictional and of real-world helicopters. Here are a few examples of helicopters that prompted my post.

Ascension class Heavy Lift Helicopter by BrickArt!san

Helicopter V3 WIP by Cpt. Decius

RAMM Spatzenfalke Support Helicopter by ѕроок

Alpha One by ~Tac~

Wyvern Attack VTOL by [Carter]

I am not singling out particular builders because I want to be nasty to them. I could have chosen a whole range of other pictures from flickr. The reason why I chose these is not because they are bad models, because they are not. They have a lot going for them: the builders have used nice techniques and have spent a lot of time fiddling with the details. The Wyvern even was the 2nd prize winner in the 'stealth' category of this year's build contest. However, each and every one of these models has a number of features that makes them look decidedly odd to me and as such serve to illustrate my point. Once you've read this post, my suggestion is to take another look at these. Hopefully you'll see what I mean.

I'll give you a sample of the sort of things I'll be focusing on, using a picture of my own OH-58D Kiowa Warrior as an example.
It is not a fictional helicopter, unlike the ones I've shown so far, but it shows a number of features of a real helicopter.

• Configuration: like most helicopters it has a single main rotor. This means that it needs a tail rotor


• Details: the Kiowa is covered with a lot of lumps and bumps, but it has many relatively smooth surfaces too and the overall shape is aerodynamic


• Engines: the Kiowa is powered by a single gas-turbine engine, with an air intake in the front and an exhaust on top


• Proportions: the tail rotor sits at the end of a fairly long tail boom. The tail boom is almost half the length of the overall length of the fuselage

I'll show more examples as I address each of these points in more detail.

Helicopter configurations
Most helicopters have a single rotor. In the picture below I've drawn a top view of a typical helicopter. In my drawing the rotor blades turn in a clockwise direction.

One or more engines turn the rotor blades relative to the fuselage. Physics (specifically conservation of angular momentum) tells you that the torque required to rotate the blades must be balanced. If it isn't, the fuselage of the helicopter would start to rotate in the opposite direction (counter-clockwise in my drawing). This is the reason why most single-rotor helicopters have a tail rotor. It generates a sideways force on the tail of the helicopter that balances the torque, keeping the tail pointing in the same direction. In my drawing this force points to the left. The internet is full of videos of helicopters crashing due to tail rotor failure, such as this one of a Sea King crashing aboard a US Navy Destroyer in 2002.

As far as I know, everybody aboard survived, but it wasn't pretty. Show me a single-rotor helicopter without a tail rotor and this is the sort of image that pops into my mind.

Some real-world helicopters have a system called NOTAR in which the sideways force is generated by blowing air through a specially shaped tailboom. Other helicopters use a so-called Fenestron (or fan tail), which is basically a tail rotor built into a duct in the tail. A nice example of a LEGO helicopter with a Fenestron is Aleksander Stein's SH-78.


There are a few alternative arrangements that involve one set of rotors turning in clockwise direction and a second set of rotors turning counter-clockwise.

• Coaxial rotors (one on top of the other), once again illustrated by a fictional model by Aleksander Stein:
  


• Inter-meshing rotors, illustrated by Daniel Zayec's Fl-282 (the winner of the helicopter model category in the contest)
  .
  A fictional example was built by Dan Rubin.
  
  


• Tandem Rotors. An example of a model of a real-world helicopter with tandem rotors is my own CH-47D Chinook, with one set turning clock-wise and a another set turning counter-clockwise.
  
  An alternative configuration, with the rotors side-by-side is Aleksander Stein's Fa-223 (the 2nd prize winner in the helicopter category of this year's competition).
  

The bottom line is that if you have a set of rotors turning, you'll need some way of countering the torque this generates. If you build a single-rotor helicopter, you'll need to think of a system to counter the torque. If you want to stick close to the real world, that means either a tail rotor, a Fenestron or a NOTAR system (which requires a specially shaped tail).

Details
The next item is more subjective than the previous one. Builders of space models generally prefer for their designs to have greebles or greebling. I have the impression that people who are very much into space building cannot resist adding greebles to machines where they are a bit inappropriate. While reducing drag isn't as important for helicopters as it is for aircraft, helicopters are supposed to move through air and some aerodynamic shaping makes sense. When building a helicopter you need to carefully balance your desire to add interesting details and the overall appearance of the helicopter as a vehicle designed to move through air. Beyond a certain point, adding more bits in an attempt to make things look interesting only makes them look messy. In that light, practice restraint when it comes to adding transparent bits representing lights in different colours, something I call random lights. Real helicopters don't have all that many lights and certainly none on the ends of the rotor blades!

Engines
Most modern helicopters are powered by gas turbine engines. These are essentially the same as a jet engine, but rather than delivering thrust directly they are used to rotate a shaft. It is connected to a gear box which drives the main and tail rotors. Gas turbines require a lot of air to run and produce a lot of hot exhaust gases. So, helicopters powered by gas turbines typically have an air intake and a big exhaust pipe. Many helicopters have more than one turbine, in which case they will usually also have more than one intake and exhaust. Magnus Lauglo's Pegasus is one example of a fictional helicopter which clearly shows the location of the gas turbine (above the passenger compartment) with an intake in front and exhaust at the back.
#
As always, there are exceptions. Gas turbines are susceptible to damage from ingesting sand, so many helicopters have their intakes covered by particle filters. In that case, rather than a big round hole for the intake, there tends to be a cylindrical device sticking out with vents all around it, called a particle separator. It's clearly visible on the engine pod on my MH-53 model (shown here with its tail and rotor blades folded).

The picture of my Chinook clearly shows one of the helicopter's two engines mounted in a pod next to the aft rotor pylon. The exhaust pipe at the back is clearly visible, but the intake at the front is covered by vents; another example of a particle seperator.
To reduce the Infra-Red emissions of battlefield helicopters their exhausts are sometimes covered by large boxes that are designed to mix the hot exhaust gasses with cool ambient air. In that case, rather than a big pipe sticking out somewhere, there will usually be a big box with vents. The picture of Aleksander Stein's SH-78 shows such a box. Some light helicopters and old helicopters are powered by piston engines, which require less gas flow. they tend to have air intakes and exhausts that are far less visible on the outside. Examples are the Fa-223 and Fl-282 I've already shown. At the time when those were designed and flown, gas turbine engines were still in their infancy.

Proportions
This item is closely related to the section about the configuration. On a conventional, single rotor helicopter, the tail tends to be fairly long. The reason for this is quite simple. Since the strength of the torque generated by the tail rotor is a product of the distance to the centre of rotation of the helicopter and the sideways force generated by the tail rotor, the longer the tail is, the less force it needs to generate to counter the torque generated at the main rotor. Only helicopters with coaxial rotors or with inter-meshing rotors tend to have a short tail. The rotor is the main source of the lift that allows the helicopter to fly will sit close to the helicopter's centre of gravity. On a tandem helicopter, the centre of gravity will sit roughly in the middle between the two rotors. A consequence of this is that, typically, a single-rotor helicopter will have a tail boom that is about as long as the cabin (although it's not always easy to determine where the cabin ends and the tail begins) and the part of the fuselage behind the rotor mast is a lot longer than the part in front of it. Check out my Lynx, for instance:

Anything else looks odd!

Putting it all together
You might be tempted to think that all these 'rules' are unnecessarily restrictive, but I am convinced that if you keep what I wrote in mind, the end result of building a helicopter will end up looking more convincing -irrespective of whether it is science fiction or supposed to be near-future/ contemporary military. Of course anybody who decides to build a helicopter is free to do this in whatever way he or she pleases. As usual with posts like this I am merely expressing my view, hoping that some of you may be able to use my advice to your advantage.

Building a fictional helicopter in some respects is a different game than building a model of a real helicopter. I normally do the latter and don't really have to think about where the rotor goes and where to put the exhaust; the real helicopter's designers have done all of that for me and I can simply stick to planning like I do for aircraft. However, having some sort of idea in mind of what your helicopter will look like before you start building might help you avoid some of the issues I described above.

I'll leave you with a picture of one of the few fictional helicopters that I myself built and which formed the basis for Aleksander Stein's SH-78, the HH-78 Gannet, both subject of an earlier post on this blog. I applied all of the things I discussed when building it, leading some people to question whether it is in fact a model of a real helicopter.

Happy building!