> (you can do before/after fairly easily using shader reloading in developer mode)
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.
Ore is a bit strange, yes. Maybe it's just because the texture is so bright already?
normalMapStrengthMaxto the same value as
> 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?
Just to illustrate, here's the "border" brightness for diffferent values of landscapeNormalDepth and current lightDepth:
(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.
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?
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.
> 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.
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.
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.
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.
Maybe we should have OC_DEFAULT_LIGHTS or something instead? Or provide an always-one ambient map?
Don't you think
OC_DEFAULT_LIGHTSwould completely replace OC_DYNAMIC_LIGHT then? I would expect it to also look decent for e.g. meshes rendered as part of the GUI.
But anyway. If you strongly disagree, feel free to change it. Just made sense to me when I worked on it.
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