Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Material Shading
- - Date 2015-10-16 23:48
Parent - - By Clonk-Karl [us] Date 2015-10-16 13:55
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.
Reply
Parent - - By PeterW [gb] Date 2015-10-16 14:26
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.
Parent - - By Clonkonaut Date 2015-10-16 14:45

> (you can do before/after fairly easily using shader reloading in developer mode)


How? :O
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-16 15:00
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
Reply
Parent - By Clonkonaut Date 2015-10-16 15:01

> Just make sure the edited shader code is correct


Oh. Okay. :D
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-16 15:04
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.
Reply
Parent - - By PeterW [gb] Date 2015-10-16 16:17
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.
Parent - - By Clonk-Karl [us] Date 2015-10-16 23:40
Actually I think there are at least two independent issues with shading.
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-16 23:44 Edited 2015-10-16 23:52
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.
Reply
Parent - - By PeterW [gb] Date 2015-10-16 23:54
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?
Parent - - By Clonk-Karl [us] Date 2015-10-17 00:02
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.
Reply
Parent - - By PeterW [gb] Date 2015-10-17 09:06
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.
Parent - - By Clonk-Karl [us] Date 2015-10-17 18:36
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.
Reply
Parent - - By PeterW [gb] Date 2015-10-17 19:22 Edited 2015-10-17 19:26
Looks good. Only gripe is that I would prefer pushing landscapeNormalDepth up to about 0.2 again to make the shading a bit softer.
Parent - - By Clonk-Karl [us] Date 2015-10-17 21:33
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. ;)
Reply
Parent - - By PeterW [gb] Date 2015-10-18 09:10 Edited 2015-10-18 09:14
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?
Parent - - By Clonk-Karl [us] Date 2015-10-18 22:34

> 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?
Reply
Parent - - By PeterW [gb] Date 2015-10-19 08:52
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.)
Parent - - By Clonk-Karl [us] Date 2015-10-19 23:44

> 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.
Reply
Parent - - By PeterW [gb] Date 2015-10-20 19:50
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.
Parent - - By Clonk-Karl [us] Date 2015-10-21 03:29

> 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?
Reply
Parent - - By PeterW [gb] Date 2015-10-21 18:21 Edited 2015-10-21 18:24
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):
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.
Parent - - By Clonk-Karl [us] Date 2015-10-25 01:58
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...
Reply
Parent - By PeterW [gb] Date 2015-10-26 12:27
Yeah, was thinking the same. Right now I'm working on revising the bias calculation itself so it's less prone to artefacts. Puzzlingly, I got a bit stuck with it, hope to make some progress eventually.
Parent - - By Clonk-Karl [us] Date 2015-10-17 00:13

> 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.
Reply
Parent - By Sven2 [us] Date 2015-10-17 02:19
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.
Parent - By PeterW [gb] Date 2015-10-17 09:17 Edited 2015-10-17 09:31
Right. That actually makes a lot of sense - the "default" normal map is currently (0.0,0.0,0.0) when it should *really* be (0.0,0.0,1.0). This also explains why water was always behaving strangely. Oops.

[Edit: Fixed now.]
Parent - - By Sven2 [us] Date 2015-10-17 00:04
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.
Parent - By PeterW [gb] Date 2015-10-17 09:33
I imagine this wasn't really for 3D effects, but for things like making the upper side "grassy" in certain landscape types? I mean, implementing custom border colours wouldn't be impossible, but not sure I see the appeal.
Parent - - By Clonk-Karl [us] Date 2015-10-17 21:11

> 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.
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-17 23:59
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?
Reply
Parent - - By PeterW [gb] Date 2015-10-18 09:25
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.
Parent - By Clonk-Karl [us] Date 2015-10-18 22:18
Okay, I added a bug report for it.
Reply
Parent - - By PeterW [gb] Date 2015-10-18 09:23
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.
Parent - - By Clonk-Karl [us] Date 2015-10-18 22:21
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.
Reply
Parent - By PeterW [gb] Date 2015-10-19 08:17 Edited 2015-10-19 08:19
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.
Parent - - By Clonk-Karl [us] Date 2015-10-16 23:48
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?
Reply
Parent - - By PeterW [gb] Date 2015-10-16 23:57 Edited 2015-10-17 00:00
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?
Parent - - By Clonk-Karl [us] Date 2015-10-17 00:09
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 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.
Reply
Parent - - By PeterW [gb] Date 2015-10-17 09:02
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.
Parent - - By Clonk-Karl [us] Date 2015-10-17 17:39
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.
Reply
Parent - By Sven2 [us] Date 2015-10-17 18:08
Depends on the number of GUI buttons!
Parent - By PeterW [gb] Date 2015-10-17 18:44 Edited 2015-10-17 18:47
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.
Parent - - By Marky [de] Date 2015-10-18 10:08
The completely flat stuff looks cool, too.
Parent - By Clonk-Karl [us] Date 2015-10-18 15:51
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.
Reply
Parent - - By Newton [de] Date 2015-10-19 15:34
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.
Parent - By Sven2 [us] Date 2015-10-19 20:09
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.
Up Topic Development / Developer's Corner / Material Shading

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill