search

SiliconStudio / xenko

Old repo for Xenko Game Engine. Please use https://github.com/xenko3d/xenko instead.
http://xenko.com
1.54k stars 343 forks source link

SSAO should be part of lighting, not postfx #449

Open xoofx opened 8 years ago

xoofx commented 8 years ago

Hi there! ;)

I saw that SSAO is coming, good! Just wanted to put an emphasis on the fact that SSAO should not be part of PostProcessingEffects as it should not be applied on the final image color but only on ambient lights. So the SSAO map should be computed before lighting a model (and then it implies to have a normal/depth pre-pass in order to be able to do this for forward rendering as well as deferred) and applied when shading/lighting surface, as part of the environment shading (ambient lights, skyboxes lights....etc.) otherwise it leads to an incorrect usage of it (though many games have been applying SSAO on all lights, but their lighting was completely wrong)

Note also that in the case an AO map is already present on a model, you need to "max" the AO between the one computed by SSAO and the baked one to avoid double count (See for more details, Moving Frostbite to PBR by Sebastien Lagarde, in the PDF course, section about "4.10 Shadow and occlusion")

sinkingsugar commented 8 years ago

That's is very true! Although I would avoid any pre-pass if possible ( can't be avoided probably at some point ), as Xenko is now quite VR focused.

LautrecOfCarim commented 8 years ago

I'll check the slides in more depth! We already discussed it with Virgile before, but decided to only add the technique as a post-fx for this release. We definitely need to make it more customizable (and physically correct ;)), but I'll need to add some profiling to check how much depth pre-pass and normals are going to hurt the performance.

xen2 commented 8 years ago

Thanks for the feedback!

Unfortunately, it will be only as a post-effect in this release, mostly because the current graphics compositor/pipeline is not configurable enough (right now, we have no other choice but to hardcode everything in CameraRendererModeForward, it won't work out long-term -- we already have the same problem for many of the other rendering technique we are working on recently, such as lightprobes & lightmap, MSAA resolve, z-prepass, shadow maps, VR, etc...).

However, we are currently working hard on addressing this issue so that both users and us can easily extend or even replace the graphics pipeline (nothing announced, it will be a "surprise feature" coming soon! :smile:)

As soon as it's done, we will be able to offer SSAO as a proper part of the lighting pipeline (and still it will be probably still be available as a post-FX for people who care more about performance vs quality, or do non-realistic rendering).