SSAO development thread

I decided to clean up the thread in the showcase and move all relevant development comments, bug reports and suggestion in a new thread in which I can actually *post* images please report problems here, etc.

So, I added now the following features (or fixed the following bugs):

• Sky entities are automatically bound to the diffuse view so that AO isn't calculated anymore on the skybox (if visible)
• Fog is now supported (emulated in the combine pass - I can not disable fog in specific views!)
• particles are ignored
• To support sprites with soft alpha textures, you can set a flag liek FLAG2 or so (is customizable!). This way they are discarded from the depthmap and therefore receive no AO, but you can see through them the AO of hidden surfaces, depending on the sprites' alpha texture (see image(s) below).

Here is how I deal with the soft alpha issue:

This is how it looks like at the moment:

I discard pixels with alha less than 50% and sample the depth of the sprites, like the plants in the Sponza Demo. This is wrong! The brightness of the sprite is drastically reduced and the (soft) alpha is cutted. We do not want this on effect sprites, like halos, lightshafts or drop shadows!

So, in the seperate view I sample once the depth of the scene without entities with FLAG2 on (the alpha sprites) and at the same time the alpha of these entities:


I use the depth map for AO and fog calculations. In the combine stage, I simply supress AO depending on the alpha mask and then I apply the fog:


A fellow here promised me beer and chips if I finish the soft alpha-sprite support very soon (due to a dead line for his project), so I delayed other requests to help him out. The pending list of features are these:

• no blur on sky pixels and 100%-fogged pixels (better performance)
• checking stencil shadows
• checking blurred stencil shadows
• dual AO calculation so that meshes with alpha will receive AO and you can see AO on hidden surfaces through their transparent parts
• use static AO via 2nd UV set if provided (better performance)
• seperate particle mask if fog is active
• generate random vectors on startup (optional)
• try other filtering options for the blur stage
• enhance Sponza demo with effects to demonstrate features and support of pre-existing shaders

If something is missing, please tell me. I will add the first item of the todo-list (ignore sky- and 100%-fog pixels in the blur stage), clean it up and then I make a public release!

If we ever meet (Dusmania, gamescom or any other meeting); help remind me to get you beer and chips as well

This is gonna be a very nice contribution, cant wait!

regards,

Small update: I have now three demos

1.) Sponza as before
2.) new testscene - see images above, and
3.) one in which I demonstrate how to write a custom object shader to use my solution and deliver all necessary data

And I am also working on a fourth demo with a whole shader pipeline (object- and postprocessing), because I didn't tested it enough with "real" scenes.

So, sorry for the delays!

We just want to show some screenshots of our upcoming game (without and with this greate shader):








I've asked some of our zombies some minutes ago, and they liked it

looks nice, but looks better with moving objects^^.

can this work with other PP effects? what would need to be done to get it to do that

Well, as every post processing effect there is somewhere an output bitmap that is rendered to the screen. So, yes, you can place your PP chain afterwards.

But wait for the next release in which I include a demo which demonstrates how to do that in the integrated SSAO mode, maybe I have to write some additional code to make it even easier (like chopping of the combine stage so that you can tinker directly with the AO-, the transparency- and the diffuse-channel).

Ok, two things happened:
1.) After finishing the base code for my new testscene I encountered that I have a too low fog resolution. But:
2.) JCL adds a NOFOG flag for views. As soon as the new beta is out I will adopt to this, and
3.) I realized that I --HAVE TO-- improve the visual quality of the SSAO because on very clean scenes with lots of rounded, planar surfaces ... it sucks like hell - in terms of AO bleeding!

So here is what I will do the next days:
a.) polish the changed code
b.) make a release

The fog support is currently done in the shader and as soon as I get the new beta I will switch the fog code. Then I focus on the AO bleeding and stuff...

Maybe you have seen it already: I have released the source and the demos of the SSAO v0.3 in the showcase (I also updated the feature list und gallery images).

Have fun with it, and please post any stuff related to the release there (e.g. bugs) and dev-related stuff here :-)

Best regards and have a nice day,
-Chris

Hi Chris,
deutsch: Habe bereits die Demos getestet, bei den neuen Demos hat alles
fehlerfrei funktioniert und sieht klasse aus. Bei der Sponza-Demo musste
ich die beiden defines (PP_SSAO_NOFOG und PP_SSAO_NOSOFTALPHA) ausklammern
damit die Scene ohne schwarze Artefakte im oberen und unteren Drittel
funktioniert.
Beim integrieren in mein Projekt stoße ich allerdings auf einige Probleme.
Sobald ich die "ppSsao.h" include bekomme ich die Malfunction W1507
mit dem Kommentar "video functions not available before first frame"
selbst wenn ssaoIntegrate(camera, true); ausgeklammert ist.
Wenn ich trotzdem OK drücke folgt der Error 1513 "script crash in
ppSsaoGenerateRandomVectors: sys". Mache ich trotzdem weiter öffnet das Level mit 0-1 frames, alles ist schwarz/weiss und der Rechner muss neu gestartet werden.

english: have tested the new demo, it work good and looks great. But at the SponZa demo I have to exclude (PP_SSAO_NOFOG and PP_SSAO_NOSOFTALPHA) to run the scene without black artifacts at the top and the bottom of the screen.

So... while including it in my project I get some issues:

When I include the "ppSsao.h" I get the Malfunction W1507 with
the description "video functions not available before first frame"
even when ssaoIntegrate(camera, true); is excluded.
When I press the ok Button the following error message is shown - Error 1513 "script crash in
ppSsaoGenerateRandomVectors: sys".

If I press Ok again the level runs with just 0-1 frames - its just in black and white and the PC needed a restart...


mfg Jane

Edit:

Habe eine wait(1); (im main-skript) hinter dem setzen von
video_mode, camera.arc usw. ausgeklammert, woraufhin das
Level zwar startet, nach wenigen Sekunden jedoch die Meldung
script-crash in bindsky kommt oder einen schwarzen screen,
der ein par mal wieder weg geht bis sich das ganze aufhängt
oder der Rechner abstürzt.

Um auszuschliessen, daß es am Rechner liegt:
Referenz-Rechner:
AMD Athlon 64X2 4800, Geforce 9800 GT, 4GB DDR3-Ram
Performance-Test-Rechner:
AMD Athlon 64 4000+, Geforce 7600 GT, 2GB DDR2-Ram

Hi Jane, nice to see someone testing it :-) I take your issues serious, but let me ask some questions because I can't reproduce your problems here, so I need some hints.

• About excluding PP_SSAO_NOFOG and PP_SSAO_NOSOFTALPHA: which resolution (do you just start the demo?) and: --- which engine version are you using? I have tested it on 4:3 and widescreen resolution and I have no problems. Can you please post an image of these "artifacts"?
• "video functions not available before first frame" - I have in the ppSsao.h a starter function ("ppSsao_h_startup"), which generates the random vector map and loads the shaders dependent on your #define configuration. Try placing a wait(1) right before the line with "#ifndef PP_SSAO_CUSTOM_VECTORMAP"...
• Do you create your sky entities dynamically with ent_createlayer?
• Where do you place the integrate-function?

Can you please remove everything from your a local copy of your game so that the problem remains? It would be very fruitful if you could provide a minimal testcase in which all problems you mentioned are appearing at the same time. As long as I don't have any insight in *how* you use it, I can't tell if you do something terribly wrong or I am terribly wrong assuming how users develop their games ;-)

Best regards,
-Christian

I have send you message , hav tested Sponza-Demo with you default options on 4:3 monitor.

I solved the issues with the help of Jane. Has anyone problems as well?

I am redesigning the shader pipeline at the moment to get normal data involved in the postprocessing, too. This way I can use another blurring which shall avoid bleeding. Second, and that is my primary goal, I am working on that the AO is calculated on the half of the screen size. I found an interesting technique for edge preserving upsampling which takes the depth and the normals into account before and after downsampling.

I implemented a bilateral gaussian blur with single dynamic weights, respecting the depths and surface normals of each sample pixel compared with the base pixel. I still have to fix surface incontinoutities in the sampling process, but it looks already better!

The images are the AO result after bilinear downsampling, AO approximation, blur and bilinear upsampling. Remember, I calculate on the half of the resolution..

Old (with 4x4 box blur):


New (with bilateral gaussian blur):


Next thing after fixing the above mentioned stuff is bilateral upsampling and switching to A8 exclusive features to reduce the overall texture lookup-count.

link?

Just take the small paragraph about that upsampling. The idea is relative straight forward. When you have generated content that is based on coarse material that was previously hires and therefore downscaled, you are looking for an inverse projection, that transforms the coarse data into hires data. Bilinear upscaling is OK, but it doesn't take edges and surface normals into account. So you compare hires and coarse surface normals (and depths) per pixel and calculate sampling weights for a bilateral upscaling.

thx

Hey, I finished also the upsampling process as well. Now I have no bleeding anymore, a smoother AO map and x1,5 - x2,0 of the the framerate. I am very satisfied

Since I switched the fog handling again and I use the NOFOG flag for views, I can't release a new version until the current A8 beta gets its public release, so please post further requests, if you have any.

why dont you release a compiled one for the community, just for showcase purpose to compare the FPS on different machines o.O

Greets
Rackscha

Afair, it isn't allowed/possible to create a compiled version of your game/demo/whatever with a Gamestudio beta.

afaik it's not possible, it compiles with last-release version if you try to publish, not the beta version.

Yes, I can't make an EXE... but I made screenshots with the debug panel on! I have a laptop here which is already slow on the Sponza demo, that might be the reason why there is no or only a small speed increase... the "white" demo is one of the new demos with very little overhead and a mini-shader that draws the whole model white, so that you can see directly the AO map without tweaking the AO-shaders.

click to see the screenshots as a slideshow

[EDIT] It is always 1.) the v0.3 version with fullsize processing and 2.) the new v0.4 version with the improved blur and the new upsampling -- on half the resolution (if you didn't knew).

@JustSid: Didnt know about this restriction^^

@HeelX:

Looks kinda great^^

Greats
Rackscha

I waited for JCL to release the new A8 public beta (A8.03.2) so that I can also release my new version ^^ you'll find it in the showcase.

I already have a bug report about animated sprites and I have requests for a tutorial. What do you think? And: do you think that it is worth it to keep the support for an own custom integration without needing a second deferred view?

Bye,
-Chris

lol so A7 users dont get all these pretty features huh

I just take advantage of new and upcoming A8 features. Since the NOFOG flag is A8 exclusive, just take it away and make sure you don't have fog in your level - then it works under A7, too.

Its an option for A7-users with "d3d_flags &= ~2;" (switch pixelfog to
vertexfog)?

The problem is, that I need to have NO FOG in the deferred view. To get this with A7, I have to override fog_color with 0 and do the fog on my own in the combine stage which involves also additional depth-lookups plus additional Lite-C overhead code. So it will be definetely a bit slower in A7!

But I will add the feature for the next version! Chips and beer!! BWAHHH!!! André!!!!!!!

Progress:

• added support of animated sprites
• renamed object shaders to cause no errors (e.g. in WED) due to too long filenames
• in the deferred view all sky entities get a shader assigned, which clips the sky, so that no additional sky management routines are needed anymore (less Lite-C overhead!)
• without the need to assign all sky entities to the base view anymore, the user isn't restricted anymore in regards to the client_id of his/her sky entities
• added an additional particle pass to render particles over the already AO-shaded scene. This way, AO doesn't shine through particles anymore
• disabled bilinear filtering in all texture lookups where not necessary to reduce the remaining AO-bleeding

Screenshots for the particle feature:

LEFT: This is a testscene with a nice fire and lots of particles for it.
MIDDLE: This is how it looks like at the moment: particles are rendered in the diffuse view and ignored in the deferred view, so AO is shining through the particles.
RIGHT: This is how it looks now with the seperate particle pass (particles are ignored in diffuse and deferred view and rendered at last).



After I have tested the particles stuff enough (e.g. with other transparent objects... let the alpha wars begin!! ), the next thing is an A7 compatibility mode (this means mostly emulated fog).

Best regards,
-Chris

The additional particle render pass is worth every performance cost, it looks very nice!

As you might have seen it, there seems to be a bug in either the particle system of GS or in my code - the particles are drawn brighter as they are into the AO'ed-scene. JCL confirmed it and is working on it after he has finished some more urgent work.

In the meantime I will have a look at (blurred-) stencil shadows, since this is maybe the most popular method of adding dynamic shadows atm. I already had some requests for the support of the new PSSM feature, but first I didn't tried it yet and second I want to wait until it has matured a little bit more so that JCL releases a public beta release in some time. Sounds reasonable, ain't it?

I started programming on Trixie HD and will be away from 12.-22.10. (London & the Netherlands), so don't expect any big news until the end of the month.

Best regards,
-Chris

Yes, I've followed your bug report. Nevertheless, I find that the particles look much more appealing to the eye because of this bug.
Have fun in London!

Short message: stencil shadows are now working correctly, so that you can use stencil_blur(1); from mtlView.c now:

(watch it fullsize by rightclick .. / show image)


Since I have access to normal- and depth values per pixel, I am thinking of adding my own support for screen-space blurring the stencil shadows - because I can then avoid shadow bleeding (because it is --screen-space-- blurred) and offer better blurring methods (I hate that poisson blur... it is too soft for my taste)).

I am also very disappointed that block-lightmaps, the stencil shadow map and my AO map are ultimately multiplied all together. Isn't taking just the darkest value more realistic? I never saw that e.g. a shadow of a person, who is walking into a shadow from a house, is darkening the shadow of the house

Grr... man, I hate monolithic shader solutions (like those one and half things which are talked about here and then) but I think I have to take this convenient opportunity in the future

Well,
the Shadow darkens shadow effect is truly present, even with a house shadow.
Sometimes its more/less noticeable.

Effect is caused by less 'Light bounces' hitting the environment, blocked by your body.

which is actually what ambient occlusion does, still your shadow and house's shadow do not add up.

hooooo that Niceeeeee

Good news for some guys: the current development version of the SSAO solution is now fully compatible to A7.86 and A8.

When do you plan to upload a new version?

When the next public A8 version will be released, because it includes a necessary bugfix for the newly added particle stage. I also want to take the opportunity to take that time to reduce the memory consumption a bit.

What about performance? Are there some improvements also?

2 Bottles of Beer? Thats not enough ! sry for OT

Since the SSAO fragment shader is a building block, it can be easily exchanged by other techniques, which I am considering (not replacing but support for more than one technique). So, other, faster techniques might be possible in the future.

Another way to speed up SSAO in general (independent from the used algorithm) is re-projection of previously sampled AO terms and Monte Carlo-integration over time. This way less samples are taken at each discrete time step with a higher quality for samples which have been seen in the past x frames.

The threshold-blur stage is now shader model 2.0.

For another reason, I changed the way I pass coarse normals (for reducing memory consumption). A positive side effect was that I don't need to reconstruct them anymore in all PP stages (because they are stored on an own 888 target). This resulted in less arithmetics. Plus, I changed the gaussian weights in the blur stage so that I get now the same image quality with 5 texture lookups now instead of 7 per pixel per pass (H and V).

I am also investigating the arithmethics involved in the bilateral upsampling in respect to scalar nature of the AO terms (they are monochromatic! - the original paper was targetted on upscaling RGB colors only). If I am right, I think the upsampling will afterwards be two times faster for the cost of one additional half-sized 8888 rendertarget.

Third, I think the AO shader can be modified so that it can be used iteratively, using one PP stage per AO-sampling. This allows a dynamic configuration of the quality (which is hardcoded at the moment) and maybe also PS 2.0. Maybe. Don't bet on it

So these are the news and my thoughts, - so lets start coding!

The bilateral upsampling is now x2.3 times faster, thanks to less lookups. Instead of calculating for each HiRes-pixel the upsampled result by examining the 2x2 neighbourhood of coarse samples, I calculate on half the resolution for each coarse sample its 2x2 HiRes counterpart. The coarse neighbourhood is still examined, but only once for all 4 HiRes pixel and not each time for each HiRes Pixel.

I got on my notebook with chipset graphics an immediate performance boost of up to 10 fps (results may vary on faster machines, though).

Still working on the heavy 0.5 release (in the case you were curious)... the new A8 release candidate comes soon to the public afaik and I hope I can finish the new ssao release this year! Tons of good stuff in there, though, I am still struggling with some nasty problems, - but beside that, Zapan reported that it runs (and looks) quiet good in their Zombie game!

*möp* request for A7 version *möp*

It will be A7 compatible.

Go for it: SSAO for A7....... & A8 v0.52

Ok, everything regarding the development of the next version (0.6) will take place here. The development direction is pushed from different sides - some commons users here and one actual team, developing a commercial game, so new features will not only affect quality and speed, but also compatibility to Gamestudio in general and content creation/usage.

The first new feature is caused by this: automatic sprite decal-support. If sprite-entities have the DECAL flag on, they get ignored in the SSAO stage and won't contribute to the softalpha mask, because it is assumed that they are "glued" to the surface behind them. This is how it looks like:



In general, entities can be excluded manually, too, but I doubt that this makes much sense, because AO is shimmering through them, then.

So, if YOU have any feature requests, don't hesitate to post them!

Next: (automatic*) GPU bones support (A8/pro only).

Best regards,
-Christian

*: depends on JCL finding that undocumented flag

Hell yeahh!

I love how realistic this looks.

Thanks! - You are one of those guys who are working with different engines and next-gen stuff - do you have have any suggestions and remarks?

Actually no, it looks perfect. As long as you make it adjustable it will be fine.
Some engines offer quality settings or range. Here are some SSAO settings I can adjust in one of these engines:

radius, sample count, occlusion intensity, blur, downsampling, occlusion attenuation, Min Z, random texture

You are talking about Unity, right? Ok, Occlusion radius is no problem; will be added.

Number of ambient occlusion samples is currently hardwired to one pass (8 samples) and can be changed in the shader file easily - I will see if I can reorganize the shader so that it is used in an accumulated fashion, so that the sample count is constant per pass, but dynamically chainable so that arbitrary passes are allowed --> I simply don't want a conditional loop. The shader is so big, it is making it all worse then.

Intensity of ambient occlusion is already adjustable through two parameters: ssaoConvexHighlight (brightnes of edges) and ssaoConcaveDarkness (darkness of ambient occlusion).

Amount of blur to apply to ambient occlusion will be possibly, maybe - I am tinkering with that stage soon to make it faster.

At what resolution calculations should be performed is now hardcoded to 1:2 (half of the screen). I already wrote on my todo-list that I try to make that dynamic for all postprocessing shaders so that you can vary this; but mainly I wanted to experiment with blurring in a resolution one step smaller than the AO stage so, we both meet here, hehe

Occlusion Attenuation is commented on the Unity page with "how fast occlusion should attenuate with distance". What does this mean?

MinZ - "Try increasing this value if there are artifacts": same here, what does this actually do??

--> I see what I can do and I'll add such parameters into the GUIs of all demos for you to play a bit with them

[EDIT]: what is meant with "random texture"? The one that determines the random rotation vectors?

Sorry, I dont know the technical details about MinZ. The random texture is a noisy looking 64x64px 24 bit colored texture called "RandomVectors". So I think you guessed it right

I forgot to reply to the attenuation question:

Generally attenuation in 3d graphics is how something decreases when objects are farer away. For a light it is how brightness decreases over distance. So it probably will fade occlusion off over distance. Maybe the translation of attenuate helps a bit:
http://dict.leo.org/ende?lp=ende&lan...earch=attenuate

Time passes by and after four months or so of no news about my SSAO solution you may wonder what happened. At the time of the last release (January), I was asked to add GPU and decal sprite support, as you might have heared, JCL implemented new features for this concern for me and after some beta iterations, they are now stable and ready to go. Inbetween I had much trouble with my work, written tests, a research paper and social issues, so, everything slowed down but now it seems that I have more free time and I am ready to go!

Here is an extract from my changelog in the order of implementation, which documents, that I am working on it :

• surface flags begin now with "SSAO_TYPE"; new surface flag: SSAO_TYPE_IGNORE for clipping e.g. decal objects
• all object shaders automatically detect and support now gpu animations (A8 only)
• Scene rendering has been splitted into two passes, once for depth map(s) and once for normal- & soft alpha map(s). Rendering the scene twice is cheap, though, the additional costs of this overhead are outperformed through the optimizations concluded through this, as follows:
• In addition to the depth- and normal maps which have been generated as before, counterparts get generated which include those depth/normal values of objects which were clipped (like softalpha objects). These maps can then be processed in later, complex shader chains, attached to the SSAO solution (like DOF) without rendering again the scene!
• Render targets consume now (including the additional two new maps, s.a.) 19% less memory due to the usage of 16- instead of 32bit FP targets and 888- instead of 8888 targets (-> faster, less memory)
• Since depthmaps are now generated again with absolute floating point values, the 8888 32bit -> 16bit FP target encoding / decoding scheme is abandoned (-> faster)
• If a view is registered as post-SSAO stage via ssaoSetContext, a new rendertarget is created in which the final image (diffuse * ao) is rendered into. Though, you can still access this image simply via TargetMap in staged views, for instance in simple PP effects like with pp_sepia.fx
• You can gain access to all screen-sized maps (clipped/full depth/normal-map, softalpha map, diffuse and combine* map with a set of getter-functions (*: only if a post-SSAO view is defined, s.a.)
• With registerSsaoResolutionEvent and registerSsaoTargetRecreationEvent you can now register external events, which are called at the end of the SSAO process. If they are called, they indicate either a (re-)creation of at least one render target and/or a general screen resolution change. Useful, if you want to adapt automatically render targets of other attached complex shader effects without checking yourself if something happened!

I am working together with Pietro Nifosi, who is generously contributing his Wasteland Remake assets for a new demo I am working on which should serve as proof of concept for integrating my stuff in complex game environments with more than just SSAO as shader effect.

I recognized some people which asked for a connection to Shade-C (Pietro Nifosi -> Boc_Havoc) or a linkage with other effects (Slin, SSAO->DOF, for Zapans game). So, I decided to put much more effort in making it customizable, but still yet powerful and complete on its own. In contrast to Shade-C I follow the strategy, that a whole shader solution is designed as a component, which is complete on its own, easily integratable, open for pre- and post-shader chains and that it, if seriously programmed, can substitute redundant things to reduce memory consumption and overhead (like serving the depthmap for other shaders, so that they don't need to render it).

So, if you failed to integrate it in your project, because your project is too complex or it is too hard for you, please tell me!

Further features planned for the 0.6 release are:

• ingame slider panel for adjusting artistic SSAO properties
• possibility of shader injection for custom Vertex Shaders, like for foliage/grass-waving scenarios
• when disabling and post-SSAO effects are needing depth/normals, these will be still sampled

I hope, there are still people interested in this and like these new news. Any news are good news ^^

Best regards,
-Christian

SSAO is always inteesting! Once I saw SSAO applied to my own levels, i can not imagine them anymore without!

Yes please continue with your project, I for one greatly appreciate your efforts
and the amount of time you have put into the A8 SSAO.

When I can spare some money I will defenitaly make a donation.

It is one of the best shaders i see for 3dgs, please keep your work...
...and thanks for this shader.

Cool, thanks guys

This is what I am talking about: GPU animated crowd + simple DOF + PSSM + SSAO humanoid demo:



Maybe I'll make that game scene (with the Wasteland assets from Pietro) later, when I implemented lightning models.

Are the darker areas on the model SSAO only? Looks pretty neat!
DOF is overdone though, but I guess it's just to showcase it...

Would love to see that in motion. Looks like it's a pretty action-loaded scene...

Apart from the shadowmapping, yes I am struggling right now with de- and activating SSAO while attached shaders re-use the still generated depth/normalmaps, but that should be fixed this weekend. I will make two comparison shots later. The action is the same as in the crowd-demo, since I use the exact very same model but yes, the actors are fighting, running, falling down and idle'ing around. Pretty much going on.



It's my first time writing a DOF shader and I wanted to assure that everyone is "seeing" it

DOF is pretty cheap, though (poisson blur on half the screen, blend via depth map from SSAO stage). Animations (though, very fast on GPU) + PSSM are already beating down my fps, SSAO adds it's own little performance decrease, haha..., so on my laptop (I have no mega-power-PC) I have a FPS which is not so.. fast. I will see if I can capture a video this weekend.

Reading through your changelogs it seems that you really want to get the most out of it.
Thank you for keep updating and optimizing your SSAO implementation, HeelX!

Here is a video on YouTube:

SSAO for Gamestudio - Humanoid Demo (WIP): GPU-bones, PSSM, DOF + SSAO

And a small comparison of the different techniques (click right, watch image and zoom in):

Damn, damn, ****, ****, ****-****!!!

I don't know WHY, but using multi-floating point targets (bmap and target1) and storing the un-normalized depth makes me insane. Yes, it works here. And there. And there. And look, there too!!! But then Superku comes and proves me that his card is totally insane and produces garbage

I think I will switch back to my previous, working 888->FP encoding scheme. ****!

Uh, my last post about this is very long ago ha, but I worked again a bit on it.

I decided to drop support of akward cards like the one of Superku. So, depth is now always sampled as floating point render target.

I finished today dynamic shader compilation. Yet, I already pass all Lite-C #define's to each shader, and after adding lots of rudimentary #define's and #if's I already got a boost of 9 fps in the white demo (50 -> 59fps) here on my laptop. I even expect more fps gain when I added permutated shader compilation for objects because of removed if statements and then also removed redundant render targets and access to them.

Also, you can supress GPU support now if needed (if you have A8), this reduces generated Lite-C code and produces less object shader code (the corresponding technique and VS is skipped then during compilation). An edition check will also disable generated gpu bone code, if you use A8, but have not pro-edition.

I'll add now also the possibility to define some shader constants in your Lite-C code, which had to be changed directly in the shader code, for your convenience, like AO passes, blur parameters or certain thresholds (NOTE: this will be done with #define's!); -as well- as to turn off some shader functionalities (like adjustable brightness/darkness parameters) -or- to hard code variables (like camera clipping values or brightness/darkness parameters).

Since my efforts are leading towards the possibility of a high customization and resulting, strong optimizations, I will also start now working on a manual, so that you are not getting lost with each new version

I decided that these are the remaining features for v0.6 (maybe begin of July), everything else (see one of my posts above) will come later, for v0.7.

Best regards,
-Christian

P.S: Can anyone please give me a clue how to make a CHM manual like the Gamestudio-manual with the exact same design?

Use this css: http://www.conitec.net/beta/css.css .. For the rest just have a look at the source of the manual html files.

Just keeps better and better, Terriffic shader program HeelX

Hi Chris

Very nice contribution! I like the look and feel of this effect very much. One question: how do i combine it with the 3dgs build in hdr effect?

I'll check that tommorow. Be preparepared for awesomness! Best regards, JCHeelXC

That´s probably a bit more difficult than some would expect. Yesterday I tried to add the 'erode' effect to this ""hdr"" thing, but eventually failed...

OK, I failed, too. Or better: I got it partially working, but messed up. This is a good testcase to improve my compatibility to other PP-shaders, so I will look into it, so that I get it work in the 0.6 release!

Great! Cant wait for it...

The code for the 0.6 release is now feature complete, but not stable (I am bugfixing now), manual is 90% complete, HDR compatibility will be skipped to a later version. Sorry.

Great, I really looking forward to it!! It will give my project the last kick. ; )

Nice that at least one person is looking forward it honestly, I think that there are some bugs in the current beta concerning view materials for static meshes... my shaders behave on it different between A8.20.1 and the current beta and different if I compile a map as BSP or ABT map... so I have to wait until this is fixed for the release.

In the meanwhile I replaced the arithmetic AO-decoding from the half-sized bilaterial upscaling stage to the combine stage through a new, lookup-based method, which gave me on my crappy laptop instantly up to 5 fps. For the testscene demo I have now a total fps increase, compared to 0.52, of about 10 fps, which is quiet nice

Yeah, leave your time. Ssao is a big thing. Better release a stable version a bit later, then a buggy version too early. : ) I know, you're doing it right!

Thanks in fact, I would like to rush on this, but I still have to wait for a next beta and betas are rare these days... when the bug is fixed, the code is finished, then I have to test it, if it is still compatible to A7, and then I just have to write some pages for the manual and then it is finished. So, if JCL would release today a new beta and everything would work, I would approximate ~2 weeks and its done. So at the moment all depends on JCL.

SSAO 0.6 is now code complete. It is now 21% faster* (avg.) than v0.52. So cool.

Release is coming soon.

*Overhead in ms

That's great news HeelX. Can't wait to try it out.

It´s already released

What is missing to v1 except bug fixing?

Agh stupid me, Should've paid more attention to his sig.

Thanks

Please reply in the showcase thread to bring it up front

Hey ho,

If have got a little problem with your SSAO solution ):



The model gets black with a red outline...

I am not using any shaders, but the model is not closed (and done in realtime).


Anything I have missed?

Are you setting the normals properly? I saw your other shot and it didn't looked like that.

Ah, I don't think so [as I am not doing anything like that ;)]

(If you meant the colors from the other screenshot - that were different textures, which are correct)

You need proper normals for the model. They are used for the bilateral upscaling and smart blurring. I don't know exactly why you get always zero AO terms, but it could be related to it.

@Rei: You can create hard normals directly in the pixel shader like so: float3 hard_normal = normalize(cross(ddx(wPos),ddy(wPos))); You only need to pass the world position in the pixel shader. This should work fine for your case.

Hummel, today I really considered to use normals derived by the same exact method you mentioned instead of sampling the gouraud shaded ones, but as you already said, this leads to hard normals. But if I tweak the blur, it could work for the upscaling.

Question: if I bilinearily downsample the depth image and create worldspace normals from the downsampled perpixel depth values, do I get the same normals if I would have create the perpixel normals from the hires depth values which I would then have downsampled, too???

That would be great, because I could save lots of memory then (and processing time, pushing it down the very long throat of your videocard... gag!).

Nevertheless...

This doesn't work with my solution at the moment, because I don't offer the opportunity to deliver a custom normal map of the view

If you would re-normalize the downsampled normals they should be the same you would get when creating them from downsampled depth values. But I´m not 100% sure. It´s worth a try at least. But consider, in a post-processing step you´ll get wrong normals along 'sharp' edges if you dont handle that case separatly.

I know. For that I already use my upsampling stage. If the derivatives over my downsampled depths are producing correct normals as if I would have downsampled the correct normals from hires, I should get visually the same image then.

Hi, I wanted to ask if anyone is using my SSAO solution with an A7 project? Because I intend to drop A7 support.

Regards,
-Christian