No no no, switching to another game engine is a last resort.
Another game engine might have just more advanced shadow solution…
I meant that some other engine may have volumetric shadows or deferred rendering, I'm aware that some issues are just common to some solution, but I'm sure that many of them can be removed by individual approach or customization. My game's world is specific, and my current modifications looks nice in dark corridors, but I'm sure that in different environment the scene will be ugly. All I need to do now is to 'tune up' the engine by modifying its settings/code to fit my needs, and of course to not have artifacts. Things just does not looks good on defaults...
I’m curious where the whole magic is done, I mean how the shader knows that it should check the shadowmap to render the dark pixel. Where, how it distinguishes between the surface that casts the shadow and the one which should receive it. Because, with the doorpost for example, it renders dark pixels where it should not do that. Where (which line of code) the z-fighting occurs?
I know the theory of shadow mapping, I saw the drawings, schemes etc. But so far I'm unable to find it in the code, things in books/tutorials and the code in JME's shaders looks different. I just don't see the place where the things mentioned above are done. Witch such knowledge maybe I'll be able to customize it again, to make it working only in grid environment, with lights of constant range and determined distances between objects etc.
Your original PolyOffset settings are probably set to meet most common needs, but there are already questions about that, people needs to tune it up for their individual needs. Again, I don’t want to blame JME, just looking for the explanation and helpful hand.
I think that the great idea is to make some kind of ‘guide’ through the JME’s shadows. And to tell ‘what’, ‘where’, ‘why’…
I know Google, but, as I said before, things looks completely different in guides and in JME’s code. Call me noob, but the shader’s codes are, for me, hard to understand.
I meant that some other engine may have volumetric shadows or deferred rendering
Well volumetric shadows come with their share of cons and corner cases too... And deferred rendering add absolutely no benefit to shadows. One of the things you'll read a lot about deferred is "and shadow mapping just work the same as in you forward rendering process".
I'm aware that some issues are just common to some solution, but I'm sure that many of them can be removed by individual approach or customization. My game's world is specific, and my current modifications looks nice in dark corridors, but I'm sure that in different environment the scene will be ugly. All I need to do now is to 'tune up' the engine by modifying its settings/code to fit my needs, and of course to not have artifacts. Things just does not looks good on defaults...
So you do understand that we cannot have a general purpose solution that fits every single need users may have, right?
Your original PolyOffset settings are probably set to meet most common needs, but there are already questions about that, people needs to tune it up for their individual needs. Again, I don't want to blame JME, just looking for the explanation and helpful hand.
I think that the great idea is to make some kind of 'guide' through the JME's shadows. And to tell 'what', 'where', 'why'...
I know Google, but, as I said before, things looks completely different in guides and in JME's code. Call me noob, but the shader's codes are, for me, hard to understand.
I considered adding an accessor for the poly offset in the shadow renderer to allow easy tweaking of the value. I didn't for several reasons :
1. I don't completely get what's it's doing. Or to be exact, I do, but I can't figure what scale the values should have. What I know is that it offsets the polygons toward the camera when rendering the shadow map to avoid having z-fighting when rendering shadows. the first number tells how much the polygon is offset and the second...is some kind of factor that tells how much the offset should decrease when the angle from the camera become steeper...
2. Those values are very sensitive as you discovered, I had a hard time finding a proper value that works in general and it seems it's not working in your case.
About the guides, I made several posts, but I guess I should have made more wiki pages.
In my opinion, such accessor is a good idea. There is still a possibility to tweak these values manually, in files, but having an access allow to have live view of the differences.
Yesterday I spend about an hour to find poly offset values that fits for my needs. Of course I’m aware that when adding new things to the 3d scene I have to verify those settings again.
And really, if you have time you should make that pages.
The shadow only screenshots shows that some areas are properly shadowed while some have weird noise on them.
The noise is there because of the FrontFace culling used to find shadowed areas (Using Back face culling doesn’t help unfortunatly because then you’ll have the same issues on lit surfaces which is even worse looking), basically the information in the shadow map is saying that the shadow begins at almost exactly the walls position and because the depth information in the shadow map isn’t that precise it says that parts are in shadow and others aren’t creating those patterns.
But it is also visible that some areas are covered in perfect shadow for example in my second shadow only screenshot the areas of the wall that are correctly shadowed are shadowed because of a column piece thats casting its shadow there.
Now my solution to this problem would be to add a second wall around your walls example in Blender:
Unfortunately my current shader’s knowledge is far from yours, so I only understand the idea you wrote in your first post, but, so far, I’m unable to write it on my own. It precludes the use of your solution and the formula: float shadow = min(shadow(),nDotL*attenuation); because I don’t have nDotL and attenuation there. So far I reduces every noise by setting the PolyOffset values, but I’m curious of your solution. Is it somewhere on git/svn to download and learn from it?
mhh so to sum it up :
You render the shadows during the lighting pass, right? no additional pass for the shadows?
Then you attenuate the shadow value with the light attenuation, and…you have thicker walls, right?
Ok i have created a project with an implementation based on jME’s default lighting and shadow materials(I only tested PointLights):
The only tricky thing about it is that you can’t add your light to the rootNode like you usually would, you’ll just set the light to the ShadowRenderer. (normal lights that don’t cast shadows are still added to the rootNode)
The material definition file is just lightning.j3md with the post material switched with my shadow material(and the necessary Material Parameters) and BlendMode changed to Additive.
The fragment and vertex shader files are just PostShadow15 and Lighting combined (I did mostly copy PostShadow15 into the Lighting shaders and made a few adjustments)
Looks like I just need to have that latest version. The shader is not working on 3.0. Even moving the missing Instancing.glsllib into my assets is not helping, there must be something deeper. I’ll try with latest version.
EDIT: Ok, what now? It won’t open as a project. I have all on disk, switched in Git to ‘master’ but neither JME’s SDK, nor Eclipse does not know what to do with that. http://postimg.org/image/pe4vdhla1/
Version 3.0 have ant build scripts, here is just nothing.
EDIT2: Ok, found that gradlew.bat file. Now I have this one: http://postimg.org/image/eqb9qg149/
I got an dialog with several demos. Saw only the JME initial screen, after clicking the continue the errors on console appears. Now I closed that dialog and… so far nothing happened, just waiting…
@Perjin Simple question - is it possible to downgrade your method to the version 3.0 of JME? I want to make the same trick as you did, step by step, learning from your code but using my version. So far after copy-paste of lighting vert/frag into proper PostShadow files I’m getting error on .frag file.
I noticed that difference in LightPos vector and I’m passing radius in LightRadius parameter.
@nehon I’m aware that trunks are always unstable, but I wanted at least to run it. As I said to Perjin, I’m trying to do the same in 3.0. Unfortunatelly, his code uses things that I found only in latest, unstable version.
EDIT: Ok, I have vert able to compile. I’m almost sure that in 3.0 the LightPos is vec3, not vec4. I changed that in j3md and vert, passing additional float parameter which contains 1f/light.getRadius().
Now I’m working on frag. By the way, I was so close with vert
Funny thing - seeing your code I can say that some time ago I was trying to do something similar. Of course I failed, because my idea was to move PostShadow into Lighting. Now, after few weeks I can only say that it was stupid
Since .vert is ok now, I started to work on .frag and found a problem.
Importing Optics.glsllib causes an shader compilation error. I traced it by commenting all lines in your code.
To be more accurate this line: return textureCube(envMap, dir); of Optics.glsllib causes an error. My materials does not uses sphere maps. I don’t know what to thing about it…
The compile error should have told you exactly what line it happened on and the log should have included an entire dump of the expanded shader. Commenting out things line by line shouldn’t really be necessary until the issue has at least been narrowed down.
I will assume that you didn’t comment out any #ifdef’s that might have otherwise skipped that particular line if you weren’t doing env mapping… but I also hate to assume.
The compile error should have told you exactly what line it happened on and the log should have included an entire dump of the expanded shader.
Ok, I understand. Damn, every time there is a compile error, I just stop the application. Now, after resume I see the additional information. It is so simple to trace bugs now
com.jme3.renderer.RendererException: compile error in:ShaderSource[name=MatDefs/Shadow/PostShadow15Pretty.frag, defines, type=Fragment, language=GLSL150] error:0(95) : warning C7508: extension NV_shadow_samplers_cube not supported
0(127) : error C7533: global function textureCube is deprecated after version 120
Ok, deprecated function. But Lighting.frag imports the same file Common/ShaderLib/Optics.glsllib and there is no error.
I see that Optics_GetEnvColor is used only when USE_REFLECTION is defined, so I’ll brace that import using proper #ifdef/#endif