That was my original idea when cubemaps came to Blitz3D... do a pre-calced 3 array of points inside the gamelevel, and the render tiny cubemaps from each of those points. Then you would just either choose or interpolate a cubemap that's most approriate to the moving, dynamic object inside the gamelevel... that way the lighting should match the lightmapped level static lighting pretty goog.
I was developing this normalmapping stuff for a Final Fantasy Tactics type turn-basied strategy game I've been working on...basicly only one character moves at a time, and what I was thinking of doing was precalculateing the normals cubemap and the colored lighting cubemap for each location on the map that a character can occupy...load this into a bank, and generate the cubemaps for each of the characters...then as the character moves from one location to next do a little "morph" on the characters cubemaps to change them to the maps of the location they are moveing to.
Problem is that invoves a whole lot of cubemaps, two for each character, and there could be two dozen or more characters on a map...video memory could handle it, but I'm not sure about surface counts...not to mention that larger maps would require a whole lot more bank memory just to store all the precalculated maps...so instead I'm working on a system that subdivdes the maps into zones or sectors...sort of how the Duke3D build engine had sectors, but here each has thier own set of cubemaps...every chacter in the same sector uses the same cubemaps...and when characters move to locations withing the same sector, the same cubemaps are used...but if they move into a different sector, a new temporary pair of cubemaps would be created- copies of the maps of the starting sector..then as the character moves, the temp maps are morphed to match those of the sector they are moveing into...and once they get to thier destination the temp maps are removed and the maps for that sector are assigned to the character...in this way I can change the lighting in a sector at runtime, effecting all the characters within it...without haveing to ajust individual cubemaps for each character...plus it saves memory as a 100 by 100 map before would have needed about half a megabyte to store 24 bytes for a normals cubemap and 24 bytes for a colored lighting cubemap for each location...instead if the map is subdivided into 256 zones or sectors, thats only 12k for all the maps to be stored in a bank...
still surface counts can become a problem :P