@oxplay2 said: @t0neg0d:
huh... changing to "*0.005" or "200.0" and later to "*0.01" or "100.0" give no result... no ssao appearance...
Will update the int/float issue. I try not to do this, but it is an issue that doesn't throw errors under windows, so I miss it sometimes.
@oxplay2 said:
you should really make repository ;) if there would be, then i could tell you which update made issue.
If I was any sort of decent developer >.<
@oxplay2 said:
on lower fps there is weird artifact(only with smooth set on)
Yeah.. the method of blurring generates noise that is static to the screen. Lower FPS will really make this stand out unfortunately. But, it is the fastest method I could come up with that produced decent looking results.
As for the toggleSSAO, I added that for debugging. What isn't working with it?
@oxplay2 said: @t0neg0d:
last JME nightly update need postQueue method updated.
I'm not using nightly... can you explain the issue?
Filter postQueue method now takes a
RenderQueue as parameter like
SceneProcessor instead of the
RenderManager and ViewPort.
Filters that were using those attributes
now properly keep a reference on them in
the filterInit method.
HAH!!! I know exactly why this changed ( @nehon )! I was grumbling about how to work around this issue (to myself) when trying to implement an idea just a little while ago. Um… I’m not completely sure what the changes will be to this filter, but I bet this broke a LOT of older contributions Glad this is changing though!! I’ll post the update once I’ve had a chance to look at how this effected other Filters I’ve written in general.
Thanks for the notification. I’m thinking I best start using nightly, so I can fix these issues as they come up.
Ok... grab the updated filter class. It's the only thing that has changed. In case you are using any other filters that have this issue, here is what to do:
Seeing as none of the Filters that exist already would be utilizing RenderQueue... the only possible thing that could go wrong with doing the above would be the references to vp instead of viewPort.
Pretty excited about this change... I wanted to try out post filter shadow blending to see if it would help improve a shadows look (this would still use blending from the lights perspective, but hopefully help with the final effect). Anyways... off to try this and then back to finishing up that Sky Dome.
@t0neg0d said:
Pretty excited about this change... I wanted to try out post filter shadow blending to see if it would help improve a shadows look (this would still use blending from the lights perspective, but hopefully help with the final effect). Anyways... off to try this and then back to finishing up that Sky Dome.
Actually i made this change exactly for this :p
I'm gonna commit a post shadow filter soon, so you can experiment with additional convolution.
I knew it would break some contributions, but, there is not that much filters that use this method....except SSAO :p
@nehon said:
Actually i made this change exactly for this :p
I'm gonna commit a post shadow filter soon, so you can experiment with additional convolution.
I knew it would break some contributions, but, there is not that much filters that use this method....except SSAO :p
Will you commit this SSAO filter to the JME0Filters? Or i should add it to shaderBlow?
I don’t know yet, i have to review it, test it and so on.
I don’t think it will be committed as is, i’ll probably use this contribution to the current one faster and make random sampling and convolution optional.
@nehon said:
I don't know yet, i have to review it, test it and so on.
I don't think it will be committed as is, i'll probably use this contribution to the current one faster and make random sampling and convolution optional.
Ok, i get you.. I'll wait for your decision for a while.
Glad this is changing though!! I’ll post the update once I’ve had a chance to look at how this effected other Filters I’ve written in general.