View Full Version : Lightmaps Future
02-08-2007, 09:32 AM
-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) (http://www.flipcode.com/articles/article_lightmapping.shtml)
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!? :)
02-08-2007, 10:45 AM
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.
02-08-2007, 11:50 AM
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.
02-08-2007, 12:50 PM
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.
02-08-2007, 01:28 PM
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...
02-08-2007, 02:28 PM
Lightmaps creation/bakingWhich 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.
02-08-2007, 03:17 PM
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
02-08-2007, 04:40 PM
...sorry.. what do you mean by "past there use by date"?
02-08-2007, 04:42 PM
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? ;)
Does it also export the text vertex coord for lightmapping?
02-08-2007, 10:39 PM
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"
02-09-2007, 05:16 AM
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.
02-09-2007, 05:39 PM
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,
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
02-09-2007, 07:35 PM
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.
02-09-2007, 08:01 PM
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 (http://en.wikipedia.org/wiki/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)
02-09-2007, 10:57 PM
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 differentYes, 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 :) ) 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)
02-10-2007, 04:31 AM
In FPS games, the player doesn't go up to much. Perhaps he will go up to the 3 floor of a building.
Also, these lightvolumes are the reason why the game consumes something like 600 MB.
What is your technique?
02-10-2007, 08:51 AM
Quake 3 used a "3d lightmap" for the first time, not HL2.
I'm curious, how would you do a "3D lightmap"? Assuming you are talking about a cubemap, you could render all shadow casters as black on the cubemap, and if your player or whatever was behind the shadow caster, it would look fine, but it would look wrong if the player moved in front of the shadow caster, because they would still be shaded.
I just do a raycast between the light source and the object, and limit the engine to only updating one light/model pair each frame.
02-10-2007, 02:01 PM
A 3d lightmap is not a cubemap. It is really a volume texture, often the vertical axis is much less detailed though.
Head for the Quake 3 source if you want (old) implementation details.
Please note that this low-res 3d lightmap is only used on dynamic objects, 'entities' as they are called in q3 engine. Classic 2D lightmap stored on atlases are still used for shadowing static meshes.
For a full-res colored sphere of light, you would need 256x256x256 = 16 mb of texture memory, just for the light texture.
Maybe I will use this method with a 64x64x64 texture. It would be a lot faster than processing the correct 2D mapping coords for each face.
I think you must be talking about dynamic lights on the walls, like rockets and weapon flashes.
02-11-2007, 05:09 AM
Well, a bit of history on quake 3 engine...
Originally posted by halo:
I think you must be talking about dynamic lights on the walls, like rockets and weapon flashes. Not only these, but also to light other monsters, the player weapon, etc, according to the static lighting baked and stored in the q3map level. For each voxel (3d texel), is stored RGB ambient light, RGB directional light, and the direction of light in compressed lat/lon format, for a grand total of eigth bytes.
Each voxel is about the size of the player, so the total number of voxels is not so big. This 3d texture was only stored in the cpu memory, only lighting results were send to the video card.
Search 'q3 light grid size' if you want to dig more infos on the subject. And use the source, Luke.
02-11-2007, 05:36 AM
zed, what's the most poisonous spider you've seen in your house?
Oh, I see, so they use the "3D texture" as a lookup table and set up the player lighting using regular hardware lights, based on what the current voxel says to use.
So they must be pre-processing the voxels to eliminate those that are occluded from the light, right? I thought about doing something like this, but I thought they were using a complex pre-processed BSP shape. I didn't realize they were just using simple boxes.
This would save a little time, because it wouldn't require a raycast to tell whether a light can see the player, but I have it set up so the engine only updates one light/entity pair per frame, so I think that is good.
As for weapon flashes and other lights on the BSP walls, a 64x64x64 3D texture is probably the way to go.
02-13-2007, 07:51 AM
What's the future of the normal?
02-14-2007, 10:13 AM
Leghorn: The normal vector is here to stay. Think about it; not only is it used for faces, but nowadays even for 2D textures (per-pixel on src 2D textures).
One thing to mention could be; most, if not all, programmers are tought "Keep your normal's length 1.0". It's basically in 3D programming 101. What is lost in this is that when going "advanced" the normal, if not normalized (to 1.0 length), can be used to enhance scenes.
As for lightmaps, IMHO they will not die anytime soon, as they are the cheapest way to fake (as we are all just faking everything) some lit surfaces - especially surfaces not recieving dynamic shadows. Sure, we may precalc texture+lightmap on the CPU (possibly even using ray-tracing and radiosity to produce it) and upload, but the lightmap is still used.
Also, while I suspect many of us are die-hard gamers too (in addition to developers), OpenGL and 3D visualisation has many applications we often never think of. Perhaps the most obvious could be CGI/FX for movies driving shaders forwards, to large-scale architecture where geometry performance (initially) is king. For the latter case, there simply are no characters (NPC's or not) casting shadows, and preprocessing time may be both seconds and minutes, but fly-by's in such a scene must be interactive.
Lightmaps won't die, I'm sure, but as all optimizations they must be applied where appropriate. I know of quite a few games today that (out of lazyness?) uses shaders (and thereby artificially limiting their target audience) where perhaps 90% of the uses are what I'd call "bad" and lightmaps would be more appropriate.
tamlin: I agree with what you said.
However, i have never seen a game using shaders (dynamic lighting?) where lightmaps would be better. Hm, maybe FEAR, though i haven't played that and am not sure, if lightmaps would've been better. Any other games?
As far as i can tell, most games on the market are more conservative, than one would expect, certainly because although dynamic lighting is nice, techniques such as radiosity do have many advantages, even today.
I think the problem is, that even high-end cards are still not able to reproduce lighting in a quality, that radiosity can give you. Therefore in indoor games precalculated lightmaps are unbeatable in quality. The problem is, that it is very difficult to convincingly combine them with dynamic lighting.
In outdoor-games (Crysis) radiosity makes no sense and if you are outdoors anyway, you might want to show off nice weather effects, so the sun will just be another dynamic lightsource. Using perspective shadow-maps the quality is indeed pretty good, and no one will miss the real-soft-shadows, so you can get away without global illumination.
I think Doom3 showed us all, that dynamic lighting might be nice for some games, but in general one is used to very diffuse lighting and that is what players miss in games that only use hard shadows (no global illumination i mean).
So i don't expect lightmaps to just vanish. Not as long as GPUs are not fast enough to generate nearly equal quality in real-time. And it is more likely that we see ray tracing GPUs before rasterizing GPUs reach that speed.
02-15-2007, 04:25 AM
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. That's right, Halo - DirectX is all your fault. Why, if it wasn't for you, I'll bet that profound 'Call to Action' thread wouldn't have been necessary.
02-17-2007, 09:45 AM
Think about it; not only is it used for faces, but nowadays even for 2D textures (per-pixel on src 2D textures).Good point, tamlin.
Powered by vBulletin® Version 4.2.2 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.