Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Lights and normal mapping
- - By Newton [de] Date 2012-09-14 12:15 Edited 2012-09-14 12:18
I looked into the shader code yesterday and tried out to do some normalmaps for textures myself.

What striked me when I saw the first generated normal maps in the game is that they looked much more "extreme" than they did in the preview in crazybump. The side of the bricks that faced the light where so light they were almost white, the other side were black. And that even though I made the normalmap in crazybump quite flat and so did crazybump's preview look like.

So I looked into the code to find out the reason for that. However, I had big difficulties to understand the code because most variable names did not speak for themselves:
lipx, lopx, npx, spx, mpx, ompx, bright, bright2, omi, mi...
Peter, I think it would be great to write-out the variables more to make it clearer to other programmers whats-what in that code. I didn't do it myself because I didn't understand the code and I don't want to fiddle around in your code without your consent as long as your work on it is not finished yet.
One thing I didn't understand for example are the two normals - I tried to leave out the normal2 completely and got the same result.

Anyway, eventually I found the places in the code that created this behaviour:

line 135-136: the brightness for a pixel is
light-level at that point * skalar product of the pixel's normal and the light  direction * 2
So if fully lighted, the landscape looks like as if you would have turned up the brightness in gimp by 100%. The notion of a diffuse map is to show the texture as if it is fully lighted. So I removed the *2 and suddenly the landscape looked pretty dark. But this is not the fault of the shader but of the diffuse textures because they currently not only have the height map baked into them but apparently also a diffuse shading as if looked on on a cloudy day*. So it is the textures that have to be changed, not the shader. Have a look at the preview in crazybump - as long as you don't enable specularity, the previewed texture is never lighter than the diffuse map.

But even by dimming the by-two light down, the effect of the normal map was still extreme. The reason I figure is an adjustment in the shader. In the crazybump preview and often in 3D games when you run around in rooms and along corridors, the lights are located at an angle (45°?) in front of the texture.
But clonk is a 2D world, so the question is where to put the light in the z-direction. If it was on the same level as the landscape, it would look completely odd. So you did already move the light a bit into the z-direction. I think the spot in the code where this can be adjusted is line 59-60. I found 0.5 to give a much more similar effect to what I would expect where the normal map only hints to the texture having a 3D-structure instead of being the main visible feature. What do you think?

Also, one last point:
As crazybump seems to be our program of choice, I suggest to keep track of with which parameters in crazybump the normalmap has been created so that we can create them with the same parameters again when the texture is changed or when we want to slightly adjust the normalmap.

* In fact, I did create most of these textures on cloudy days because otherwise the sun would have left some ugly shadows on the textures which should not at all be on a diffuse/texture map
Parent - - By PeterW [dk] Date 2012-09-14 12:49 Edited 2012-09-14 12:52

> Peter, I think it would be great to write-out the variables more to make it clearer to other programmers whats-what in that code.


Okay, sorry. As I said, I am in somewhat of a prototyping phase - I found the names going out of date very quickly, so I gave up on associating any meaning with them. Now that things are settling down a bit more, I should probably document a bit better.

This sort of programming is pretty new for me, too, so I have no stable opinion on best practices yet. Apologies, I'm learning this stuff as I go as well :)

> One thing I didn't understand for example are the two normals - I tried to leave out the normal2 completely and got the same result.


No, it will be different - though the difference will be hard to see. The two texture pixels (with, again, two normals) are for the two materials that the zoom-shader is currently interpolating between. So with removing normal2, you'd apply the normal of one texture to a (landscape) pixel worth of the other where two materials meet. Probably pretty subtle and a potential optimisation - but considering both normals is certainly the correct way to go about it at first.

> Times Two


That's intended. Normal light only uses about 50% brightness level, in order to allow many lights shining on the same spot to be even brighter than that. We might scale it down to 150% at some point, depending on what amount of "overshine" we want to allow. This doesn't have anything to do with your problem, though.

> I think the spot in the code where this can be adjusted is line 59-60.


Yes, that's the right spot. What I'm doing there is calculating the third component of the normal using the two remaining components. That's a plausible way to deal with the landscape-structure normals, but distorts the normal map of the material texture. And it's actually silly, because normal maps already contain said third component, so I don't have to just generate a new one.

The proper way would be to make vec3 out of normal & normal2, pull the normalize bit out of dotc and only apply it to everything in the normal & normal2 equations but the npx.xy bits, which we'd instead replace with npx.xyz. That would remove the current distortion.

> As crazybump seems to be our program of choice,


A bit careful - I'm not sure CrazyBump would be compatible with our license. It's definitely commercial in some way.
Parent - - By Newton [de] Date 2012-09-14 13:45
You are in Denmark?

> Normal light only uses about 50% brightness level


What do you mean? Currently it seems to use 200% brightness level(?)

>The proper way would be to make vec3 out of normal & normal2, pull the normalize bit out of dotc and only apply it to everything in the normal & normal2 equations but the npx.xy bits, which we'd instead replace with npx.xyz. That would remove the current distortion.


sorry, you lost me there. But it's good to know that you know what has to be done.

> A bit careful - I'm not sure CrazyBump would be compatible with our license. It's definitely commercial in some way.


It's true. But the CrazyBump License agreement does not restrict on how the generated maps may be used. Not even the 30-days trial does. I am thinking of buying a licence for it - it's definitely a powerful tool. Only the price is a bit expensive in my opinion.
Parent - - By PeterW [de] Date 2012-09-16 10:18

>  You are in Denmark?


Well, as I said, I don't have much time currently. Travelling a lot :)

> What do you mean? Currently it seems to use 200% brightness level(?)


Only if you assume that the normal value for shadeBright is 1.0 - but as I explained, it's actually 0.5. You will only get higher values once you overlap lights.

> sorry, you lost me there. But it's good to know that you know what has to be done.


Yeah, I kind-of dropped everything in the middle of development and decided to not just leave everybody hanging completely for a month. Given that I kind of knew exactly what I wanted to do, I have quickly whipped up a corrected version. Does this work better for you?
Parent - - By Newton [de] Date 2012-09-16 17:53

> Only if you assume that the normal value for shadeBright is 1.0 - but as I explained, it's actually 0.5. You will only get higher values once you overlap lights.


But I didn't overlap lights and still got materials that where lightened up extemely. (Currently the shader seems to be broken for me even though I didn't even recompile, otherwise I could show you some screens.)
Parent - - By PeterW [de] Date 2012-09-17 11:50
Extreme in what way? And it works fine on my Intel-chip laptop...
Parent - - By Newton [de] Date 2012-09-17 15:23
In the way that fully-lighted areas are extremely bright.
Parent - - By PeterW [de] Date 2012-09-18 08:57
Brighter than in the screenshots I posted?
Parent - - By Newton [de] Date 2012-09-18 10:50
No, like that;
http://forum.openclonk.org/attach_show.pl?aid=1776
but way brighter than the diffuse texture viewed in an image viewer and also seemingly way brighter than your first screenshots here
http://forum.openclonk.org/attach_show.pl?aid=1750
Parent - By PeterW [de] Date 2012-09-18 12:54 Edited 2012-09-18 13:22
Well, this is how it looks like on the crap laptop that I'm currently carrying around - note the cropping. Is this too bright?



[Edit]

Or more like this? I remembered that I didn't actually finish the math properly in the light map generation code.

Up Topic Development / Developer's Corner / Lights and normal mapping

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill