[BUG 1.1Beta1] Bad Terrain Shadowing (too much) - LOGGED

#1 @Steve, might be worth checking your scattersky settings, might be a few more options in there that need tweaking on 1.1b?

#2 That's odd, I've actually found the terrain shadowing to be far more accurate. Mountains produce shade where you would expect at the right times of day, shadows don't randomly appear on flat terrain where they shouldn't be and just overall it's all much improved(perhaps the shadows could be a little less dark to take into account ambient lighting, but then that is a simple settings tweak). Though this is with my own levels(Which definitely weren't shadowed right in 1.1a, don't remember 1.0.1). I've not paid much attention to newly created ones.

#3 That looks like its possibly broken in some way to me.

Are you getting any shadows on the terrain at all? Note i mean shadows... not just the back sides of terrain being ambient lit. Like at any angle does the player model cast shadows on to the ground?

#4

Quote:
Like at any angle does the player model cast shadows on to the ground?

Yes player model casts shadows, just not on a shadowed area - and if does, then it's shadow on shadow so you can't see it (actually I can see the player shadow casting into the edge of the terrain shadow before the overkill-terrain-shadow complete swallows it up into the ambient). Any/Every object casts shadows on the terrain fine -- but it seems the terrain is causing some form of self-shadowing-overkill upon itself (guess).

Please note: that my player is not affected by these "overkill" shadows on the terrain (model is in view of sun regardless of what overkill-terrain-shadow thinks)- but the player model is affected by "proper" terrain shadows, when the model is in a position from which it cannot see the sun (which is how it's supposed to be - and good fix from the alpha on this).

#5 After a quick play around - and I may be wrong on this ... it looks like the sun height is calculating shadows from a static position at the end of (let's call it plane) Z (if you think of the world as a cube), rather than from the actual position of the sun object.

So if I have a low number like 10 for height, terrain shadows seem pretty correct because the sun object isn't moving allow X, it's at the horizon rather than over the terrain.

Now, make that 80, and it will still cast a shadow like it's transmitting the light from Z, but has not moved over the terrain like the sunObject (the flare) has. This gives slight shadowing on every terrain square which is facing away from that side of the worldcube (even though they can all clearly draw a line to the sunflare above).

Move the height to 90, and it's directly overhead, the terrain doesn't cast shadows on itself (as expected).

But move it past 90 to say 110, and the problem starts again, but this time from the other side of the box, the other end of X, and shadowing starts to form on the other slopes, the other ones which are now facing away from the other side of plane Z.

........... and now I've confused myself so here's a terrible diagram of what I mean.

The light source is not following the sun track, it's stuck against the (for want of a better word) skybox.

9000 hours in M$ Paint, honest

#6 I think I get what you're saying, but I can't really see that this is happening in my tests. The shadow length vs angle from eye to peak seem to always line up with the sun, and that seems to suggest the lighting is correctly coming from the sun. In the screenshot you're showing, the light is hitting the upward slope at an angle such that it really shouldn't be very well lit, but the difference between versions is still a bit confusing.

Is it possible there have been some changes to the ScatterSky rendering which might result in a lower overall light level with identical settings? The entire shot appears somewhat darker, even the color of the horizon and the sun itself.

Also, I was wondering if HDR might play some roll. I was going to mess with it a bit, however apparently it and the other post-effect options are totally missing now. I assume they're going to be moved to some "advanced" sub-options panels. Neither of those shots look like they're using HDR, but I'm just trying to suggest possible causes. :P

It might help if you had a shot with the camera actually at real ground level, ie just slightly clipping through the ground, that way we could see what the angle is exactly. I can't tell exactly, but it looks like your camera is still a bit off the ground in those shots, and I still think it's possible that the lightness in the first shot was just the "missing shadows" bug, since the player shadow is totally invisible (was that bug introduced in 1.0.1? I jumped from b5 to 1.1a, never used 1.0.1).

I loaded up 2 identical levels in both 1.1a and 1.1b1, and couldn't see any difference (aside from 1 spot where a terrain-cast shadows was missing in 1.1a), so if there is a problem here, it was already introduced in the alpha.

#7 Shadows seem to check out for me, at the right sun height on the terrains.

#8 @Henry
FYI - HDR and the other postFX are currently only accessible from prefs until the devs decide how to link them up into Options menu.

Quote:(was that bug introduced in 1.0.1? I jumped from b5 to 1.1a, never used 1.0.1)

Kinda the reverse fro me, I never bothered with the alpha beyond testing the new editors for bug reports.

*boots up the alpha, makes a terrain, paints noise* - yes, same issue in the alpha, there are parts of the terrain which have a line-of-sight to the sun are in shadow.

Back to beta:



SunObject, higher this time at 45 (it was 25 before) and Black skybox, desert terrain for contrast. Top image, looks okay from the lit area, but move forward into the shadows, camera pierces the plane but manages to still view it, and there's a LOS to the sun, yet it's not lit.

This seems to be terrain on terrain shadowing issue. Everything else shadows correctly, the terrain casts shadows over itself and other objects correctly when the sun goes behind a peak, but then there's a whole load of shadowing on slopes which have a LOS to the sun. Check out the playermodel's feet in the original picture, she's stood on terrain in shadow, but it's not casting a shadow on her, because all of the model is in LOS to the sun, and so is the terrain below so it shouldn't be in shadow.

As a test, someone make a flat terrain, give it a quick noise brushing for undulating hills, set your sun 45 height, and go find a gentle slope facing away from the sun that is in shadow. The set your sun to 80 height, 80 is near enough 90, and as long as you've not got any enormous mountains, you should still see some shadowing, even though every square of the terrain should have LOS to the sun. Set the sun at 90, and all shadowing will end (as it should). Set it to 110, see shadowing even though everything is in LOS of the sun. --- then post pics!

#9 Was there a lot of shader updates in this version because it seems that everyone is having similar problems but they all look a bit different, I'm wondering how many that are having problems have an ATI card...I do....

#10 If it's also present in 1.1a, then it's not actually a shadow (ie, ray-cast shadows) issue, as the terrain wouldn't cast them in 1.1a, so it must actually be a problem with the lighting calculations.

I'm definitely not seeing anything nearly that aggressive when it comes to shading. Any way you could post the terrain and mission files you're using so I could get some comparison shots? This definitely looks like a bug, and it's starting to look hardware-specific. My gentle upward slopes facing a low-angle sun aren't pure ambient like the ones in your shots, they fade from light to dark as the angle increases, as you would expect.

GF GTX 285, btw.

#11 Upload the mission and terrain file - excellent idea.

torque.abigholeintheweb.com/public_system/useruploads/badshadowtest.zip

#12 downloaded your mission, turn up the brightness to 3, exposure to 4, and paly with the ambient scale (used 0.68 0.68 0.68 1), in your scattersky. should be able to reproduce what you had in the previous build. i do agree the default scattersky lighting is a bit dull by default in beta 1, play with the values and it looks better than the alpha.

#13 You see what I mean that Gideon being fully lit (because all of him which is facing the sun (obviously) is in LOS with the sun) but the ground he's stood in isn't receiving sunlight even though it is also in LOS with the sun.

also your sky settings burn my retinas! don't look at the sun!

#14 hehe, yeah i doubled the sky brightness, forgot to mention that.

#15 Ah, okay, now I get it. The lighting in my test scenes wasn't really making this apparent, probably because I've attempted to adjust the effect away, but I have actually noticed this before and thought it was a bit off.

I originally saw this when doing some tests with a paged scenegraph -- I took a generic random noise terrain and made it huge by setting a squaresize of 100 or so, in order to provide an area to work in. Even though the terrain angles were virtually undetectable from the perspective of a player on the ground, the terrain lighting was basically exactly the same as it was on a squaresize of 2. "Backs" of hills were the same level of darkness as before, but the actual in-game hill geometry was so subtle it appeared flat from the ground.

It's not connected to shadowing (the dynamic PSSM shadows cast by the scattersky), this is actually a problem with the terrain shading. While hills sloping up towards a low-angle sun should be darker than flat surfaces, this effect appears to not take into account the real geometry of the terrain. I'm wondering if it's based on the heightmap itself and totally ignoring the squaresize.

Basically, subtle hills are shading as darkly as the backs of tall peaks. It's easiest to get these comparisons if you just totally disable the PSSM shadows (uncheck cast shadows in the scattersky).

*Edit: Screenshots, additional theoreticizing.

Here's a shot where I've changed the squaresize in Steve's level to 64, creating a terrain with nearly flat hills. You'll see that the shading is still in extremes, either very light or very dark.


I tried editing the terrain a bit at this scale and could immediately see that the terrain slope tolerances made no sense at this squaresize. A slope over a degree or two turned totally dark (ambient light color), while a terrain slope of similar intensity facing the light turned bright too quickly.

To add to my "ignoring squaresize" theory, at a squaresize of 1, the slope of the terrain was now creating very reasonable shading, with a decent gentle slope being slightly darker than a flat terrain, and requiring a severe angle to get to totally dark.


As you can see, that looks pretty reasonable. Note that I have PSSM shadows off in both shots, as I'm pretty certain they're unrelated, and they just obscure the results. For that same shot w/ shadows, click:
ubermonkey.phpwebhosting.com/overShading2s.jpg
For a version of this shot where I've clearly identified the slopes, click:
ubermonkey.phpwebhosting.com/overShading2d.jpg
Finally, changing the texture and a little over-exposed HDR makes the shading more obvious:
ubermonkey.phpwebhosting.com/overShading3.jpg

Summary of that Wall O' Text&Img's: This definitely appears to be a lighting bug, and it first appeared in 1.1a. The fact that a squaresize of 1 seems to correct it suggests this scale factor is being ignored when doing lighting calculations (actual cast shadows seem unaffected)

I'm searching the code, looking for differences in the terrain or lighting involving squaresize, but so far not much is coming up. I did notice that the Pass object now has a squaresize value, and it seems to be getting this value from the shaders ("$squaresize")... this code is fairly mysterious to me, so I doubt that helps.

#16 FYI.

I've seen this occur at times on other systems, but i've not been able to nail the reason.

Still investigating it.

#17 I take it there are system setups where this does not occur.. didn't expect that. I guess that rules out any of the really obvious "whoops" types of errors I was looking for in the terrain lighting.

I should have included this in my first post, but here:
-Windows 7 64-Bit
-Geforce GTX 285, just updated drivers (196.21)
-Intel Q9650 (Core2 Quad)
-4 GB RAM
-Occurs on my heavily edited 1.1a as well as a stock 1.1b.

#18 By chance is anyone using HDR when this happens?

We just fixed a ton of HDR bugs internally which should all be in 1.1 beta 2.

#19 Nope, no HDR here.

Not sure it helps but the terrain lightmapping in BL causes the same over-dark ambient issue (if you bump the mlightmapsize up high to give it some detail).

#20 Tried with and without HDR, doesn't seem to make any difference. Again, the lighting appears to work properly on a squaresize of 1, increasing in its overreaction to angle as the squaresize goes up. So basically it appears to always be lighting the base heightmap geometry and totally ignoring the horizontal scale factor, though the actual shadow casting itself is working off the correct geometry.

Just wanted to make that clear because calling it an "over-dark" issue is only half the picture, the sun-facing angles are also too sharply brightened.

The easiest way to spot this issue is to take a noise terrain and kick the squaresize up to something high enough to make it nearly flat, like 20+ -- the lighting will still be sharp light/dark contrast even with basically flat geometry.