PGR3 update

In reality, the level of ambient light is not constant. For example, if the sun is behind heavy cloud, then the level of light in the middle of an open field will be greater than that in an alley-way. This is because the buildings either side of the alley-way occlude the sky (i.e. block out some of the light). This ambient occlusion value can be calculated in our lighting tool and stored per-vertex on the models. The first screenshot shows a car wheel with no ambient occlusion (i.e. constant level of ambient light). The second pic shows the same wheel with the intensity of the ambient light from before turned down on a per-pixel basis, depending on the ‘up’ direction at that pixel (upwards facing pixels are lighter than downward facing ones). Finally, the third picture is the full monty. This one takes into account the ambient occlusion that results from the wheel itself, so the disc and bits behind the spokes have an even lower level of ambient light because the spokes themselves block out light.

I was pretty sure Laa-Yosh said there was no way ambient occlusion could be done on realtime applications on present or near future architecture... Not saying the guy's lying, i'm saying that it's quite impressive :D
 
Anyone remember the Ambient Occlusion demo on PSP? There's certinly trickas that cen be used, but i don't know how dynamic they are. When the car drives out from a high-rise street and next to an open park, how well does the lighting change? I think it could be simulated closely enough with a few different textures and blending between them based on an approximation of the surrounding area.
 
london-boy said:
In reality, the level of ambient light is not constant. For example, if the sun is behind heavy cloud, then the level of light in the middle of an open field will be greater than that in an alley-way. This is because the buildings either side of the alley-way occlude the sky (i.e. block out some of the light). This ambient occlusion value can be calculated in our lighting tool and stored per-vertex on the models. The first screenshot shows a car wheel with no ambient occlusion (i.e. constant level of ambient light). The second pic shows the same wheel with the intensity of the ambient light from before turned down on a per-pixel basis, depending on the ‘up’ direction at that pixel (upwards facing pixels are lighter than downward facing ones). Finally, the third picture is the full monty. This one takes into account the ambient occlusion that results from the wheel itself, so the disc and bits behind the spokes have an even lower level of ambient light because the spokes themselves block out light.

I was pretty sure Laa-Yosh said there was no way ambient occlusion could be done on realtime applications on present or near future architecture... Not saying the guy's lying, i'm saying that it's quite impressive :D

Perhaps you should reread what you quoted. :D
 
V3 said:
london-boy said:
In reality, the level of ambient light is not constant. For example, if the sun is behind heavy cloud, then the level of light in the middle of an open field will be greater than that in an alley-way. This is because the buildings either side of the alley-way occlude the sky (i.e. block out some of the light). This ambient occlusion value can be calculated in our lighting tool and stored per-vertex on the models. The first screenshot shows a car wheel with no ambient occlusion (i.e. constant level of ambient light). The second pic shows the same wheel with the intensity of the ambient light from before turned down on a per-pixel basis, depending on the ‘up’ direction at that pixel (upwards facing pixels are lighter than downward facing ones). Finally, the third picture is the full monty. This one takes into account the ambient occlusion that results from the wheel itself, so the disc and bits behind the spokes have an even lower level of ambient light because the spokes themselves block out light.

I was pretty sure Laa-Yosh said there was no way ambient occlusion could be done on realtime applications on present or near future architecture... Not saying the guy's lying, i'm saying that it's quite impressive :D

Perhaps you should reread what you quoted. :D

:| just did... ?
 
london-boy said:
In reality, the level of ambient light is not constant. For example, if the sun is behind heavy cloud, then the level of light in the middle of an open field will be greater than that in an alley-way. This is because the buildings either side of the alley-way occlude the sky (i.e. block out some of the light). This ambient occlusion value can be calculated in our lighting tool and stored per-vertex on the models. The first screenshot shows a car wheel with no ambient occlusion (i.e. constant level of ambient light). The second pic shows the same wheel with the intensity of the ambient light from before turned down on a per-pixel basis, depending on the ‘up’ direction at that pixel (upwards facing pixels are lighter than downward facing ones). Finally, the third picture is the full monty. This one takes into account the ambient occlusion that results from the wheel itself, so the disc and bits behind the spokes have an even lower level of ambient light because the spokes themselves block out light.

I was pretty sure Laa-Yosh said there was no way ambient occlusion could be done on realtime applications on present or near future architecture... Not saying the guy's lying, i'm saying that it's quite impressive :D

It says it's being done with a tool ie non realtime. This precalculated data is then plugged into the game engine. Spherical harmonics works the same way using precalculated datasets. It only works on static geometry and in this case it's a wheel.
 
PC-Engine said:
It says it's being done with a tool ie non realtime. This precalculated data is then plugged into the game engine. Spherical harmonics works the same way using precalculated datasets. It only works on static geometry and in this case it's a wheel.

Oh that explains it :D
 
london-boy said:
I was pretty sure Laa-Yosh said there was no way ambient occlusion could be done on realtime applications on present or near future architecture...
Fake Ambient Occlusion is probably one of the easiest 3D rendering method that could be implemented in a (next-gen) engine.
And in 99% cases, in a game scene, I'd say it would look nigh identical compared to the offline solution.
 
PC-Engine said:
It says it's being done with a tool ie non realtime. This precalculated data is then plugged into the game engine. Spherical harmonics works the same way using precalculated datasets. It only works on static geometry and in this case it's a wheel.
Spherical Harmonics! That's the technique used in the PSP demo. It looked very effective. I think it was precalculated for the scene on the PSP (rather than precalculated on a development workstation).

This could be done, so levels are loaded, lighting calculated, and then you play. Though it might be quicker to pre-calc and save on the game disc. (?)
 
Vysez said:
london-boy said:
I was pretty sure Laa-Yosh said there was no way ambient occlusion could be done on realtime applications on present or near future architecture...
Fake Ambient Occlusion is probably one of the easiest 3D rendering method that could be implemented in a (next-gen) engine.
And in 99% cases, in a game scene, I'd say it would look nigh identical compared to the offline solution.

yes,and you don't even need to calculate a real occlusion ,a dirtmap does the trick way faster.
Strange that they actually bake it to vertices.A low resolution dirtmap would do better in allmost every case.

*edited for keyboard dyslexy (sp ?) *
 
_phil_ said:
yes,and you don't even need to calculate a real occlusion ,a dirtmap does the trick way faster.
Strange that they actually bake it to vertices.A low resolution dirtmap would do better in allmost every case.
That's what I'm thinking too, they definitely didn't choose the easiest way for implementing their AO effect.
 
It's precalculated in that you're not calculating it in real time. Like lookup tables for sin and cos from many moons ago. Where you pre-calc it doesn't matter I guess.
 
Shifty Geezer said:
It's precalculated in that you're not calculating it in real time. Like lookup tables for sin and cos from many moons ago. Where you pre-calc it doesn't matter I guess.

It does if you want high accuracy/quality...
 
_phil_ said:
yes,and you don't even need to calculate a real occlusion ,a dirtmap does the trick way faster.
Strange that they actually bake it to vertices.A low resolution dirtmap would do better in allmost every case.

Can you explain? The occluder is static, but the occludee and ambient light level are dynamic. How does a dirt map help?
 
I'd guess, in areas of shade (based on proximity of objects?) you'd decrease the alpha of the occlusion map, and vice versa, adding a layer of darkness to the surface.
 
I'm not allowed to show you the difference between a precalculated static occlusion map and dynamically calculated (raytraced) occlusion... but on characters, it's very very evident.
Edit: that is, using images from our current work, guess it wasn't clear without this bit ;)

Think about this... On the side of a character's body, there's a given amount of indirect lighting from the sky and the enviroment when his arm is raised. As the arm comes down, it slowly starts to occlude this light, and when it's resting near the torso, almost 90% of the light that was previously there is gone. If the incoming light was direct, there'd be a shadow, but I'm talking about indirect light, stuff like an ambient cube map in HL2 or additional fill lights.

Or, on that image for example, there should be a very soft contact shadow under the wheel, where it touches the ground, and an even larger and softer and blurry contact shadow from the car's body; and those 2 contact shadows should be gone if the car gets up in the air somehow.


It is a subbtle but very dramatic effect, exactly because it goes a long way in tying dynamically interacting objects together.
 
Back
Top