Lighting Frustrations

The lighting in UDK has been somewhat frustrating for me. The fundamental problem is that UDK has been set up expecting to use precomputed lighting. This works fine for indoor areas, but I need realtime light to allow me to do a full day/night cycle and as a result, I'm working against the grain of what UDK knows how to do.

My various frustrations include:

• Although UDK can perform deferred shading in directX 11 mode, I do not have access to the normal, diffuse or specular buffers to make any adjustments nor do I have the ability to modify the cascaded shadow map before it is compared with the scene.
• The results of the cascaded shadowing are not blurred or dithered and because of the above, I cannot make these adjustments myself. So the shadows are either pixellated or blurry, never how you'd want.
• When rotating the light, updates to the cascaded shadow map appear to happen only when the light has rotated by more than (complete guess here) 0.1 degrees. Although this sounds like very little, it results in the jittery movement of shadows
• Due to the way cascaded shadow maps work, their results as the light is rotated vary quite considerably, leaving jerkily updating shadows
• Due to the way cascaded shadow maps work, I have to comprimise between undesirable self-shadowing across oblique angles (causing shadow striping), or "floating shadows" caused by an offset.
• I am unable to use custom lighting on terrain to hide the undesirable self-shadowing at oblique angles.
• I have been unable to find a way to interface with the baked lighting in any way
• In the dumbest bug to date, when a light is rotated very slowly, if you're looking horizontally, it doesn't move. look up ot down to get it to carry on moving. just... what?!

All of the above appear to be pretty much unavoidable, and have to be hidden away and mitigated as best as possible. A couple of features which I may be able to implement but are not currently implemented in UDK are:

• The current post-processing chain built into UDK is very well-featured, and probably well-optimised, but is costing 5-10ms per frame... this is cutting frame rate by about 30%. I may have to live with that, but if I have time to implement my own post-processing solution I may be able to cut some of the features I don't need for a fairly substantial framerate boost.
• UDK's out-of-the-box bloom does not feature bokeh (shaped) bloom (it does feature bokeh depth of field but that's not really what I want). This would be probably the hardest thing for me to implement, but I'd really like to give it a go if I have time at the end. It looks super-nice when water catches flecks of light and you get a bokeh effect on the highlights.
• Post-processing parameters are not kismet or matinee-accessible, but can be adjusted in UnrealScript.

Don't get me wrong... I love UDK. With it, I can do all of the effects I want, and I'm hoping it'll pay dividends when I come to that part... But its frustrating when I see somebody create a new level in CryEngine and within minutes has a day/night cycle with none of the problems above. and it has bokeh bloom. and a better frame rate. And such pretty water...

Really wish I was using Unreal Engine 4 to do this stuff. :(