So, in a very round about way, I decided to post this as a plugin in the next day or two.
How did this come to be? Well, I was playing around with the SkyDome thingy I made… updating it a bit and the test project I had was using this as well. Soooo… I used my GUI library to create a control panel for the SSAO Filter and see what it was capable of… and I was actually pretty suprised, as it allowed my to try settings I wouldn’t have thought of trying otherwise.
I thought I would post quick vid of the results, mention that I was going to post this as a plugin and also drop the control panel code here for anyone who wanted to play with it after it is released.
Most importantly, the reflection lookup happens along the X, Y and Z axis instead of just X and Y.
The convolution filter in the current SSAO is VERY expensive… event using x2 on the blur filter in this will give you half the FPS impact of the current SSAO filter
You can use either a single pass for SSAO, or a secondary pass for adding detail back into the wide-area pass.
It has a falloff function that allows you to blend it seamlessly with other depth-based filters like fog. This also discards pixels and increases framerate.
There are a few other differences, but these are the most important.
Not saying that this filter is by any means perfect, but it can be used with lower-end hardware where the current one can not.
@t0neg0d said:
Most importantly, the reflection lookup happens along the X, Y and Z axis instead of just X and Y.
The convolution filter in the current SSAO is VERY expensive... event using x2 on the blur filter in this will give you half the FPS impact of the current SSAO filter
You can use either a single pass for SSAO, or a secondary pass for adding detail back into the wide-area pass.
It has a falloff function that allows you to blend it seamlessly with other depth-based filters like fog. This also discards pixels and increases framerate.
There are a few other differences, but these are the most important.
Not saying that this filter is by any means perfect, but it can be used with lower-end hardware where the current one can not.
No, I mean the visual editing, not your SSAO code.
@normen said:
No, I mean the visual editing, not your SSAO code.
Actually, I didn’t realize that the SDK allowed for editing custom filters this way. Though, I had other motives for hooking this up through my GUI library. It gives me a chance to test that at the same time. For instance, I found something while doing this that I probably wouldn’t have noticed otherwise (altering the font size of a dropdown list to match the defined font size of the owner, in this case).
You can’t really hook custom filter right away .Right now you can only edit stock Filters (as far i remember, I can be wrong)
Maybe we could add this feature, so home brewed filters could be edited in the sdk.
About your SSAO it’s been a long time since we spoke about it, and I never took the time to look into it in the end, I’m sorry. I admit from this video it looks very good.
About FogFilter, more than never it’s gonna be deprecated, now that we have a real solution to put it in the lighting material. So there will be no way around your falloff system, because SSAO will be renderer after fog.
@zarch Filter’s shaders can use ShaderNodes as any other material now, but the use of it is less obvious than with the “classic” materials. Filters are already kind of modular.
@nehon said:
You can't really hook custom filter right away .Right now you can only edit stock Filters (as far i remember, I can be wrong)
Maybe we could add this feature, so home brewed filters could be edited in the sdk.
About your SSAO it’s been a long time since we spoke about it, and I never took the time to look into it in the end, I’m sorry. I admit from this video it looks very good.
About FogFilter, more than never it’s gonna be deprecated, now that we have a real solution to put it in the lighting material. So there will be no way around your falloff system, because SSAO will be renderer after fog.
@zarch Filter’s shaders can use ShaderNodes as any other material now, but the use of it is less obvious than with the “classic” materials. Filters are already kind of modular.
This is all sorts of exciting news!
Fog is becoming a shader based solution?
Will there be a way to exclude the sky bucket? The reason I ask, is I would like to ditch my FogFilter from the skydome thingy I made.
I’ll drop the SSAO filter out there for now… but I always assumed that it would only be useful temporarily as you had said that the filter was eventually going to be rewritten. There are a couple useful ideas in this one, but I have a feeling you’ll find better approaches than I did to implement these.
I think fog would and should be material based. So some objects in your scene would have it and some not. For example, in Mythruna, none of my lights have fog. So the sky would have a material without the fog node.
@t0neg0d said:
Fog is becoming a shader based solution?
Will there be a way to exclude the sky bucket? The reason I ask, is I would like to ditch my FogFilter from the skydome thingy I made.
Fog is usually applied in the frag shader of all materials, but until very recently there was no good way to inject the fog code into every shader..
If I got this shader node thingy correctly the solution for the sky would be to not add a Fog node to the sky matdef.
@kwando said:
Fog is usually applied in the frag shader of all materials, but until very recently there was no good way to inject the fog code into every shader..
If I got this shader node thingy correctly the solution for the sky would be to not add a Fog node to the sky matdef.
I kept bouncing back and forth between shader based and filter based fog in my game. They definitely render slightly different from each other and both had their benefits.
Personally, I liked being able to manage what used/didn’t use fog on the material level, so this is really cool.
@nehon
Since fog will now be shader based, any chance that we will be able to choose the type of fog we implement? i.e. GLSL has three different methods of rendering fog: cam to distance, distance to infinity and linear.
@t0neg0d said:
I kept bouncing back and forth between shader based and filter based fog in my game. They definitely render slightly different from each other and both had their benefits.
Personally, I liked being able to manage what used/didn’t use fog on the material level, so this is really cool.
@nehon
Since fog will now be shader based, any chance that we will be able to choose the type of fog we implement? i.e. GLSL has three different methods of rendering fog: cam to distance, distance to infinity and linear.
It will be a shader node. So just implement a different shader node.
I can’t imagine the standard fog node being more than one or two lines of frag code.
@t0neg0d said:
This is all sorts of exciting news!
Fog is becoming a shader based solution?
Will there be a way to exclude the sky bucket? The reason I ask, is I would like to ditch my FogFilter from the skydome thingy I made.
I’ll drop the SSAO filter out there for now… but I always assumed that it would only be useful temporarily as you had said that the filter was eventually going to be rewritten. There are a couple useful ideas in this one, but I have a feeling you’ll find better approaches than I did to implement these.
What Paul says about the fog. Honestly that’s one of the main issue the hypothetical Shader Injection and now Shader Nodes are supposed to fix.
and about SSAO, I’m not sure the solution I want to implement will be faster than the current one. It will look a lot better though (hopefully), but one can prefer speed over prettiness. Also it’s been like 6 months since our last talk about it, and I did not touch this filter since then (except to fix an issue on mac). So my argument saying “I won’t make change on it because i want to re-implement it with another approach soon” is not valid anymore. I’ll do it eventually, but in the mean time…
Yours looks good. IMO it suffers of the same issue as mine,that I hate (the banding thing when the radius is high), but your convolution is better and somehow manage to attenuate it. Also if your SSAO is faster, as you claim, that’s even better.
@t0neg0d said:
Since fog will now be shader based, any chance that we will be able to choose the type of fog we implement? i.e. GLSL has three different methods of rendering fog: cam to distance, distance to infinity and linear.
We can have limitless features in the lighting shader now....no more "well..i would add it...but I'm afraid it will bloat the code". Maybe I'll have to buy a bigger screen though for that mat def to fit into it ;)
