I don't like the term "next-gen", but I wondered what kind of techniques current games like Bioshock are using. Whatever kind of technique it used, it looks good in my opinion. Some say its still using old techniques (a mix between a realtime lighting and a basic lightMap --> Farcry), in the Unreal 3 engine description I saw "directional" lightmaps (HL2 uses those as well, that's why its mentioned), and you mention shadow-maps. I don't know what is being used... That's why I ask. If its a combination between a lightMap and realtime lighting, then I'd like to know how to do this properly.
Greetings,
Rick
"Next-gen" lighting systems
What a lot of games seem to be doing these days is to fake indirect lighting with pre-baked ambient occlusion maps. This allows for dynamic lighting and yet doesn't produce the typical dynamic lighting look.
Here's what a couple of recent games are doing with lighting (all to my knowledge):
S.T.A.L.K.E.R.: Deferred shading, pre-baked ambient occlusion, realtime soft-shadows (uses something like penumbra maps)
HL2 Ep. 2: Forward shading, lightmaps (HDR, normal mapped), phong shading on moving geometry, shadow mapping (used to be projected shadows)
Killzone: Deferred shading, pre-baked ambient occlusion (?), realtime soft-shadows, pre-computed sun shadows
Crysis: Forward shading, realtime ambient occlusion, realtime soft shadows
Traditional lightmaps seem to have gone out of style (dunno if UT 3 is still using them, but I seriously doubt it).
Obviously, lightmaps have the advantage that they scale nicely, but S.T.A.L.K.E.R. for example seems to run just fine on SM 2.0 hardware (it lacks the nice shadows but it still looks pretty good). However using pre-baked ambient-occlusion won't buy you a lot in pre-processing, because it still takes a while to create them. The approach Crysis is taking with realtime AO looks very interesting and elliminates the need for pre-processing altogether (which is why their Sandbox editor provides real WYSIWYG). To me, this is one of the best reasons for moving away from lightmaps.
Here's what a couple of recent games are doing with lighting (all to my knowledge):
S.T.A.L.K.E.R.: Deferred shading, pre-baked ambient occlusion, realtime soft-shadows (uses something like penumbra maps)
HL2 Ep. 2: Forward shading, lightmaps (HDR, normal mapped), phong shading on moving geometry, shadow mapping (used to be projected shadows)
Killzone: Deferred shading, pre-baked ambient occlusion (?), realtime soft-shadows, pre-computed sun shadows
Crysis: Forward shading, realtime ambient occlusion, realtime soft shadows
Traditional lightmaps seem to have gone out of style (dunno if UT 3 is still using them, but I seriously doubt it).
Obviously, lightmaps have the advantage that they scale nicely, but S.T.A.L.K.E.R. for example seems to run just fine on SM 2.0 hardware (it lacks the nice shadows but it still looks pretty good). However using pre-baked ambient-occlusion won't buy you a lot in pre-processing, because it still takes a while to create them. The approach Crysis is taking with realtime AO looks very interesting and elliminates the need for pre-processing altogether (which is why their Sandbox editor provides real WYSIWYG). To me, this is one of the best reasons for moving away from lightmaps.
Author
What exactly means "forward shading"?
And what is an "occlusion map"? Like I said, my eyes were closed last year :)
Crysis indeed looks very interesting. In the nVidia SDK, there was a realtime ambient occlusion demo I believe, but it runned pretty slow on my GeForce 6600. That card is getting a little bit old by now, but is that technique already suitable (combined with all other effects like normalMapping, HDR, and so on) for modern cards? I don't know when Crysis will be released, but probably it should run on nowadays cards. That would be great, skipping the whole pre-generated stuff.
Thanks for the info,
Rick
And what is an "occlusion map"? Like I said, my eyes were closed last year :)
Crysis indeed looks very interesting. In the nVidia SDK, there was a realtime ambient occlusion demo I believe, but it runned pretty slow on my GeForce 6600. That card is getting a little bit old by now, but is that technique already suitable (combined with all other effects like normalMapping, HDR, and so on) for modern cards? I don't know when Crysis will be released, but probably it should run on nowadays cards. That would be great, skipping the whole pre-generated stuff.
Thanks for the info,
Rick
Quote:Original post by Harry Hunt
What a lot of games seem to be doing these days is to fake indirect lighting with pre-baked ambient occlusion maps. This allows for dynamic lighting and yet doesn't produce the typical dynamic lighting look.
Here's what a couple of recent games are doing with lighting (all to my knowledge):
HL2 Ep. 2: Forward shading, lightmaps (HDR, normal mapped), phong shading on moving geometry, shadow mapping (used to be projected shadows)
Very true. The shadowing algorithm has changed a lot since the first incarnation of the HL2 engine.
Quote:Original post by Harry Hunt
Killzone: Deferred shading, pre-baked ambient occlusion (?), realtime soft-shadows, pre-computed sun shadows
There's an article up on Killzone's entire lighting engine (and tons of references). Its indirect lighting is particularly impressive.
Quote:Original post by Harry Hunt
Crysis: Forward shading, realtime ambient occlusion, realtime soft shadows
Crysis names its ambient occlusions maps "Realtime Ambient Maps" or RAMs. However, they are in fact precomputed, but dynamically adapted in-game using portal information. The actual real-time ambient occlusion contribution stems from "Screen-space Ambient Occlusion" or SSAO.
Quote:Original post by Harry Hunt
Traditional lightmaps seem to have gone out of style (dunno if UT 3 is still using them, but I seriously doubt it).
Lightmaps have several disadvantages that (offline) ambient occlusion maps successfully address, being:
1) LMs contain lighting information, whereas AOMs store an occlusion factor; this means that lights can change colour and/or intensity in real-time without the maps having to be updated to reflect this;
2) LMs don't work with per-pixel lighting techniques such as normal mapping, whereas AOMs can be made to do so (using a "bent normal" for example), albeit by approximation.
I'm more or less interested in Bioshock's behind-the-scenes lighting engine myself.
Quote:Original post by spek
What exactly means "forward shading"?
forward is the traditional approach (the antonym would be deferred shading) where you don't separate shading from rendering the geometry (this is probably a really poor explanation)
Quote:
And what is an "occlusion map"? Like I said, my eyes were closed last year :)
As mentioned in the previous post, ambient occlusion maps store the occlusion factor for each texel. If for example you look at a wall that has cracks in it, less light will reach the inside of the cracks which is why they will be darker (more occluded). This is sort of like shadowing but unlike shadowing, ambient occlusion doesn't have a directional component, so the information stored inan ambient occlusion map will work regardless of the lights' positions. When rendering a scene with ambient occlusion, what you normally will do is to multiply the ambient color with the value stored in the ambient occlusion map (this will essentially reduce the influence of the ambient color for geometry that is occluded).
Quote:Original post by spek
What exactly means "forward shading"?
And what is an "occlusion map"? Like I said, my eyes were closed last year :)
Forward shading, as opposed to deferred shading, theoretically lights every surface using every light when it's rasterized to the backbuffer. The important difference between forward shading and deferred shading is "overdraw". Deferred shading is a screen-space algorithm, shading only those fragments that made it to the backbuffer in the end. To that end, deferred shading makes use of G-buffer, containing all the necessary geometric information that forward shading has access to at prime-time. Forward shading is often a multi-pass algorithm (although it doesn't have to be, nor does it require every surface to be lit by every light). In any case, either has its distinct advantages, look around for other posts that dwell onto this.
An occlusion map stores an occlusion factor per lumel. Contrary to a lightmap, this factor signifies the ratio of light that can reach the surface point, under a hemisphere. If you consider this ratio to be normalized, 0 would mean no light ever reaches the surface, and 1 would tell us there is no occluder to stop light from reaching the surface (e.a. it's fully lit).
Basically, it's a flexible scaling factor for lighting equations, and yields low-frequency light details (along the lines of very cheap GI).
Quote:Original post by spek
Crysis indeed looks very interesting. In the nVidia SDK, there was a realtime ambient occlusion demo I believe, but it runned pretty slow on my GeForce 6600. That card is getting a little bit old by now, but is that technique already suitable (combined with all other effects like normalMapping, HDR, and so on) for modern cards? I don't know when Crysis will be released, but probably it should run on nowadays cards. That would be great, skipping the whole pre-generated stuff.
That real-time dynamic ambient occlusion is a demo, and not ready for prime-time just yet. There are other techniques (for example, Crysis' SSAO) that yield considerably better performance characteristics at admittedly lower quality.
Author
Thanks, and thanks!
That's what I mean, I turn my back for a little while, and the game-programming world is full of new terms I never heard about. But "forward shading" is just the "normal way" to render things (draw a couple of polygons, apply its parameters/textures, shade it)? Time to search some demo's and try it myself. Does someone know some nice demo's about this stuff?
I suppose an occlusion-map will be generated just like a lightMap (although the information you store aren't colors, and the calculation is different). Are there any generators for that, or do I need to write one my own? In the second case, I need to calculate the occlusion factors for the surface lumels... Would that generate a grayscale image where white pixels are the fully lit ones? And when is a lumel exactly fully lit? And eventually the "bent normal" is stored in each pixel?
If there are 10 lightSources placed in a large world, none of the lumels will ever receive all the lights. But I suppose it doesn't really matter, as long as if there is a (bright) light nearby the shines directly on that lumel. But if I calculate it that way, I'm doing just the same as with a lightMap, except for the colors. I think I don't 100% understand it yet though...
And when applying such a map on my world, how to combine it with the lights? Is it realtime lighting, but then I also use that map to check how much of its light can reach that pixel? But what if there are multiple lights... or do I need an occlusion map for each surface-light combination (which could explain the question above)?
[edit]
I did some reading, and it becomes a little bit more clear now. But the examples are shooting rays "outside the world" (towards the sky), and then check how much % did not collide. In my case the locations will be indoor in most cases, so rays will almost always collide. Does that mean I need to shoot those rays towards the lightSources, instead of the "sky"? That could be somewhat difficult though, since point lights don't have a volume... But I could make spheres/rectangles of them of course. Anyway, if that's the case, I could end up with receiving light from multiple sources, which means multiple light colors/directions/"bent normals". How to deal with that? ...Or, is this not really the purpose of AO, and do I still need to add another technique for the diffuse lighting part?
Again, thanks for the help!
Rick
[Edited by - spek on September 20, 2007 2:16:49 AM]
That's what I mean, I turn my back for a little while, and the game-programming world is full of new terms I never heard about. But "forward shading" is just the "normal way" to render things (draw a couple of polygons, apply its parameters/textures, shade it)? Time to search some demo's and try it myself. Does someone know some nice demo's about this stuff?
I suppose an occlusion-map will be generated just like a lightMap (although the information you store aren't colors, and the calculation is different). Are there any generators for that, or do I need to write one my own? In the second case, I need to calculate the occlusion factors for the surface lumels... Would that generate a grayscale image where white pixels are the fully lit ones? And when is a lumel exactly fully lit? And eventually the "bent normal" is stored in each pixel?
If there are 10 lightSources placed in a large world, none of the lumels will ever receive all the lights. But I suppose it doesn't really matter, as long as if there is a (bright) light nearby the shines directly on that lumel. But if I calculate it that way, I'm doing just the same as with a lightMap, except for the colors. I think I don't 100% understand it yet though...
And when applying such a map on my world, how to combine it with the lights? Is it realtime lighting, but then I also use that map to check how much of its light can reach that pixel? But what if there are multiple lights... or do I need an occlusion map for each surface-light combination (which could explain the question above)?
[edit]
I did some reading, and it becomes a little bit more clear now. But the examples are shooting rays "outside the world" (towards the sky), and then check how much % did not collide. In my case the locations will be indoor in most cases, so rays will almost always collide. Does that mean I need to shoot those rays towards the lightSources, instead of the "sky"? That could be somewhat difficult though, since point lights don't have a volume... But I could make spheres/rectangles of them of course. Anyway, if that's the case, I could end up with receiving light from multiple sources, which means multiple light colors/directions/"bent normals". How to deal with that? ...Or, is this not really the purpose of AO, and do I still need to add another technique for the diffuse lighting part?
Again, thanks for the help!
Rick
[Edited by - spek on September 20, 2007 2:16:49 AM]
Ambient occlusion is completely independent of your actual light sources. This is also its primary advantage: You will only need one AO texture regardless of how many lights there are in your scene.
You shouldn't think of AO as a lightmap, more as a texture that holds additional information you use in your dynamic lighting equation. Usually, when doing phong shading for example, there are three components that make up the light information of a single luxel: diffuse, specular and ambient. When using AO, diffuse and specular pretty much stay the same, the only thing that really changes is the ambient part. Instead of just using a constant ambient value, or one you sample from a spatial structure, you'd use whatever ambient color you have and multiply it with the value read from the AO-texture.
There are several tools for generating AO maps. You could use the PRT functions in D3DX although that would probably be quite tricky. Alternatively, a lot of 3d modelling packages have a render-to-texture function and most of them also support baking AO.
Check out this pic:
This pretty much explains what AO is: In that pic, you can't really say where the light source is, because light effectively comes from all directions. Still, the image has a very good depth to it and even small details stand out nicely - this is what AO will help with.
(Sorry about the saggy...you know what...)
You shouldn't think of AO as a lightmap, more as a texture that holds additional information you use in your dynamic lighting equation. Usually, when doing phong shading for example, there are three components that make up the light information of a single luxel: diffuse, specular and ambient. When using AO, diffuse and specular pretty much stay the same, the only thing that really changes is the ambient part. Instead of just using a constant ambient value, or one you sample from a spatial structure, you'd use whatever ambient color you have and multiply it with the value read from the AO-texture.
There are several tools for generating AO maps. You could use the PRT functions in D3DX although that would probably be quite tricky. Alternatively, a lot of 3d modelling packages have a render-to-texture function and most of them also support baking AO.
Check out this pic:
This pretty much explains what AO is: In that pic, you can't really say where the light source is, because light effectively comes from all directions. Still, the image has a very good depth to it and even small details stand out nicely - this is what AO will help with.
(Sorry about the saggy...you know what...)
I am very interested in this topic. I got some useful info in the topic I started about it a while ago (linky), which got me as far as implementing a spherical harmonic based global illumination renderer. This technique only works for directional lights (not point or spot), so is really limited to outdoor use, but I would have to recommend it as the shader overhead is tiny (just a few dot products in the vertex shader), and the vertex data overhead is manageable (9 coefficients per vertex for 3rd order s.h, which can probably be compressed).
(please excuse the poor texturing, but you should just be able to make out the indirect lighting effects and the dynamic super soft shadows!)
Currently I am implementing the paper found here, which seems promising, and expands the global illumination to work with point lights (and even spots), at the cost of a lot of dot products in the vertex shader. Still they quote 30fps on a 100'000 poly scene on a gf6600. So my 8800 should eat it for breakfast :D.
Still trying to find anybody else who has implemented this, or is interested in it, but it seems like the only true GI algorithm out there that handles dynamic lights.
(please excuse the poor texturing, but you should just be able to make out the indirect lighting effects and the dynamic super soft shadows!)
Currently I am implementing the paper found here, which seems promising, and expands the global illumination to work with point lights (and even spots), at the cost of a lot of dot products in the vertex shader. Still they quote 30fps on a 100'000 poly scene on a gf6600. So my 8800 should eat it for breakfast :D.
Still trying to find anybody else who has implemented this, or is interested in it, but it seems like the only true GI algorithm out there that handles dynamic lights.
Author
Reminds me of my good old grandma...
Yeah, I kinda figured out that AO is an additional thing to improve the lighting with more realistic ambient, not a replacement for other (diffuse) lighting techniques, right?. Nevertheless, its an interesting technique and it comes at a relative low cost. But... how to deal with indoor scenes? In my case, the rays will always collide sooner or later if there are now windows. I could use a maximum distance for the rays (when traveled > x metres, it counts), but maybe there are better solutions?
That still leaves me with the original question. I also took a look into deffered shading. Sounds nice as well (except for some issues like memory, AA and transparency), but I still need shadows. I could combine it with stencil shadows in order to have a fully dynamic solution. But I don't want to loose my soft smooth shadows I get with a radiosity lightMap.
In other words, I'm searching for a nice combination that allows realistic shadows, but still has some dynamic behavuar (flickering lights, switching lights on/off, eventually small moving lights), and especually a solution that fits better with normal/specular Mapping. Like they managed in Bioshock... Or maybe old Farcry was a good example as well, where dynamic lighting was combined with a Lightmap in a proper way (how?).
@bluntman
Nice shots! But I need an indoor solution indeed. That paper showed some cool stuff, but my poor math knowledge always makes it hard to read those kind of papers. Maybe there are examples / demo's that you know of?
thanks for the info,
Rick
[Edited by - spek on September 20, 2007 9:01:19 AM]
Yeah, I kinda figured out that AO is an additional thing to improve the lighting with more realistic ambient, not a replacement for other (diffuse) lighting techniques, right?. Nevertheless, its an interesting technique and it comes at a relative low cost. But... how to deal with indoor scenes? In my case, the rays will always collide sooner or later if there are now windows. I could use a maximum distance for the rays (when traveled > x metres, it counts), but maybe there are better solutions?
That still leaves me with the original question. I also took a look into deffered shading. Sounds nice as well (except for some issues like memory, AA and transparency), but I still need shadows. I could combine it with stencil shadows in order to have a fully dynamic solution. But I don't want to loose my soft smooth shadows I get with a radiosity lightMap.
In other words, I'm searching for a nice combination that allows realistic shadows, but still has some dynamic behavuar (flickering lights, switching lights on/off, eventually small moving lights), and especually a solution that fits better with normal/specular Mapping. Like they managed in Bioshock... Or maybe old Farcry was a good example as well, where dynamic lighting was combined with a Lightmap in a proper way (how?).
@bluntman
Nice shots! But I need an indoor solution indeed. That paper showed some cool stuff, but my poor math knowledge always makes it hard to read those kind of papers. Maybe there are examples / demo's that you know of?
thanks for the info,
Rick
[Edited by - spek on September 20, 2007 9:01:19 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
