![[us]](/mwf/flags/us.png "United States")
Last time I checked (few days ago) e.g. a granite edge was illuminated just the same no matter whether you were standing to the left or the right of it. I don't think there have been any changes to the lighting since then.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Granite being the dark stoney texture? Problem is that the texture is already very dark and has very strong normals at the borders, so the effect is overpowered. When I was playing around with parameters I confirmed that the shading was still applied (you can do before/after fairly easily using shader reloading in developer mode), but next to the existing structure the effect ends up very subtle.
> (you can do before/after fairly easily using shader reloading in developer mode)
How? :O
Just edit the .glsl files in an unpacked Graphics.ocg while the engine is running. Just make sure the edited shader code is correct or the engine will crash :P
> Just make sure the edited shader code is correct
Oh. Okay. :D
It seemed that all new materials have that problem, though (except ore). So also rock or gold don't "stick out" anymore with respect to the surrounding earth. The landscape normals are correct, but somehow their influence in the overall shading is very low.
To some extent it is expected that the shading is less intensive than before. I made an effort to make light directions consistent for objects and landscape. To make that look good they had to be less "extreme" in some cases.
Actually I think there are at least two independent issues with shading.
1) The material edges are very "flat". This is what I mentioned in the post above. See for example the first screenshot. The rock hardly stands out against the earth, or the earth against the water. If I remember correctly we had much more of a "3D effect" there previously, and less dense materials (water) had a shadow next to denser materials (earth).
I played a bit around with the landscape shader and increased the weight of the landscape normals compared to the texture normals at the edges between materials (second screenshot). Any opinions on that? Still no shadows in the water though...
Also, the ore is somehow shaded super-strong. That's probably something funny in the material definition, though, and not in the shader.
I played a bit around with the landscape shader and increased the weight of the landscape normals compared to the texture normals at the edges between materials (second screenshot). Any opinions on that? Still no shadows in the water though...
Also, the ore is somehow shaded super-strong. That's probably something funny in the material definition, though, and not in the shader.
Yeah, that's the same factor I increased before. Didn't want to go too far though because I didn't want to dampen people's new-found enthusiasm for strong material normals.
Ore is a bit strange, yes. Maybe it's just because the texture is so bright already?
Ore is a bit strange, yes. Maybe it's just because the texture is so bright already?
I didn't just increase the factor -- I made it dependent on the landscape normal. The idea is that when the landscape normal is mostly in Z we want to see the material normals, but when the landscape normal is mostly in XY (at material edges), we want to see the landscape normals to highlight the edges.
So basically you factored the landscape normal Z component into the weight? Sounds a bit strange, given that now the output Z depends quadratically on the landscape normal, but I won't argue if it looks good.
I enabled it for now, let's see how others perceive it. To get the old behavior back, one can just set
normalMapStrengthMax to the same value as normalMapStrengthMin.
Looks good. Only gripe is that I would prefer pushing landscapeNormalDepth up to about 0.2 again to make the shading a bit softer.
I like it much better at 0.1. As Sven already pointed out it's important to have visual distinction between materials, and this helps a lot. I could probably settle with 0.15 as a compromise. ;)
What is bothering me most is that it makes the 7-pixel reach of border shading very visible (especially in corner cases). Maybe another solution here would be to increase the size of the border region?
> Maybe another solution here would be to increase the size of the border region?
Or just a stronger gradient for fading back into the material bulk? Then we'd have thinner but more pronounced edges? I'm not fully sure where would be the best way to implement that... probably adjust the horizontal/vertical bias calculation in C4LandscapeRenderGL::Update?
What do you mean by "stronger"? We can't pronounce an edge more than rotating the normal exactly into light direction, for which 0.1 is already overshooting quite a bit (light depth is 0.5). And the bias calculation (which I'm working on a bit currently, btw) is basically limited by the 127 values it can put into the byte into one direction - the shader just has to decide what to do with it.
Just to illustrate, here's the "border" brightness for diffferent values of landscapeNormalDepth and current lightDepth:
https://docs.google.com/spreadsheets/d/1OBtfOoObBtvXF370v2YBWq_5TarVGxZOKR7yT_aLQa4/edit#gid=0
(0 = far from the edge, 1 = close to the edge. Note that 0.1 actually has lower brightness at the edge because we are "overshooting" with the normal.)
Just to illustrate, here's the "border" brightness for diffferent values of landscapeNormalDepth and current lightDepth:
https://docs.google.com/spreadsheets/d/1OBtfOoObBtvXF370v2YBWq_5TarVGxZOKR7yT_aLQa4/edit#gid=0
(0 = far from the edge, 1 = close to the edge. Note that 0.1 actually has lower brightness at the edge because we are "overshooting" with the normal.)
> What do you mean by "stronger"?
Just a quicker fall-off. If the problem at the moment is that those 7 pixels are not enough for the light to properly "fade out", then we could make that fade-out quicker so it "fits" in the 7 pixels. Right, one could probably either do it in the bias calculation or in what the shader is doing with those bias values. What are you changing with this calculation?
I think I see what you're saying with the "overshooting". The brightest spot is not right at the edge but a pixel or two into the material, right? Interesting... I wonder whether we could parameterize it differently so that this can't happen and the lowest value would correspond to the maximum brightness at the edge.
What is "quicker" here and "fall-off"? :)
Because as far as I'm concerned, what you are describing sounds exactly like what happens when we increase landscapeNormalDepth: The normal becomes front-facing faster, therefore the light normalises more quickly. But this also means that the shaded area is smaller, so the edge is less distinct.
Because as far as I'm concerned, what you are describing sounds exactly like what happens when we increase landscapeNormalDepth: The normal becomes front-facing faster, therefore the light normalises more quickly. But this also means that the shaded area is smaller, so the edge is less distinct.
> What is "quicker" here and "fall-off"? :)
Basically if we have 7 pixels available for the edge, and I'm encoding brightness values with 0.0 for the default brightness in the material bulk and 1.0 for maximum brightness, then with a high landscapeNormalDepth (0.25) we have something like [0.4, 0.35, 0.30, 0.25, 0.20, 0.15, 0.10]. With a low landscapeNormalDepth close to 0.1 we get [1.0, 0.95, 0.9, 0.85, 0.8, 0.75, 0.7] -- so this leads to the effect that the 7-pixel-limit becomes very visible, because even after the 7th pixel the brightness is nowhere near default yet. Now what I mean with a stronger gradient is to get a pattern like [1.0, 0.85, 0.7, 0.65, 0.5, 0.35, 0.2], i.e. the fade-out from the edge toward the material bulk is smooth within that 7-pixel range. Does that make sense?
Well, see the spreadsheet. I have now updated it so it is exactly 7 steps, and also covers the "dark edge".
This gives the following numbers for the bright edge, assuming maximum placement difference (40 - granite to tunnel):
and for the dark edge:
With 0.45 being the "standard" illumination level. Lower placement differences should "stretch" the distribution appropriately. So, yes, this means that if we only used landscape normals, the dark edge of granite would be basically black. I might actually have to re-check the math a bit - this seems a bit too extreme.
This gives the following numbers for the bright edge, assuming maximum placement difference (40 - granite to tunnel):
0.1 : [0.45, 0.98, 0.99, 0.97, 0.95, 0.94, 0.94, 0.93]
0.15: [0.45, 0.94, 0.99, 0.99, 0.97, 0.96, 0.96, 0.95]
0.2 : [0.45, 0.88, 0.99, 0.99, 0.99, 0.98, 0.97, 0.96]and for the dark edge:
0.1 : [0.45, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
0.15: [0.45, 0.02, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
0.2 : [0.45, 0.12, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]With 0.45 being the "standard" illumination level. Lower placement differences should "stretch" the distribution appropriately. So, yes, this means that if we only used landscape normals, the dark edge of granite would be basically black. I might actually have to re-check the math a bit - this seems a bit too extreme.
The whole spreadsheet is for placement difference 40? No matter what the landscapeNormalDepth is, the gradient seems very steep. How does it look for other placement deltas? Maybe the lighting should not depend so strongly on the placement difference, but there should be only a much weaker dependence (in the extreme case only on the sign of placement delta)? Anyway, I'm looking forward to your tweaking there...
> Ore is a bit strange, yes. Maybe it's just because the texture is so bright already?
The texture is not brighter than others such as gold or firestone. But one important difference is that it does not have a normal map at all.
Hm, maybe the engine should just create a default normal map for textures when there is none? It could e.g. take the gradient of the luminance.
Stronger edges are good because they help a lot in discriminating the material borders. So I would vote for increasing it to the value of the second (except for ore).I also liked how it was done e.g. in Worms: https://upload.wikimedia.org/wikipedia/en/0/08/Worms_World_Party_screenshot.png There they explicitely had borders in vastly different color.
> If I remember correctly we had much more of a "3D effect" there previously, and less dense materials (water) had a shadow next to denser materials (earth).
Here are two screenshots of the same scenario, one from an old OpenClonk version and one from current master. In the old screenshot you can see the shadow at the edges between tunnel/water and earth/rock. I realize that we have light now coming from diferent directions instead of just the top, but did we remove these shadows on purpose? I quite liked them.
Actually there is a shadow at landscape border, just not between materials of different densities. Where does this shadow at the landscape border come from?
That's not shadow, that's just a material border at the side of the landscape. Which I would actually consider a bug if the side wasn't open.
I was actually experimenting with an implementation of this initially. However, it would have been iffy - we obviously cannot emulate it by messing with the normals, as that would mean that light coming from the opposite direction would over-saturate the "shadow". Basically, I knew that it would make things complicated going into dynamic lights, so I skipped it.
In any case, the CPU can't pre-calculate the shadows. I would have to be done on the GPU - so for example we could use the light normal at a point and test a few steps into its direction to see whether we find a higher-placement material. Might work, but will have some probably strange-looking side-effects such as single pixels casting shadows at a distance, plus even more advanced craziness when more than one light is in play.
In any case, the CPU can't pre-calculate the shadows. I would have to be done on the GPU - so for example we could use the light normal at a point and test a few steps into its direction to see whether we find a higher-placement material. Might work, but will have some probably strange-looking side-effects such as single pixels casting shadows at a distance, plus even more advanced craziness when more than one light is in play.
Hm. In principle the CPU could pre-calculate separate "shadow normals" that are used by the shader only when light comes from one direction and not the other, right? I think we even have some yet unused components in the landscape surfaces so we wouldn't need another surface for it.
I guess so. But would this really make sense? Why would shadows appear into one direction but not the other?
Just recalled that I was toying with the thought of doing this as a lights pass - you would trace the line of sight further, note the next (few?) solid-to-free transitions, then do something appropriately magical in rendering.
But note that almost by definition anything you do here would be barely noticeable: If the light is shining on it directly, the shadow will be disabled due to the light coming from the opposite direction. If the material is too thick, the light will have fallen off too much to produce any effect. So all that's left for casting shadows is relatively thin material layers, which would probably look strange using the GPU method sketched above. To make matters worse, we now ignore thin walls in close proximity to the Clonk, which means that these shadows would magically disappear in certain situations.
I don't know. I liked the feature too, and have been thinking quite a bit about it, but at this point my opinion is that it's mostly incompatible with directional lights.
Just recalled that I was toying with the thought of doing this as a lights pass - you would trace the line of sight further, note the next (few?) solid-to-free transitions, then do something appropriately magical in rendering.
But note that almost by definition anything you do here would be barely noticeable: If the light is shining on it directly, the shadow will be disabled due to the light coming from the opposite direction. If the material is too thick, the light will have fallen off too much to produce any effect. So all that's left for casting shadows is relatively thin material layers, which would probably look strange using the GPU method sketched above. To make matters worse, we now ignore thin walls in close proximity to the Clonk, which means that these shadows would magically disappear in certain situations.
I don't know. I liked the feature too, and have been thinking quite a bit about it, but at this point my opinion is that it's mostly incompatible with directional lights.
2) In a global viewport, everything is completely flat. And with everything I don't only mean the landscape but also other meshes, e.g. trees. A while ago, things were illuminated with a directional light from the front (meshes) or from the top (landscape). Now it just seems that all shading is entirely gone, and things look just super boring. Is this really intended?
Is that dectivating OC_DYNAMIC_LIGHTS? Then yes, I guess - I was mainly thinking about GUIs, where flat shading seemed to be the a more robust approach. Trying to fiddle with the constants so that stuff like menus and selection graphics had the right brightness seemed like a rather roundabout way of going about things, hence this solution.
Maybe we should have OC_DEFAULT_LIGHTS or something instead? Or provide an always-one ambient map?
Maybe we should have OC_DEFAULT_LIGHTS or something instead? Or provide an always-one ambient map?
Yes, OC_DYNAMIC_LIGHTS is deactivated -- there is no light texture in this case after all. By the way, this is also the mode in which full map screenshots are taken, so it would be good to get it more atmospheric / less boring. I was thinking for screenshots we could create a light texture from all light sources, including all clonks on the map. But on the other hand one also wants to see everything when taking a nice end-of-round screenshot, and also of course when drawing a map in developer mode.
Don't you think
Don't you think
OC_DEFAULT_LIGHTS would completely replace OC_DYNAMIC_LIGHT then? I would expect it to also look decent for e.g. meshes rendered as part of the GUI.
Well, no - as I said, the idea was that it was plain silly to have a shader with light calculations attached in cases where we really just want to blit something to the screen (like, say, a button). That's both wasteful *and* error-prone.
On the other hand, maintaining yet another set of shader configurations and #ifdefs in the shader code is also error-prone. I can assure you that the game won't lag because of rendering GUI buttons.
Well, it just boils down to skipping the whole block where light gets applied. Not really that hard to maintain. And if we get shader modifications in future we might quickly get the feature request to be able to change the brightness just of "rendered" game content.
But anyway. If you strongly disagree, feel free to change it. Just made sense to me when I worked on it.
But anyway. If you strongly disagree, feel free to change it. Just made sense to me when I worked on it.
![[de]](/mwf/flags/de.png "Germany")
To me it just feels wrong that when e.g. making a full map screenshot the shading looks completely different compared to what the players see ingame. By the way, if you want that shading for a custom scenario it's simple enough: just copy the shader files in a local Graphics.ocg and change them to your liking.
Hm, for being supposedly flat, the granite looks still very 3D to me. I think Matthias overdid it a bit with the brushing or how it is called.
Well but looking 3Dish is not a problem. For example, making ridges dark is good because you bake self-shadows into it (which we do not get from rendering).The only problem is if you have 3D cues from directional light, e.g. if the light seems to come from above. Because that will look wrong when shaded with light coming from below.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
