here's my answer to some of your questions
I believe so.For example, imagine I had a 1600 square foot home I wanted to lightmap, with three stories. Would it be able to handle that sort of thing?
It's been a while since I took a look at the OgreFSRad and I believe there is a point light converter in there. However FSRad's strongest feature is using geometry as light and I don't remember if OgreFSRad supports this.As far as I know, OgreFSRad only supported point lights, and possibly mesh lights (geometry that acts as a light - probably by sampling points across the surface of the mesh?)
FSRad may slice your data to fit an octree data structure, but this can be turned off. Furthermore because FSRad can generate multiple lightmaps for one piece of geometry your original geometry may be return separated. Besides that all sets of connected triangles will be clipped against the lightmap size to make sure the fit in a lightmap. So what you will get back are new UV coordinates and possibly new vertices.when you send geometry to OgreFSRad to lightmap, do you get back different geometry (different number of vertices, new UV coordinates obviously for the lightmaps?)
FSRad will store your original UV's and give them back next to the generated lightmap UV's, but remember that only one set of original UV's can be stored.If it gives you back geometry, does it contain the original UVs and a second set of UVs so you can use the geometry that came back from OgreFSRad in place of your original geometry?
Unfortunately the latter is the case. You define the number of pixels per meter and FSRad will make sure it generates enough lightmaps to fit all geometry. The lightmap packing could be more optimized, because for instance triangles with large aspect ratios will often end up in a new lightmap.Can you give it a lightmap texture size and it generate all lightmaps within that limit, or does it simply start creating lightmap textures on its own and spreading them out over multiple textures without you having a say in it?
One of the strong features of Gile[s] is that it creates lightmaps attached to materials. With FSRad you may end up with a lot of extra stateswaps, because of the distribution over multiple lightmaps. Besides that FSRad does not support transparency/translucency like Gile[s] does. It does however in my opinion calculate a more physically plausible result.