Where are the dark lines in that screenshot? I am not sure what I am looking at …
http://s3.postimg.org/x0ojj7vur/3ddu35.png
On the upper part you can see dark lines (caused by the shadow of the grate). Some lines appears also on places where objects intersect each other. The last screen was just to show what happened with shadows in general, after my poor shadow’s cams manipulation, which absolutely had no effect on the dark line’s presence.
ok so I managed to have your project run…(I didn’t even knew about the import eclipse project). But when I run it I have a black screen…
Anyway I searched the source and tried to apply the polyoffset values you have to standard JME lighting shader. Here is the result.
Looks pretty much the same as your issue
Your values are off. You should keep standard values.
So I guess you’re back to issue number one, shadows are offset on rough edges. I’m afraid you’re gonna have to choose what issue is the worst.
Else you can try to dig what @Perjin said earlier in this thread.
Black screen? Are there any errors in the console? Do you have added a folder with assets to the project?
As I said before ( http://hub.jmonkeyengine.org/forum/topic/my-next-pathetic-attempt-with-shadows-help/page/2/#post-298278 ) I’ve tested it with my own material definition (modified PolyOffsets in both Pre and PostShadow) and the untouched Lighting.j3md
http://postimg.org/image/ygwz26nx5/
Here we have the doors switched to untouched Lighting.j3md. Setting the Lighting.j3md to every other material is not helping. There are still lines and a lot of dark noise on the flat surfaces. With the original PolyOffset values we have ugly vertical lines on the round columns.
As you can see on your own scene, there is a serious problem with the shadows in the engine. How to make anything that have shadows with such results?
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? Thousands of games that uses shadowmaps have it done correctly, something here must be wrong. Help me to understand the process (without giving me a link to the bookstore) and I’ll try to fix it on my own, because rewriting my code to c#/c++ and switching to another game engine is a last resort.
So far I found:
- the 2nd value of PreShadow’s PolyOffset reduces the dark noise
- using the original PostShadow’s PolyOffset values (-0.1 0) I still have dark lines
- using slightly modified (-0.01 0.1) PostShadow’s PolyOffset values removes almost all of these dark lines, there are only few sharp vertical lines on the round columns.
- using another set (-0.51 0.1) of PostShadow’s PolyOffset values, which were made to solve one previous issue, gives even more dark lines.
I’m sure that answering to questions from my previous post and testing what that magical PolyOffset really is, should bring us the solution to now and to future problems with shadows.
1 Like
Note: we didn’t invent this form of shadow implementation… we just implemented it for JME. You are likely to run into very similar issues with other engines. Just saying. Shadowing mapping in screen space like this is going to always have some tradeoffs. The best looking games have likely baked a lot of their lighting in ahead of time.
Another game engine might have just more advanced shadow solution…
Anyway, I’m still here, trying to do my best with JME, asking for more, more and more information. My math is weak, to fully understand the 3d graphics I should spent a year covered with books. I chose to learn on the current issues, writing my 2nd game at the same time.
Well I’d really be glad that someone actually does the comparison once and for all… I mean comparing JME shadows to other engines.
I’m not saying this so that you leave, I mean now that you have insight in how they perform in JME, it’d be interesting to know if you can achieve what you want with other engines.
The shadows we have are multi-purposed shadows that adapt to all light types (except maybe area lights that we don’t have them at all).
It implements state of the art shadow mapping and with no surprise exhibit the common issues that you’d have with shadow mapping. Also we have 5 types of edge filtering, ways to cut off z far for shadows with smooth transition.
This polygon offset issue is a common one, but usually people prefers the issue you posted in this thread
http://hub.jmonkeyengine.org/forum/topic/my-next-pathetic-attempt-with-shadows-help/#post-297534
rather than this one
http://hub.jmonkeyengine.org/forum/topic/my-next-pathetic-attempt-with-shadows-help/page/5/#post-298576
@FrozenShade said: As you can see on your own scene, there is a serious problem with the shadows in the engine. How to make anything that have shadows with such results?This just prove that shadows looks bad if I use your polygon offset values instead of the ones used in the engine. If you want to document on this issue, search for polygon offset, shadow mapping and shadow acne in google.
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.
@FrozenShade said: I meant that some other engine may have volumetric shadows or deferred renderingWell 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".
@FrozenShade said: 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?
@FrozenShade said: 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.
Yes, I understand.
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.
Ok I got curious and tried to make a very similar scene, since my game will have some dungeon like levels as well.
With my custom shaders (using the approach described in my previous post, polygon offset -1.0,0.0)
Ok that does look reasonable, but there is something wrong at the ceiling (the bright line above the gate).
So I went and got just the output of the shadow renderer, and it isn’t pretty:
now whats hiding those artifacts in my originial render is that I’m basically doing the following in my code:
float shadow = min(shadow(),nDotL*attenuation);
the output of that line looks like this:
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:
in JME:
I hope this helps you with your problem.
3 Likes
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)
A few Screenshots I made of it.
default:
pretty:
default:
pretty:
And one with three point lights, the blue one in front of the box doesn’t cast shadows.
3 Likes
Thank you. This is for sure much more advanced solution than the one I’m currently using. Now I have something to study 
I just made my own contribution here: http://hub.jmonkeyengine.org/forum/topic/how-to-have-shadows-influenced-by-many-lights/
This is the modification I’m using, maybe someone find it useful.
@Perjin I don’t know if I did something wrong but PointLightShadowRendererPretty is missing some code…
I have errors there:
plsr.setShadowZExtend(15);
plsr.setShadowZFadeLength(5);It’s not supported in 3.0
I added the code in last git, if you want to take a look
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…
NOooo. I didn’t say to switch to the git repo it’s highly unstable and may break your code.
I was just suggesting to look at the commit so you could adapt the code to your own shadow renderer.
1 Like