Jump to content
  • Advertisement
Sign in to follow this  
gchewood

Efficient lightmapping?

This topic is 2106 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm playing around with lightmaps for my fairly small demo scene. I've looked around at some of the online literature

but I can't discern whether there's an agreed upon method for storing and implementing the lightmaps.

 

I realise it'll depend on the game in question as to whether you can spare texture memory or processing time but I'm just wondering if there's one approach that's considered superior. The way I see it, the main possibilities are:

 

 

1) Bake the lightmaps into the textures for each model. This means only 1 texture needs to be send to the shader but a unique texture needs to be held for each model (a lot of my models reuse textures otherwise).

 

2) Bake separate lightmaps for each model. A unique lightmap still needs to be kept for each model but you can probably get away with lower resolutions (given that the main textures are often shared between models and are more detailed). 2 textures need to be sent to the shader, but 1 can be shared between many models.

 

3) Given that lightmaps can use a second set of uv-coords (and I'm working with a fairly small scene), put all of the scenes models onto 1 huge lightmap. This'll make it a lot easier to assemble the scene and most textures will be shared quite a number of times. The main problem will be the huge amount of memory needed to get high-quality lighting.

 

Have I correctly dichotomised the problem? And which approach would you recommend.

 

Thanks a lot.

Share this post


Link to post
Share on other sites
Advertisement
I would use 2).
3) only makes sense if you're already using megatextures for your main texture, and you already have megatexture-handling inmplemented. Then you would have to match lightmaps to the main megatexture, and the easiest would be if the lightmaps are a megatexture too.

The advantage of both 2) and 3) is that you can blend dynamic lights into the static lightmaps, to make light spots, like the light from a flashlight lighting a portion of a wall that is normally in shadow - you can't do that if your lightmaps are baked into the texture. You could make the light affect the baked diffuse color instead of the lightmap, but the effect would be different. If you don't use dynamic lights, then you won't need to do this. In that case, 1) is good too.

Share this post


Link to post
Share on other sites

Thanks tonemgub,

 

Yeah I'd just realised that problem with 1) when I was thinking about what would happen when dynamic shadows mixed with baked shadows. I guess the lighting needs to be stored separately for this reason.

 

Why does 3) only make sense if I'm using a megatexture already? They wouldn't match the uvs anyway because a lot of the regular texture-mapping uses overlapping and repetition (so can't be used for lighting).

Share this post


Link to post
Share on other sites

Because of the often lower resolution of light maps, it's also possible to bake them as (rgb) vertex map data. That way you don't need uvs (if you don't use them otherwise) or assign per-face texture space.

Share this post


Link to post
Share on other sites

You can store RGB data as additional vertex data, just like uvs and weight maps.

 

I don't know what modeller you're using, but here's a video of how it's done in Modo: http://vimeo.com/24408692

Edited by eppo

Share this post


Link to post
Share on other sites

Aha, yeah I get it. I'm guessing that only works for fairly high-poly models though!?

 

And I use 3ds max btw.

Edited by gchewood

Share this post


Link to post
Share on other sites

http://wiki.polycount.com/AmbientOcclusionVertexColor

 


Yeah I'd just realised that problem with 1) when I was thinking about what would happen when dynamic shadows mixed with baked shadows. I guess the lighting needs to be stored separately for this reason.

 

The baked lighting is basically a light of its own, so it can be additively blended together with other/dynamic (shadow casting) lights.

Share this post


Link to post
Share on other sites

3) only makes sense if you're already using megatextures for your main texture, and you already have megatexture-handling inmplemented. 

 

Think I just got what you meant actually. You mean that instead of needing lots of separate models with unique uv coords, I'd need the system in place to transform one set of unique uvs into the various places on the lightmap? At the moment I'm looking at a megatexture/texture atlas (I assume those are synonyms?). So that'l probably be what I go for! 

Edited by gchewood

Share this post


Link to post
Share on other sites

The issue with having separate lightmaps for each mesh is that you'll waste a lot of texture space. No UV mapping for a given mesh is ever going to be completely efficient, and any unused space will result in wasted memory. However if you pack lots of meshes into the same texture, you have the opportunity to tightly pack together the various charts and reduce the amount of wasted space. Also you have to keep in mind any hardware limitations regarding power-of-2 textures, since that will also factor into your memory consumption.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!