Baking lightmap with normalmap?

It will be awesome if WED can bake lightmap using normalmap. Or maybe using texture with alpha channel as heightmap.

I don't think you want to bake lightmaps with normalmaps. Lightmaps are non-repetitive, large, and have a low resolution, while normalmaps are repetitive, small, and have a high resolution. When you want for some reason your level to be very small or look very low-res, then baking both could be a good idea.

On the second though, you're right I never realize that until you mention it . I was looking on a Unity tutorial when I see that lightmap baking with normalmap, and the example indeed only a bumpy table and a ball LoL...
Thanks for the response

Having light maps together with normal maps is actually not a dumb idea:
http://www.decew.net/OSS/References/sem_ss06_07-Independant%20Explanation.pdf

As you can see in this document, the Source engine (just like UDK) uses lightmapping information to affect the lighting situation together with normal maps. This makes a lot of sense. This way all the static lights can contribute to the normal mapped lighting. And there are no additional dynamic lights needed to influence normal maps / specularity. It even renders very fast.

This reminds me to something I already wanted to request: would it be possible to get eccess to particular radiosity bounces saved in extra lightmaps for shaders? It seems that this is needed for radiosity normalmapping as it is explained in valve´s paper about this technique.
Eventually there is no need for 20 bounces but 3 or 4 could be useful

Yes, you'd need the light bounce direction for radiosity normalmapping. This is currently not stored in the WMB file, so this information gets lost. It would make sense to store the directional components of the lightmap in a future version. I'll check if this can be done within the current format.

Yes, that will be nice. A directional baked lightmap will surely render faster than dynamic lights. Plus the model can get the light direction from static lights too(so they'll have bright part and dark part instead of having uniform brightness)

I am interested how you would solve this. Lightmaps are limited to mapped surfaces. But your character is moving in a 3d room.

I think, to do this perfectly we would need a 3d data block, like a complete volume covering your level subdivided into lots of small blocks (voxels?). Each of these blocks should save directional lighting information. So you could light your dynamic models very accurate wherever it is, even when flying through the room.
But it also needs bunch of memory.

Well it only apply if the model stand on the ground though, not working well if they flying, just as you said...

Rendering the ligth bounce information into a cubemap from the obejct´s position can be a working approximation for dynamic models. That´s how Valve does it.
A 3d data blocks would require support for volume textures which is not given for Acknex yet, sadly. In fact CryEngine3 renders lighting information into cascaded 3d data blocks in realtime for their GI solution and it seems to work well even on consols.