Super-fast high-quality SSAO

This looks excellent, sign me up on the will buy list.

 

take our money

 

yeah ... can't wait to get my hands on it

 

If you throw this on the Asset Store for a competitive price, consider it as good as purchased. I can't use the built-in AO because it looks awful.

 

Any information when this will be released? I've been using the SENatural Bloom and Dirty Lens pack you released and it is amazing, can't wait to get my hands on this now.

 

@hippocoder - One reason to not have pre-baked AO would be in my case, where the additional file size from lightmaps and AO maps really bloats download size. By having everything dynamic, yes its a bit of a hit performance wise, but the benefits of the slimmer download totally warrent it.

@sonicether - Would it be possible, to only have the AO effect where there are shadows? That's my biggest gripe with the AO effects is the goal of them is to simulate a very crude bounced light effect, and darkening the edges in direct sunlight doesn't make any sense. Is this sort of thing possible? Can you read shadow info into a buffer and use it to mask out all the areas that are in direct light?

 

well - as far as I know he did implement this in one of the latest builds so yeah - it should work exactly like that

 

Oh sweet, that would be awesome

 

Hey SonicEther-
Any updates on when the release could be? Itching to put this in our game.

 

as far as I know - soon

 

This looks fantastic...

 

it really does, doesn't it?

 

Truly...

 

and all the additional stuff (other than just an awesome-looking ssao, that is) only makes me want to try it out RIGHT NOW!! especially that colour blending, damn ...

 

@RB_lashman:
Reading this thread gives me the strong feeling that you and the creator of the plugin is the same person.....

 

Funny!

I read the rea posted about how naughty dogs did with their AO solution. I think it is a very optimized solution.

Scene Unity 5 standard material included the object based AO map, Artist can easy apply it to the model material itself for physically based shading. If the image based AO apply again to the model that already has AO map applied, it duplicated the same effects and it is not necessary.

Lets say there have a box lays on top of the plane, AO affects only the contact area, but not the model itself. Or as the rea mention in earlier post, AO affects only the dynamic objects with static objects (Not static with static objects). So if there have a option that only has the AO effects between those models that will be great.

 

sorry to disappoint you detective, but ... nope

 

Can I bug ya for another update and/or screenshot? I'm definitely looking forward to this asset. I pretty much use SENBDL religiously. Your stuff is top notch.

 

When is this coming out. I want it!

 

It's not the first time I meet that statement. And I can't understand why do you guys say it. You do an image effect, so you got PRO -> RTT, that means you can do ANITHING. You can render albedo to screen-size rt, and use it later. Since you are already using depth texture, it's not difficult to blend albedo whith screenspace shadow buffer after all. You can even make your own deferred rendering. So I don't get "unavailable" in that context.

 

You can generate it at startup then.
The fastest ssao approach i've seen so far is the combination of pre-baked self-occlusion and dynamic object-object ao. It uses a special buffer for determining which pixels needs to be processed, generated before ssao step.

 

Which requires re-rendering the ENTIRE scene once again, which could severely impact performance. Whereas in Unity 5, all G-buffers are generated in one go with a shader that writes to multiple render targets.

 

Any luck to have SSAO with a temporal filter like in Battlefield3+ ? To have a good cover for a waving grass?

 

Sure! Here's what's been going on.

I've been diving into optimization lately. For more simple geometric scenes, an approximation can be enabled with no noticeable artifacts. I'll show a comparison between no SSAO, and my SSAO with color bleeding and that optimization enabled.


Here's no SSAO, just for reference.


Here's with my SSAO and color bleeding. With the optimization enabled, the effect is running at a very speedy 2.8 ms. Of course, this scene is in Unity 5 with realtime GI enabled. Since realtime GI doesn't capture high frequency details, SSAO really helps to finalize the look. Check out that color bleeding too!

I'd like to finish this before the end of the month. I think the algorithm itself is nearing completion. Writing documentation, ironing out any possible bugs that may show themselves during testing, and setting up the UI will be the most time-consuming obstacles to overcome before this is released.

Like PhobicGunner mentioned, without writing a new deferred rendering pipeline, getting scene albedo would require another render of the scene geometry. That's just not an option, for performance reasons. Sure, I could write my own deferred rendering pipeline (which I have before), but that would render almost every other graphics-related asset completely incompatible and useless to anyone who is using this asset.

 

Isn't Albedo available in Unity 5's g-Buffer by default though?

 

Yes, I was referring to Unity 4.

 

Which part? Not necessarily. By the way, you can also use mrt. What kind of magic Unity casts, when you switch to deferred (except for a slightly different lights processing algorithm)? Which part of it you can not re-create / change? The only restriction, as sonicether pointed out, is the loss of compatibility with other assets from the store. But here you need to find a balance between flexibility and speed.
And don't forget that it is a multiplatform engine, and many features are emulated on platforms that does not support them. Take at least a camera's depth texture for example. If OP uses it in forward renderer (obviously he is), then he already "re-renders the ENTIRE scene once again" for _CameraDepthNormalsTexture on almost all platforms (you can check it out with the profiler, this step called UpdateDepthTexture or UpdateDepthNormalsTexture there).
And what magic happens in 5, which you can not recreate in 4? I'm not talking about enlighten now. A slightly different g-buffer? Ubershader? Platforms aren't changed, their posibilities are the same since 4. Demos and screenshots are more beautiful than it was in 4, I must agree with that. The more interesting part for me begins with an internal multitasking functionality, but it is not directly related to the graphics pipeline.

 

Perhaps it's been fixed since I last checked with Unity 4.5, but MRT does not work with the deferred lighting pipeline. That makes the whole matter of getting any additional information from the scene while keeping most of the rendering system the same impossible. Even if it were possible, it would lock the user into using specific shaders that provided the right information via MRT. Again, a custom deferred renderer is the only way to go there, and with Unity 5 being on the horizon with native deferred rendering, I feel it'd be best to wait. I just don't think that most people would be interested in an asset that is completely incompatible with most other graphics assets. What magic happens with Unity 5? Native functionality that everyone has access to, which means full compatibility for combining assets that need additional gbuffer information.

And no, I'm not using the forward renderer for most of development or for any of my screenshots. What makes you think I am?

 

Oh, my mistake, you're talking about compatibility, so I thought that you mean different platforms as well. Including those which does not support the mrt or refuse deferred for whatever their reasons (low fillrate, for example).

What do you mean by "native"? Will Unity 5 work on platforms without mrt (or if i don't want deferred rendering at all)? Does v5 native more native than v4 native?

 

I'm not interested in people shuffling around on old slower 4.6. Any asset that gimps itself to be compatible with the past is off my radar

This doesn't appear the case here, so I'm watching to see how it develops.

 

yeah - Sonic is really good at staying current with all the new awesome stuff out there so I'm definitely not worried about that plus - we already know it looks freaking amazing ... and 2.8ms? CRAZY!!

 

2.8ms is high for ps4, but would have to test first of course. One needs to combine post fx where possible for it to really shine, for instance, I bought SE natural bloom recently but find myself wanting the Unity version because it has lensflare support.

 

that might be true ... but then again - Unity's built-in ssao takes 3 times longer to render

 

You've proven that your SSAO looks A LOT better than the built in one, but I'd like to see a comparison for speed.

In the first comparison you are comparing it to the highest built-in SSAO settings, which is very slow.

I'd like to see a comparison with more sensible settings. As hippo said, 2.8ms is kinda high (it's like 15% of the total processing time if you want 60fps) and I wouldn't want to spend so much on SSAO (I don't value it that much as an effect I guess).

 

If it works well on mobile then I would definately buy it.

 

Don't know why you would even ask that sort of thing, most mobiles on the market don't even have native depth texture support, let alone the power to run SSAO at a decent speed.

 

2.8 ms was the speed it was running at pretty much maximal quality. It can definitely be tuned down to run faster. My comparisons really have been to compare maximal image quality settings for both Unity's SSAO and my SSAO. For reference, Unity's SSAO at default settings except for downsampling being set to 1 runs at 3.8 ms in the same test scene.

Downsampling is certainly something I will include as an option. With downsampling, the effect renders in 1.8 ms. Downsampling dulls some of the high-frequency details in the effect, but it may be a viable option for some scenes. It definitely doesn't look bad. For games that aim for a cleaner look that rely much more heavily on lighting nuances, I'd say it'd be justifiable to spend ~2.8 ms on an effect like this, but for games that have a lot of texture detail, the loss of high-frequency details will be negligible. The user will be able to make this choice for themselves.


Here's what the effect looks like with 2x downsampling. Again, the effect is rendered here at 1.8 ms. 1.5 ms if you don't want color bleeding.

 

Thanks. I'll definitely keep an eye on this asset.

Also, I definitely want the color bleeding. I don't normally really like how SSAO looks, but your color bleeding brings something very pleasant to the scenes.

 

Funny, i prefer the '1.8ms rendering'
and +1 for the color blending. It's an incredible option.

 

I just want to stop talking about it and start using it

 

The keyword here is 'most' and mobile processing power is at a point where it will soon be possible to start running post process effects such as SSAO. And if we can get the author to optimise his SSAO to a point where we can start using it on mobile device, then why not?

 

likewise hurry up, Sonic!!

 

I don't really like to compare two assets here, but with SSAO Pro, I'm having around 0.8 ms at most complex scenery.
Will there be an option to disable features like color bleeding? Some things I won't need and I would prefer not to spend process power for them.

 

Isn't SSAO independent from scene complexity but dependent on screen resolution?

 

That's correct. Though, the cost of the effect increases as the sampling radius increases in screen-space. This means that if the SSAO algorithm is using a constant world-space radius, slowdowns can be expected when there is really close geometry in view. I'll implement a screen-space radius limit to reduce this slowdown.

 

So the complexity of the depth buffer impact performance? there is a loop inside the shader?

 

Might be worth adding branches since some gpus handle them quite well for a valid speed boost (optionally)

 

Yes, there is a loop. No, the complexity of the depth buffer does not affect performance. With constant world-space radius, closer surfaces will cause the shader to take farther samples from the depth buffer. This is a limitation of all world-space constant SSAO shaders and is unavoidable.

Dynamic branching does not work with texture lookups, so it's not an option, sadly.

 

Hurry up and get it out. Also, what ideas do you have for anamorphic lensflares or glittering like yebis? Not sure if you've considered it but your bloom is a little lacking in those. I'd be interested in either an upgrade to it or paying for something like that - just general feedback

 

This looks great! The effect looks more like SSDO (screen space directional occlusion) than SSAO to me. Any options for controlling the color saturation (or a color value multiplier you've mentioned before) combined with the color blending would be nice! (I think in the last two examples it would look better if the orange AO tint would be less intense, and maybe darker to give it more of a 'shadow' feel.) Will this be sold through the asset store? I'd love to use it