interleaved SSAO with cubemap lighting
Author: | m4d |
Date: | 01 Aug, 2010 |
Category: | effect |
Credits: |
|
Download
64bit
Description

this is a vvvv adaption of ArKano22's updated SSAO technique. (a vvvv version of his original technique by joreg can be found here) While the original version used 2d sampling, this one interleaves sampling in object space and therefore has the following benefits/changes:
- should be slightly faster
- view-independent sampling pattern - no more "boiling grain" during animation/camera movement
also ArKano22 added the following nice features to this version:
- texturing
- cubemap lighting
- self occlusion parameter to add more control over the general look
known problems:
-only edgeblur filter instead of hardware antialiasing
since this is my first contribution i'd appreciate any feedback on errors/optimisations concerning this effect.
Comments
Comments are no longer accepted.Please create a new topic in the vvvv beta forum to discuss this contribution.
can't give feedback about errors/optimisations, but i like! i think it looks better than previous joreg version, right?
thanks, defetto! :) it's probably the view independent sampling pattern, i'd guess..
something isn't right for me with this. ssao_do_ssao.fx (in the module) renders nothing just black (so the output of ssao3 module is again just black) (in the help patch). i've tried it on an ati hd4850 and on an ati hd5470. so what could cause this?
hello m4d. i have the same problem as microdee - ssao_do_ssao.fx stays black. also with ati. i tried different texture modes and render settings, no luck. thank you for making ssao3 anyways!
hey, thanks for the feedback! i attached a fixed version which should run on ati cards. actually it's the exact same shader with the compile target set to vertexshader model 3.0. i have absolutely no idea why that is necessary, but it seems fair enough as long as it runs..
edit: this also seems to work for other shaders which refuse to render on ati gpus. edit2: sorry, i uploaded the wrong version 0.2 first. if you've already downloaded it, please update for ati compatibility ;)
that was quick. it's working now... i still had to change the texture format for the upper dxtexture to A32B32G32R32F, the second entry from the bottom. only then the do_ssao renderer shows the correct depth mask. thanks again, m4d!
great! thanks, now it's good!:)
oh, that must have slipped in during debugging.. :o fixed in v0.2b. also thanks for reporting!
edit: this patch seems to be haunted by some evil curse.. -> updated to 0.2c (maybe the curse has been hastiness after all..^^)
thanks a lot for this shader! 0.2c works great! (i have an ati mobility 5850) can't wait for antialiasing.. =P
thanks for the nice comment, aze! i posted an updated technique which incorporates edgeblur to compensate for the missing hardware antialiasing. dottore helped me with porting and evaluating several different techniques over the weekend (big up to him and defetto!), but this seems to be as good as it gets in dx9. dx10 ofcourse is a whole different story. (with msaa on mrts.. mhmmm..)
working really nice,up 2 60fps,thank you so much
thanks! glad to hear that. :) more stuff coming up..
difference is subtle but it's here and the perf is same, thanks guys! (radeon users will have to use vs3 in ssao_edge_blur.fx for it to work)
aze, thx for pointing out! -> fixed in 0.3a
unfortunately it is much more difficult to go any further in dx9 with this sort of deferred approach. crytek uses a similar method for close to medium distance and a proprietary technique called temporal AA for medium to far distance objects, but then they are crytek.. :D as mentioned earlier: dx10 would really help here..
I guess it's not so unexpected that it runs slow on intel graphics, but it's rather surprising that the bottleneck is all GPU in windowed mode and CPU in fullscreen with similar FPS - must be the intel driver switching to CPU for some reason... (intel supports all of DX9 & DX10 on these cards but not all in hardware)
maybe not.. same on mine: GPU windowed, CPU fullscreen
hehe no, not really. i'd guess that it's the massive fillrate demand which is the bottelneck here. perfmeter may however report different results due to driver "optimisations" as suggested or other strange sideeffects.. i plan to release an optimised final version of this shader once i finished research on this topic. (don't hold your breath ;))
edit: just read aze's comment. i'll look into it over the next evenings. thanks for reporting!