SSR Post Filter

[neph1]

SSR Filter based on: https://github.com/riccardobl/SimpleSSRShader/
Some liberties taken when restructuring it.

Consider skipping testScene.j3o. Might just clutter an already cluttered testData project?

Some artifacts remain. Unsure which are due to SSR in general, the original shader and my implementation

[riccardobl]

Thanks for taking the time to adapt this to jme filters.

I see that you have replaced some macros with uniforms, if there is no specific reason for doing that, i suggest to switch them back (using the Defines { } block in j3md) because they are generally faster (no memory access) and allow compile time optimization.

Also, i made this patch at some point, that fixed some artifacts that were caused by wrong depth linearization riccardobl/SimpleSSRShader@f0e91a9 .

[neph1]

I replaced the macros to allow as much runtime tweaking as possible (since the filter probably needs to be adapter to different use cases). But performance is everything, so I switched back (and added even more macros for the blur pass). If anyone wants to tweak in runtime they'll need to reinit the materials to see the changes).

[neph1]

I noticed that the blur is meant to be run over several passes. I'll try to implement that as well

[neph1]

added new technique for rendering world normals + glossiness in pbrlighting

[neph1]

The current pre pass only uses vertex normals. Would it make sense to read the normal map if available? Or make that a HQ option? Or is it simply not worth the cost since the roughness map will take care of the details?

[riccardobl]

Yes, i think it should, otherwise the result won't be much different from the approximated normals.

[neph1]

All right, I think that's it? Thanks for reviewing this feature. The filter would have been crap otherwise.

[riccardobl]

Do you have a test scene that uses the PBRLighting?

[neph1]

Yeah. I removed the one i committed because a simple isnt really representative. So i've been testing with a scene from work which is complex.

…

On Fri, Aug 2, 2019, 14:57 Riccardo Balbo ***@***.***> wrote: Do you have a test scene that uses the PBRLighting? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1144?email_source=notifications&email_token=AB46MQWXDKJP7JRIE5NR3UTQCQVLBA5CNFSM4IC2R7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3NVFFI#issuecomment-517690005>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB46MQUHH7JMQBE2NEJUB5LQCQVLBANCNFSM4IC2R7BA> .

[neph1]

I noticed that approxNormals = false didn't work on the master branch, whereas it worked on my somewhat obsolete local branch. Some digging led to a difference in Instancing.glsllib
master:

vec3 TransformWorldNormal(vec3 normal) {
    return normalize(g_WorldNormalMatrix * normal);
}

mine:

vec3 TransformWorldNormal(vec3 normal) {
    return normalize((g_WorldMatrix * vec4(normal,0.0)).xyz);
}

the latter works just as expected, but the master version leads to the wrong perspective. PBRLighting and relevant shaders in effects are identical.

I've changed (not pushed) normal_gloss.vert to:
wNormal = normalize(TransformWorld(vec4(modelSpaceNormals, 1.0)).xyz);
rather than TransformWorldNormal. Convoluted, but works as expected now.

Thoughts?

I also noticed that the envmaps from a lightprobe doesn't really look that good together with SSR. The only thing I can think of is an option in the material to turn env maps off. I don't really like to propose changes to PBRLighting though Edit: It might only be on some special cases, like large flat surfaces, and it's not Edit: This was only in a special case, and not related to SSR, just ugly envmap

[riccardobl]

Mh, actually the master version should be the correct one... i've also noticed some pretty bad artifacts when you move the camera away, i'll have to take a look at this more carefully and maybe move the raytracing to screenspace while i'm at it. I hope it is not a problem if i keep this unmerged for a while until i have the time to look into it.

[neph1]

Any progress on this? Otherwise I suggest we merge it to avoid it rotting away. What's there works quite well on short to medium distances. Merging would allow anyone to refactor it in the future.

[AlrikG]

@riccardobl What artifacts? Can you take a screenshot?

[neph1]

FYI: I've pushed this to a separate repo: https://github.com/neph1/SsrFilter
Maybe that is a better way to move forward than pushing everything into master. Both from a maintainability and accessibility point of view.
Close?