Lightmaps Future

Hi everyone!

-How come there are almost no post on lightmaps on this site?(I did a search) You guys don’t use them?

-“Conclusion: With the arrival of new monster graphics cards, lighting using lightmaps may become extinct.” (Source)
What?! No way… per pixel shading using shaders produces overhead and a huge load on the engine, and why calculate something real time when it can be precalculated and stored in textures?!!

What do you guys think!? :slight_smile:

Cheers!
Rod

How come there are almost no post on lightmaps on this site?
Because everything that needs to be said about them has been. Besides, it’s just a texture; how much is there to discuss?

per pixel shading using shaders produces overhead and a huge load on the engine, and why calculate something real time when it can be precalculated and stored in textures?!!
Because it can’t be precalculated and stored in textures.

Lightmaps are a hack (or, less hyperbolically, an approximation). As such, they have limitations. The most serious of which is shadowing.

Lightmaps only provide shadows for objects that were in the scene in that position when the light map was generated. If all you’re doing is rendering static terrain, that’s fine. But what happens when you want to do better? What if you want to move the terrain (open doors, destroy boxes, etc)? Or even just render something else that moves?

Well, in lightmapped engines, you don’t get shadows from those characters. You can try to approximate it, of course, but that’s about the limit of what you’re capable of doing.

Furthermore, once you use lightmaps, you’ve limited yourself to mostly static lighting. That might work when you’re indoors in some corridor-based shooter, but it has no meaning for reality when you step outside and the sun rises and sets.

Personally, I don’t think lightmaps are worthwhile in the general case. In certain limited, specific cases, perhaps. But in general, the cost of fragment programs has reached the point where actual lighting is performant. And since actual lighting allows for so much more, there’s really no point in using lightmaps.

It seems to me most people who dismiss traditional techniques are either programmers who only code one-room demos, or large companies that want to mislead their users and scare their competition.

I can’t count the number of times I have heard Epic or some other developer announce that lightmaps or some other basic technique are no longer going to be used in their new engine, and then when the engine finally ships, you still see the same old techniques. For example, it was said that Unreal Engine 3 would totally do away with BSP geometry and lightmaps, but UnrealEdit 3 is still using the same old methods.

Lightmaps are going to be around until either real-time raytracing or soft stencil shadows are possible, on the same scale of a scene you can currently render with lightmaps. The techies will keep repeating that lightmaps are extinct, while actual shipping products will continue to use them.

it’s not really a question of whether lightmaps are dead or anything, it’s just that there are better alternatives to lightmaps at the moment (ambient occlusion, shadow maps, per-pixel lighting etc.) which don’t work too well when used with lightmaps. You can’t have dynamic lighting with traditional lightmaps, so if a light in the scene is moving the illusion baked into your lightmaps is broken and the result is very noticeable.
If you can get away with lightmaps for a particular scene, then use them. They’re just another tool to be used in appropriate circumstances.
Your propensity to use out-dated and soon to be unsupported OpenGL extensions, however halo, is not clever use of a tool set. People like you will hold OpenGL back.

I think lightmaps are moving from lighting entire scenes to more detail work in those cases where either stencil or depthmap shadows are a bit overkill.
Like those little emergency lights on steps or perhaps inside advanced machinery or something like that.
I don’t think that they are going away, ever, they just get other uses.
It’s like rendering, raster rendering as we have today is fast, really fast, ray tracing on the other hand looks better, but it will always be slower than raster rendering, no matter how fast it becomes.
And because both methods can be combined and used at the same time, people will still use the faster method, but in different ways than we use it currently.

Originally posted by Korval:
[QB] Because everything that needs to be said about them has been. Besides, it’s just a texture; how much is there to discuss?

…Lightmaps creation/baking. It’s a really difficult topic and there are series of algorithms for creating the lumens maps (Gouroud, Phong, Radiosity, etc, etc) and then another algorithm for mapping then to the respective polygons (which is easier). Very few documentation can be found on the internet about this as most of the ‘lightmap tutorials’ just show you how to use multitexture functions, which is a piece of cake. It seems to me that most of this forum users just use external tools to create their lightmaps, reason why this topic is not popular.

Respect the rest of the discussion:
I concurr with zeoverlod. I think that lightmaps could be used in conjunction with dynamic lighting. And by the way, don’t you like the lightmaps generated with Radiosity algorithms?
For example, picture a forest without time cycles (e.g 12 AM):
-Lightmap the terrain without objects shadows
-Lightmap the tree meshes themselves (not their shadow)
-Use Shadowmapping (depth textures) for the shadows of all moving objects (trees move a little because of the wind and also for leaves particles that fly through the wind).

Of course that could be made all dynamic with time cycles and everything, using shaders, and blah blah… but I think that we will have to wait for several years till that is not overkill for consumer cards…

Lightmaps creation/baking
Which has nothing to do with OpenGL. That’s a question for your tool pipeline and asset creation system.

but I think that we will have to wait for several years till that is not overkill for consumer cards…
It’s not overkill for consumer cards. Consumers have had performant shader-based solutions for some time now. See any consumer hardware that runs Doom 3 just fine.

I would also point out that lightmaps will become increasingly expensive compared to fragment programs. Already the cost of a texture access has risen to more than a few opcodes. That’s only going to increase, as memory access is getting faster much slower than processing speed. As such, the cost of doing a simple NdotL (or even a more complex lighting equation) to get your lighting is actually becoming more efficient than a texture access.

Plus, if you want full HDR, lightmaps quickly become memory intensive. For colored lighting, you need a 64-bit float texture, which rules out filtering on some hardware that could otherwise do HDR.

Originally posted by Rodrix:
…Lightmaps creation/baking. It’s a really difficult topic and there are series of algorithms for creating the lumens maps (Gouroud, Phong, Radiosity, etc, etc) and then another algorithm for mapping then to the respective polygons (which is easier).

Personally i just push a button or two in maya and it does all that for me.

yes lightmaps are past there usebydate, they have been used in games from quake2 -> gears of war.
the reason theyre past there use by date, is they dont fit in with a unified lighting model, ie u must use lightmaps with something else.
not to mention there major problem is theyre only correct if nothing in the scene moves beit people or lights whatever ie no games

…sorry… what do you mean by “past there use by date”?

Originally posted by zeoverlord:
Personally i just push a button or two in maya and it does all that for me.
Really? …Could you point me to a tutorial link for creating Lightmaps in Maya? :wink:
Does it also export the text vertex coord for lightmapping?

Thanks!

I think lightmaps can be useful. If you have an outdoor scene and your sun won’t be moving, why generate a shadow map? Of course, you could generate the shadowmap when you load the map, but a pregenerated map and static texcoords seems more appropriate (and this creates other issues).

“use by date”? In my country, “expiration date”

I like the little similarities like this between britain and new zealand - it’s use-by and sell-by date here too.
I’m still waiting for my come-back off halo.

Personally i just push a button or two in maya and it does all that for me. [/QB]
I managed to create the lightmaps with MentalRay and using BatchBake.

Could you please tell me what export format do you use to read te texture vertex coordinates of your lightmaps and then apply them to your engine? This would be REALLY helpful and I would really appreciate it. I tried .ma but it doesn’t export text vert…

Thanks in advance,
Rod

Originally posted by V-man:
[QB] I think lightmaps can be useful. If you have an outdoor scene and your sun won’t be moving, why generate a shadow map?
true it works when the tree casts a shadow on the ground but what happens when a player/car goes between the tree + ground since u cant project the lightmap on that, u have to use a different method. ie it will not be unified + the shading will look different

WRT terms theres 2 commonly used (best before is usually used on packages), i learnt this on national radio (radio4 for the poms), which i listen to allday when i pick fruit, oh that reminds me another apple season is starting soon, happy happy joy joy, (flails hands in air) oh, who would be me!

useby(date) - after this date the product MUST be discarded ( ie in the trash/rubbish) as ingesting it can be harmful
best before(date) - the product can still be used /consumed after the date but isnt optimal, eg old milk might be a bit sour but its not gonna kill ya

i guess what im saying in 2007 if your still using lightmaps u should be firing your graphic engineerers, unless u have greabt PR ppl

Lightmaps aren’t going away anytime soon and most games still use them to some extent. It’s still the case that most light are static and most of the scenes are static in your typical game. Thus, lightmaps are still an excellent choice. Of course, you don’t neccesarily do it the old way where you prebaked all lighting into one map that you multipled with your base map and that was it. You probably want to use it in a more modern lighting solution with normal mapping, parallax mapping etc., so lightmaps today are probably more of a shadow mask for a single light. For static lights that’s an excellent choice since it gives you real soft shadows for almost no cost at all.

OK Zed, seriously, your unwillingness to even make attempts at using proper grammar are just making it impossible to comprehend what you’re saying. This isn’t a stylistic question or personal preference anymore; you’re not even communicating with people at this point. Your messages are indecipherable; you may as well write them in sanskrit .

In any case, I can see where Humus is coming from with respect to using lightmaps as a shadow mask. Though the basic problem of making your entities look like they actually belong in the terrain is not helped by this. After all, what good is soft shadows for non-entities if the entity shadows are still hard?

Personally, I prefer consistency in graphics. The days when you had no choice but to use lightmaps to make your graphics look good are over. You can do it right, get things consistent, and still achieve 80-90% of what light maps could. That’s a win in my book.

i disagree humus im with korval on this, i personally would accept a lower quality scene as long as it was consistent/unified.
whilst true lightmaps look great 90% of the time, its the other 10% that is just so glaring bad which destroys all the hard work, its like a film over cleopatra that youre watching + youre caught up with the story + then bang one of the romans pulls out a cellphone (hmm edit sanskit isnt related to hyrogyphics) , anyways take gears of war u have scenes there where a guy is standing next to a wall casting a vivid shadow but the wall 1meter away is just casting this indistinct smudge on the ground, ok for joe blow, they ignore this + goes wow, big explosion, good, no food, bad (yes i recently watched bride of frankenstein). but to me this huge error feels like an insult to my nether regions
yes korval i am the great ****e communicator, but i really cant improve, i would love to but, alas (ok sanskrit is a struggle but im sure if i done it in vulcan u would have no probs, sorry very weak + old joke)

Originally posted by zed:
true it works when the tree casts a shadow on the ground but what happens when a player/car goes between the tree + ground since u cant project the lightmap on that, u have to use a different method. ie it will not be unified + the shading will look different
Yes, that’s the problem I was talking about but it’s been solved with the Q2 engine.

Looking at HL2, they have it badly coded. Sometimes when an object goes from light to shadow (or vice versa), there is a sudden change.
Sometimes, it interpolates slowly.
They are using lightvolumes, which is basically a few 3D texture in RAM.

Very fast! If object center is at XYZ

color = My3DVolume[X][Y][Z];

and color the object.
Also, since they update their engine on a weekly basis, maybe they fixed it by now.
For moving objects, they render to a texture and project onto objects below. What a simple solution and they get good frame rates.

I know PCF shadow volumes and related tricks are the near final solution to the shadow problem.

color = My3DVolume[X][Y][Z];
wont work, even on a static scene due to the immesnse memory requirements if u want any reasonable sort of detailes in the shadows (eg 256x256 areas = 64kb *256 = 16MB for a very low res shading map).

projecting textures are nice as u can easily blur them but they dont handle selfshadowing, thus arent unified, also u gotta generate a map per object etc, personally ild prefer just throwing a polygonsoup at it + let itself generate in one iteration

PCF-personally i think is crap, its just normal SMs average over a few samples thus gets rid of some aliasing (at a great exspense i might add, esp WRT its cost)

what the best answer is? i dont know,
see http://www.zedzeek.com/ dec 2nd for an idea i had years ago (4years ago i just checked :slight_smile: ) which i posted here, though i see other ppl are doing similar things since then, ambient occlusion + some fella at microsoft has been doing similar stuff, where the scene is constructed from spheres/disks.
true the resulting shadow/lighting quality is low frequency, just like lightmaps, but it has the major advantage that everything can move in the scene (including lights)