Baking Height Maps in Blender (since you'll ask...)

Ok. First off, there is no 'official' way to bake out height maps from Blender. It isn't a quick option in the Render properties like Normals, AO, etc. Instead there is a cheat or a hack. Bear with me...

A height map is traditionally a greyscale image from a particular projection (usually above) which represents relative distances. This can be achieved with a ramp texture:

1. Delete all current materials from the mesh and add a single new one. Set it to Shading > shadeless as per image 1.
2. Set up the camera to look directly at the model (or position your plane accordingly, if you are planning on baking the Render to a UVd surface). Set it to orthographic mode and crank the orthographic scale slider until your model fits squarely in the frame. Add a texture to the material already on your model. Choose Blend from the drop down and setup the two colors in Color > Ramp. Leave Mapping > Coordinates at generated (for once) but change the X Y Z dropdowns to all be the same angle (the angle you wish to project from). Per image 2.
3. Render, correcting the ramp colors accordingly if you find the closer areas to be darker than the distances... See image 3.

A Fancy material setup

I don't pretend to be an expert here, but these are some discoveries I made from experiments using the existing UDK material nodes (as opposed to writing my own shader, which most topics online seem to be related to). 

This particular material for a sci-fi 'virtual' fabric consists of an animated glowing golden pattern which oscillates with another pattern of green scanlines (like a glitch in the construct). 

Things to take notice of here:
- I'm using an if statement to toggle between two materials at a certain interval (the time for this coming from a sine node and a divided time node). When sine is over .95 (i.e. a very small interval) the second state is allowed to flow through.
- Texture Coordinate nodes perform a number of functions here:
       - to tile the UV coordinates (it's basic function)
       - to change the UV channel (see below)
       - as a three channel graypack consisting of a vertical ramp (red), a horizontal ramp (green) and a          
       uniform black (blue). This, again, has two uses:
                 - should you need a ramp texture (more useful than you think - try doing a linear wipe without it)
                 - as a representation of UV space, the 2D ramps can be multiplied by/ added to a grayscale
                   image (here i'm using a height map frontal projection) to distort the UV, and therefore the image
                  said UVs are plugged into.
- My glowing hexagon panner (here, broken up by a cloud greypack) is plugged into the TransmissionMask and TransmissionColor channels. These are usually reserved for faking subsurface scattering (which also glows... to an extent - and I only discovered this technique through a happy accident in skin modelling), but, blown out by any value above one, the details glow in a response to any lights in the scene (much like Spec but way more powerful).

Multiple UV Channels in Blender

Despite there being no need for you to retain a second UV channel on your meshes for light baking purposes, there are certain situations which arise (principally in fancy Material setups: see above) which necessitate the need for that second layout.

While many forums (which I painstakingly Google'd) will swear that no such thing exists, I happened to stumble on this particular holy grail when researching a completely unrelated matter...

And here's the proof:

It's in the object data properties panel of your mesh. Hurrah. Simply add a new channel, select it, redo the UVs as you wish, and you're done.

Or not.

It seems that unfortunately while the Unreal Exporter (see below) will export the mesh absolutely fine, it will only retain one of the two (or more) UV channels: principally, whichever you left selected.

This is a problem.

Fortunately the solution comes from a quite unforeseen direction: The FBX Exporter. The very same FBX exporter which I had previously dismissed as being too out of date to be usable in the latest versions of UDK . Yes, it seems that my previous attempts as importing meshes through this means had been with meshes which were just too damned shoddy (and it's here that I return to that old selling point of the Unreal Exporter: debugging at export time, not import...).

Yes, long story short: Use the FBX Exporter - just be sure to polish up your mesh according to the same requirements which the Unreal Exporter upholds.

Skeletal Meshes Pipeline in Blender

Requirements:
- Must be a single mesh (Though you can combine several together before rigging)
- All Transforms must be zeroed out in Object Mode (feel free to align and resize the mesh in edit mode though)
- There must be a single root bone at the origin.
- There must be a minimum of three bones.
- All bones must be within a hierarchy (even, if only to the root - and all bones not within the hierarchy should be parented to the root)
- There must be at least one material applied. (unreal uses the material slots, but won't load the mesh with the material already applied: there's no point - it removes all of the fun of the material editor!)

The Unreal Exporter (Preferences>Add-ons> Input-Output>Unreal .PSK/.PSA) elsewhere known as ActorX is touchy: with Blender 2.63 I have experienced great difficulty in exporting a mesh due to what I can only guess as problems with excessive poles in the mesh (I'm a stickler for quad modelling, so there are a number of places where there just have to be poles in order for the mesh to flow in an agreeable way). This I  have surmised after spending an excessive amount of time cutting holes in my mesh before export to try to ascertain the root of the problem. In the end I OBJ'd the mesh to an earlier portable version of Blender (I believe it was 2.57) and found there to be no problems whatsoever exporting from there.

The principle advantage of ActorX, though, aside from the warnings which Unreal presents when uploading an older FBX export, is that all of the problems are logged at export time: you won't end up with a file which fails to load in UDK.