My next pathetic attempt with shadows - help

FrozenShade · October 20, 2014, 8:28pm

Is that my fault again or there is something very bad with the engine itself?

http://s10.postimg.org/adzxet709/3ddu22.png

1st thing: note the areas marked on red. There are strange shadow artifacts. The grate, the doorpost and the pillar are three different objects, on all of them we can see that bad effect. It’s on both, my own material definition and standard Lighting.j3md. I was trying with different edge filtering mode and shadow compare mode settings. My own material definition have different PolyOffset than the default lighting.j3md but it does not matter and artifacts are exactly the same.

2nd thing: yellow arrows points at different ‘light distribution’. The point light source is close to the wall, but the wall is the darkest object here.

I have tangents, normals, etc. Checked it twice just to not waste your time. It must be something different.
If it needs any shader modification then please, point me where to look at.
Is this engine usable for someone who is not the master in shaders?

Or… is there any shader’s master who might want to write some code? Nothing versatile, we just need few customs and some basic things working well.

nehon · October 20, 2014, 8:37pm

1 looks very weird. Sure that’s a shadow artifact? I mean it does get away when you switch shadows off, right?
2 looks like your wall is a “cube”, light distribution is compute to vertices so it can look weird on very low poly objects when the light source is close. Try to subdivide your wall

FrozenShade · October 20, 2014, 8:53pm

right, with ShadowMode.Off there is no such effect.
The ceiling is made of many same objects optimized by GeometryBatchFactory. So we have there a big, flat surface. The walls are made the same way, but there is no upper or lower level, so they are not extended on that dimension.
The wall model with increased poly count: http://postimg.org/image/677lew2h5/
It is better but still it is dark at the edges (it should not looks like that).

nehon · October 20, 2014, 9:10pm

Well it’s hard to tell just looking at the picture. could be z fighting issue or memory trash. what kind of shadow processor do you use? the renderer, the filter? Is that a Pointlight shadow processor?

FrozenShade · October 20, 2014, 9:22pm

It’s my own modified shadow renderer, just to pass nearest lights into post shadow, so shadows can be lighten up with other light. All lights are pointlights.
Here is the screen of the scene with default PointLightShadowRenderer: http://s18.postimg.org/o1u5j92rd/3ddu24.png
Note the influence of the second light. Removing that light does not change anything.

EDIT: providing correct link

EDIT2: Is that possible to ‘just’ calculate the distance between fragment an light source and with that to light up the fragment? I’m trying to understand the .frag code, but so far I found that it’s a bit too complex.

FrozenShade · October 21, 2014, 12:22am

I did some research. Check these screens: http://postimg.org/image/odwtyhqbz/

Here we have the point light moving from the left to the right. The value at the bottom of the screen means the light’s position. Wall is at 10, 11 means the middle of the corridor.
We can see that if the light is near the wall it can’t light it up in proper way. Moving the light to the center of the corridor slowly fixes the bug. So, it seems that there is a ‘required distance’ between the surface and the light. But why?
Also notice the shadow artifacts appearing on the grate door. On the last image the ‘shadowy thing’ appears on the whole doorpost.

Definitely I need an assistance with this, it seems that we have a ugly bug somewhere.

I also played with the #define ATTENUATION in Lighting.vert. Removing that line effects in lighting up the whole room… except the left wall! I think that this screen is important: http://postimg.org/image/afyihnd0l/

pspeed · October 21, 2014, 12:59am

@FrozenShade said: We can see that if the light is near the wall it can't light it up in proper way. Moving the light to the center of the corridor slowly fixes the bug. So, it seems that there is a 'required distance' between the surface and the light. But why?

Because there aren’t enough triangles to interpolate properly. I think if you show the wire frame of the mesh it will be quite obvious that the wall has almost no triangles. And it’s more than distance that has to be calculated if you wanted to move the calculation into the fragment shader, you’d have to recalculate the angle to every point (view angle and light angle). It’s way better just to have more triangles, really.

FrozenShade · October 21, 2014, 1:03am

Thank you, I’ll ask my team member to do even more triangles there. Never thought that flat surfaces need many triangles. I’ll provide the screen tomorrow.

nehon · October 21, 2014, 5:34am

For the shadow issue, I’d need a test case.
Something crossed my mind though, what happens if you move your light closer to the gate?

winhelp · October 21, 2014, 9:03am

Hi. I make models for this game. Maybe this screenshots can help you. As I see low-poly meshes are not our problem (no matter if the walls are connected or not - vertex normals).

http://s23.postimg.org/6lw2x2grv/attachment46.png

http://s27.postimg.org/418sbr74z/attachment49.png

FrozenShade · October 21, 2014, 12:48pm

@nehon
http://postimg.org/image/bgu3bzyvz/ here you have few screens with the light in different distances to the gate. Bottom line, second value means light position in proper axis. Gate is at 8.0, the light is moving away from the gate.

nehon · October 21, 2014, 3:04pm

Ok so that’s definitely zfighting…
You can try to play with the polygon offset.
I’m gonna try to reproduce the issue and see if I can find something.

FrozenShade · October 21, 2014, 3:18pm

Do you need our gate model? Maybe it is so specific that it would help you?
http://www.speedyshare.com/WgUrP/Door.rar
Just change the first line in the j3m file.

Changing poly offset does not take any effect.

FrozenShade · October 21, 2014, 7:43pm

After reading some book I learned some pretty obvious things about light calculation (normal, light direction, dot function etc…).
So, i started to play with these things, here are results: http://postimg.org/image/ai5rbwyd1/
It is far from perfection but a bit close to the effect that I want to have.

My ugly solution looks like that: (in lightComputeDiffuse, Lighting.frag)


		//return max(0.0, dot(norm, lightdir));
		float val = max(0.0, dot(norm, lightdir));
		return (0.45 * val) + 0.50;

pspeed · October 21, 2014, 9:00pm

@FrozenShade said: After reading some book I learned some pretty obvious things about light calculation (normal, light direction, dot function etc...). So, i started to play with these things, here are results: http://postimg.org/image/ai5rbwyd1/ It is far from perfection but a bit close to the effect that I want to have.
My ugly solution looks like that: (in lightComputeDiffuse, Lighting.frag)
		//return max(0.0, dot(norm, lightdir));
		float val = max(0.0, dot(norm, lightdir));
		return (0.45 * val) + 0.50;

Seems you could get a similar effect just be ramping up the ambient. You are effectively making it so that there aren’t any dark shadows ever.

While you are reading, you should read about what happens to vec3 varyings as they interpolate over a figure and try to guess what happens when the vectors are nearly 180 degrees apart from one another (as they would be for the light dir for a very large untesselated surface with a light very close to it).

Again, try turning wireframe=true on for your material and posting a picture of that. Given your results, I think your wall is two giant triangles. Your graphics card can eat up triangles like nothing… especially as compared to what it would take to fix this issue in the .frag (per pixel) shader.

FrozenShade · October 21, 2014, 9:24pm

The ambient will light up the whole scene which I don’t want. Check the second image from my previous post (torchlight only) - I can still use point light’s range. Here the ATTENUATION factor still takes place, which will not occurs with the ambient.

Lets see the wireframes then: http://postimg.org/image/go1y5e70z/
As my team member wrote before ( http://hub.jmonkeyengine.org/forum/topic/my-next-pathetic-attempt-with-shadows-help/page/2/#post-298295 ) more triangles are not helping. As far as I understand it is caused by the angle between wall’s normal and light direction vector. But of course I’ll continue my research.

pspeed · October 21, 2014, 9:40pm

So, actually… what do you think is wrong with this picture?:
http://s23.postimg.org/6lw2x2grv/attachment46.png

FrozenShade · October 21, 2014, 9:49pm

I don’t know. There are normals, there are many triangles (squares in blender)… Of course I’m using different model now, this one was only for test purpose.
EDIT: as far as I know the picture was taken with both light sources, torch and that one on the wall.

pspeed · October 21, 2014, 9:56pm

@FrozenShade said: I don't know. There are normals, there are many triangles (squares in blender).... Of course I'm using different model now, this one was only for test purpose. EDIT: as far as I know the picture was taken with both light sources, torch and that one on the wall.

I mean visually what do you think is wrong with it because without ray tracing the ambient light bouncing off the ceiling, it looks right to me. With the light source close to the wall, the ceiling directly faces the light and is in range and so will be brighter then the wall near the ceiling. This happens in real life also if the surface doesn’t reflect much light.

pspeed · October 21, 2014, 9:58pm

And if that’s the effect you are trying to avoid then yes, your angle clamping hack is probably the only feasible way around it.