What's the difference between real-time ambient occlusion vs it being pre-calculated ambient occlusion and baked into a lightmap?"
what means having the ambient occlusion computed in a 'full-screen pass'? What are the advantages of this technique?
Is 'full-screen pass' specific for real-time ambient occlusion? Could 'full-screen pass'be used when ambient occlusion is being pre-calculated and baked into a lightmap?
pre-baked lightmaps don't work so well with day/night cycles.
hi, sorry what you mean with that? What is day/night cycles?
What's there not to understand about "day/night cycles". It cycles between day and night.
Realtime is expensive and looks like shit, but works on anything on the screen. Precomputed is cheap and can look almost as good as a prerender, but only works on static objects.
Ambient occlusion doesn't have anything to do with day/night cycle what are you on? It works equally well on every lighting situation, seeing as it only applies to ambient light. Now light bounces and actual shadows are more specific and wouldn't work with dynamic light.
Basically the above.
When it's realtime, then it isn't "faked" and works on everything. Including props, objects with physics, vegitation, things that move, characters, etc. It also costs much more performance, especailly if you want to run it at a good quality setting
When it's precalcuated, it costs virtually no computer resources to run and can look much better. But it only works on static objects like beds frozen in place and static walls - you can't precalculate things that move in the game world (or can move). It also doesn't look good at all if the lighting in the world you play in changed (from either the sun going down or an area where the light sources can be moved or changed in some way).
Ambient occlusion itself is universal, doesn't matter what time of day it is. Stalker for example has precomputed ambient occlusion while still having a full day/night cycle. That looks great. You're thinking of something like VRAD from HL2 which does every aspect of the lighting, direct, shadows, and even bounces, which is only possible because it does the direct lighting statically in the first place. Stalker doesn't have any of that, only the occlusion.
[QUOTE=BmB;24242604]Ambient occlusion itself is universal, doesn't matter what time of day it is. Stalker for example has precomputed ambient occlusion while still having a full day/night cycle. That looks great. You're thinking of something like VRAD from HL2 which does every aspect of the lighting, direct, shadows, and even bounces, which is only possible because it does the direct lighting statically in the first place. Stalker doesn't have any of that, only the occlusion.[/QUOTE]
Yup. The only time ambient occlusion looks unrealistic is when it's clear that it shouldn't be dark, e.g. when pointing a light straight at it.
[QUOTE=KorJax;24242428]Basically the above.
When it's realtime, then it isn't "faked" and works on everything. Including props, objects with physics, vegitation, things that move, characters, etc. It also costs much more performance, especailly if you want to run it at a good quality setting[/QUOTE]
Technically, it is faked. Most AO in games is actually a shader called Screenspace Ambient Occlusion, which isn't really ambient occlusion at all. SSAO is actually more of an edge-detection shader, modified to utilize the scene's z-depth as well. When an object's edges lie near a polygon, it'll create a darkened map that'll be blurred outward to simulate Ambient Occlusion. However, the main problem with this method is ghosting, seeing the AO fill in after an object has moved or the camera turns. Some have workarounds for this, but they seem to be in a minority and generally lead to low-resolution shadows or poor performance. [I]But[/I], SSAO's not without its merits. Done well, can add a TON of depth and believability to a scene that just couldn't be done otherwise.
Real ambient occlusion is looking at a given pixel, and determining how much light it hitting that pixel from every possible direction. If one of the directions is blocked, it darkens that pixel a small amount proportional to the number of directions you're looking at. This method is EXTREMELY expensive for real-time purposes and is why you always see pre-baked stuff in games.
[QUOTE=Jallen;24245119]Yup. The only time ambient occlusion looks unrealistic is when it's clear that it shouldn't be dark, e.g. when pointing a light straight at it.[/QUOTE]
Quickly fixed by doing direct lighting seperately from ambient occlusion and not baking directly into the texture.
That reminds me, Crysis had terrible SSAO, especially indoors.
Most SSAO is like that. There's HBAO and HDAO but those are hilariously expensive to render. Not worth it. Besides most games except Crysis just end up overcorrecting by having both baked and screen space AO. That's just dumb.
I remember reading something on the SSAO used in Starcraft 2, blew my mind.
I'll just say this.
Prebuilt+Realtime combined can look [b]VERY[/b] good. (See Just Cause 2, Cryengine) (But to see it well in Crysis, you'll need to turn off the shitty SSAO shader first.)
[editline]11:08AM[/editline]
Hi guys, forgive my ignorance, although this is all quite new to me.
So we have three different techniques to try to achive the same type of effects (realistic depth and believability to a scene):
1. pre-calculated ambient occlusion baked into a lightmap
i. Advantages: Pre-computed is cheap. It costs virtually no resources to run.
ii. Disadvantages: It only works on static objects like beds frozen in place and static walls - you can't pre-calculate things that move in the game world (or can move).
iii. Quality: Medium. It can look much better than real-time ambient occlusion
2. real-time ambient occlusion is looking at a given pixel, and determining how much light it hitting that pixel from every possible direction. If one of the directions is blocked, it darkens that pixel a small amount proportional to the number of directions you're looking at:
i. Advantages: It isn't "faked" and it works on anything on the screen including props, objects with physics, vegetation, things that move, characters, etc.
ii. Disadvantages: Expensive. It also costs much more performance, especially if you want to run it at a good quality setting.
iii. Quality: Low
3. Screen Space Ambient Occlusion (SSAO)- It is a rendering technique for efficiently approximating the well-known computer graphics ambient occlusion effect in real time. A full screen render pass is performed wherein z-buffer data is sampled around each pixel and a darkening value is computed based on depth differences. When an object's edges lie near a polygon, it'll create a darkened map that'll be blurred outward to simulate Ambient Occlusion.
i. Advantages: Done well, can add a Ton of depth and believability to a scene that just couldn't be done otherwise.
ii. Disadvantages: The main problem with this method is ghosting, seeing the AO fill in after an object has moved or the camera turns. Some have workarounds for this, but they seem to be in a minority and generally lead to low-resolution shadows or poor performance.
Questions:
1. Is it expensive to implement Screen Space Ambient Occlusion?
2. so, Screen Space Ambient Occlusion technique only works with Real-time ambient occlusion? or does it work with pre-calculated ambient occlusion baked into a lightmap?
3. moving towards a more modular way of scene construction and terrain instancing then we would not be able to bake maps on these repeated items would we?
Method no. 2 is probably so expensive calling it "real-time" isn't exactly proper. I've seen a paper for ambient occlusion baked per object and projected outwards in all directions per object, which combined with baking would look as good as a raytraced solution, but that's the closest thing.
how would you call method no.2 then if 'real time' AO is not appropiate?
[editline]12:36PM[/editline]
what would be the different between methods 2 and 3, they are both 'real time' AO?
Because doing no.2 the way you describe it would be waaaaaaaaayyyyyyy to expensive to use in real time. That's production quality raytracing we're talking about there.
@nobago - SSAO is impossible to bake (or at least, if you used an SSAO-like technique to bake then it wouldn't be SSAO anymore). The SS stands for "screen space".
#2 is not feasable for real time and has no place in rasterisation renderers. Soon enough ray tracing renderers will be common place and ambient occlusion will be implicit anyway.
Raytracing can suck a dick, raster will always be more efficient.
so, let's say i use Screen Space Ambient Occlusion then, how the implementation of terrain instancing would affect this method? What would i need to take in consideration?
Also, how is quality when using Screen Space Ambient Occlusion? Some people think the quality of the effects is high, far better than when using pre-calculated ambient occlusion baked into a lightmap?
Why are you talking about terrain instancing? It has nothing to do with SSAO... SSAO is just a full screen shader.
[QUOTE=BmB;24260979]Raytracing can suck a dick, raster will always be more efficient.[/QUOTE]
With the way parallel processing is going, ray tracing is most likely going to be more efficient than rasterisation IMO.
It's not a matter of parallel processing, it's simply a matter of casting a ray is fundamentally more expensive than looking up a colour. Maybe you could use raytracing for certain effects, like caustics or something, but basically there's no reason to switch to a fully raytraced renderer. Raster is also very good at faking effects convincingly, raytracing is for perfect accuracy, which honestly has no place in realtime graphics.
Even Pixar knows raster is more efficient, Renderman isn't a raytracer. It can raytrace for the effects that need it, but fundamentally it's not a raytracer because raytracing is simply so inefficient. It's more advanced than a common raster renderer but the point stands that raytracing simply is too inefficient for more than specialised effects.
Sorry, you need to Log In to post a reply to this thread.
