I've been put in charge of doing some R&D for lighting solutions for our current project. Most of the lighting we've done in the past has been handled by vertex lighting and it has served us pretty well and achieved the results we've wanted.
With the early versions of our current project, we've noticed a lot of our environments were lacking crisp shadows which gave the illusion of floating geometry.
After a few tests, the only way we would get these results were by sub-dividing our geometry (going from 1000tris to 20,000tris for a ground plane).
My question to you is, what is the common practice with using Lightmaps?

We are developing this for the Wii and the engine we are using doesn't support multitexturing (applying two or more textures to a single bit of mesh in a single pass: Spec, Bump, Alpha, Normal, etc), but we are looking at implementing this so we can explore the Lightmap avenue.

Now... Does the mesh need to have a unique unwrap for this to work properly (no overlapping UVs)?
Do the UVs have to be contained within the 0 to 1 UV co-ordinates?
Any information you can give me on this would be great. I've done a little research already and found out the basics of how it works. Figured I'd ask here as well for those of you that have worked with this medium before.
Thanks.

-caseyjones

While I'm sure a number of people on this forum can (and should) give their advice and experience, since this is for your studio/game, let me give some better advice than what our ideas of implementation may give. Level lightmapping is much better handled programmaticly and procedurally when building levels. Every surface needs its own lightmap space and instances of the same object need their own unique space. It is possible to set this up in advance, such as creating your level in max, unwrapping all the objects with a second UV channel, and baking- obviously there are limitations but this is what I would do for a one-shot deal such as a tech demo. However this isn't a tech demo (AFAIK) so whatever a good solution you find, it will be not be handled by the artists. It will be handled by the engine (at runtime or pre-rendered/calculated. Whatever the implementation of a usable and flexible system will be by programmers.

My suggestion is, find a programmer who has done this before- if there are none at your studio, then ask around, as this has been a common thing. However there just isn't much for an artist to do on this aspect, since it should be independent of the content pipeline for the most part. The programmer will be doing most of the work but it is always helpful to have an artist watching, since this is, after all, about graphics.

But to answer your question directly: most lightmapping solutions I know (either in-engine or software plugins I don't know about (Maya2008 I think has one?)) handle lightmaps the same way: create a second UV channel for all geo and give all geo unique UV's in that uv space. Then render the lightmap. Multitexturing is required, no other way to do it I can think of if you're not doing vertex-baked lighting.

If you want to do more research, the best bet it, look around at other engines that have good lightmapping solutions and look for papers (here, I'm sure, forum members can come through with papers they've found or read), but also look at engines that don't have great lightmapping, for ideas, and also lightmapping plugins/baking apps.

Thanks for the reply, Professor420. It confirmed a lot of the suspicions I had and it has definitely given me a huge starting point.
I'm working closely with our lead programmer to get an optimal lighting solution and he more than confident he'll be able to get this to work in our engine. His concerns were more to do with the increased texture counts and the high resolution textures required for an accurate lightmap.

I'll post updates as I get them.

-caseyjones

Something that came to mind is, suggest to him to use a unique lightmap in each channel of a texture, would save space if you are dealing with RGB or RGBA maps. Lightmapping's been around for a long while, so I'm sure you'll be able to overcome whatever limitations and get it working even on a Wii [img]/images/graemlins/smile.gif[/img] Though my knowledge doesn't go to before this console generation so I can't give any real specifics but there are others here and elsewhere that could.

am I wrong, or would that mean you're stuck with greyscale lighting? if you want coloured effects you'd need the full range of channels right

By the way... as this also applies to creating models which can be self shadowed:
Am I guessing right that having a second UV map results in a duplication of vertixes and thus greatly increases the transform costs (as with splits in the uv map and so on... explained in the "why poly optimisation isn't always king" sticky).
And thus it would be better in most cases to have the first uv-map made in a way that would support a lightmap also (e.g. no overlapping/mirrored uv-parts)?

Thanks for the suggestion, Professor420. It was something we did think about, possibly storing some of the lightmap data in the alpha channel of our texture to conserve space. But as rooster pointed out, it would only give us a greyscale colour spectrum. We need a coloured lightmap, so we'll have to use the full RGB channels for the single lightmap.

I did however have some success while messing around at work and was able to get a coloured lightmap.
My procedure:
1. I first built a flat plane and cube that sat in the middle. I unwrapped them to accomodate a tiling texture.
2. I created a second UV channel and made a new unwrap so I wouldn't have any overlapping UVs.
3. I then threw in a single spotlight and applied colour to both the light (peach) and the shadow (dark purple).
4. Switched to Mental Ray renderer and set up my bake to texture settings using only light, and fiddled with some of the settings. Once that was done, I ran the bake and ended up with a coloured lightmap.
5. Created a new Lambert material and assigned a tiling texture to the Colour channel and then assigned the lightmap texture to the ambient channel.
6. Using the relationship editor (UV-Linking > UV Centric), I connected the first UV channel to the Colour channel from the Lambert material, and the second UV channel to the Ambient channel (this probably made no sense - needs screenshots).
7. In the viewport it only looks like there is only the Colour channel texture displaying. One you render the scene, the Ambient channel acts as an additive colour overlay. Giving me the exact result I was after.

My next step is to get this to display realtime in the viewport, so I can get more of an idea of how it all will look. If anyone has any suggestions on how to accomplish this, please let me know.
Like I mentioned in the earlier post, I'm using Maya 8.0. Most of our experienced Maya guys had already left for the day before I had a chance to ask them. If I get a solution, I'll be sure to post it here and will eventually write up a tute with my findings.

-caseyjones

EDIT:
JKMakowka: I don't think it doubles up on the vert count, but it does add to the processing having a second UV channel. So there will be a hit on the performance.
Though, by transforms, I'm assuming you mean animated mesh? Well, the lightmaps will only be used on the environment mesh only, we had another lighting solution in place for the characters. Plus the characters will have an ambient occlusion pass baked into the texture itself and then will be dynamically tinted based on how the environment mesh is lit.
I didn't read your post because I spent too long writing up mine :P