Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Colored lights
1 2 3 Previous Next
Parent - - By Marky [de] Date 2015-06-04 14:49 Edited 2015-06-04 15:38
Yes, that makes sense. So the sun just makes everything bright, and nothing else (a sun of different color, along with the global "ambient light" would make the whole thing needlessly complex). FoW seems a good choice for that, yes. I still would leave the FoW color black, just add information to the light texture.
Where do materials emit light/brightness? I also wanted to implement an option for material light with different colors.

Edit: One additional thing: The color value of that global light influences the brightness of the sun light at the moment. Otherwise, a dark red global light is not possible at the moment, because it gets normalized by the shader. The darker color is achieved by reducing the brightness of the sun.
Parent - - By Clonk-Karl [us] Date 2015-06-04 16:31

> So the sun just makes everything bright, and nothing else (a sun of different color, along with the global "ambient light" would make the whole thing needlessly complex)


The way the "sun" works at the moment is basically just be letting sky material emit white color. The same mechanism could easily be adapted for other materials to emit light, such as lava emitting some orange-ish, or crystals some blue/white-ish color. That's why I referred to it as ambient light, not as sun... maybe we could call this something like "material lights"?

> Edit: One additional thing: The color value of that global light influences the brightness of the sun light at the moment. Otherwise, a dark red global light is not possible at the moment, because it gets normalized by the shader. The darker color is achieved by reducing the brightness of the sun.


As I said, I would prefer to keep these two concepts separate. By default the "sun" should make everything bright, and if a scenario author wants dark red light also overground, they should call SetAmbientBrightness() themselves. Sorry I didn't yet get to look at the details of your implementation, so this is my slightly uninformed opinion ;)
Reply
Parent - - By Marky [de] Date 2015-06-04 16:50
Ok, "material lights" sounds good then.

In the current implementation the color is always of the same brightness, because it is normalized in the shader. A dark color is just blended over more easily by light colors, because dark light is weak. The actual darkness of the light is achieved by also reducing it's brightness, so that it is less prominent in the light intensity texture. For brightness I use V from the HSV color scheme, so that overall brightness = V * brightness.

Example: RGB(128, 0, 0) would have the same effect as RGB(255, 0, 0). But RGB has only a value of 0.5, which makes the light half as bright as the other one.

Do you know where the from other materials is applied?
Parent - - By Clonk-Karl [us] Date 2015-06-04 17:59

> Do you know where the from other materials is applied?


Hm? If you mean the "material lights", it should be in AmbientShader.glsl.
Reply
Parent - - By Marky [de] Date 2015-06-04 21:06
Regarding terminology: We already use "material lights" for sun and lava, what are the other lights then, "object lights"?

Hmm, this could be a bit of a mess... The object lights have their own texture for brightness/color, and the material light has a texture for brightness only.

So: the material light would need the same upper/lower-half implementation for material brightness/color, then mix it with the mix function that is used in the AmbientShader.glsl?

Currently the material light color is just the default color for the lower half of the object lights texture.

The other question was actually: Where in the c++ code do materials with "Light=1" add brightness to the material light texture?
Parent - - By Clonk-Karl [us] Date 2015-06-04 21:54

> Regarding terminology: We already use "material lights" for sun and lava, what are the other lights then, "object lights"?


Until now I always thought in terms of ambient light and dynamic light. Material light and object light are maybe more accurate, though, since they explictly specify the source of the light.

> So: the material light would need the same upper/lower-half implementation for material brightness/color, then mix it with the mix function that is used in the AmbientShader.glsl?


Good question. At the moment, the texture uses only one component, since it doesn't store normals. So this could easily be extended to three componets without the upper/lower half trick. Whether we might want to introduce normals for this at some point would be a completely different question that I was not thinking about before yet...

> The other question was actually: Where in the c++ code do materials with "Light=1" add brightness to the material light texture?


In C4FoWAmbient.cpp.
Reply
Parent - - By Marky [de] Date 2015-06-05 05:38

>Whether we might want to introduce normals for this at some point would be a completely different question that I was not thinking about before yet...


If you stand in front of the material, then the light would come from that direction, so it would make sense to introduce normals for that. Is it necessary though?
What happens with material light, for example when lava floods a tunnel? Is it updated?

With object lights, why is it that the rays that go towards the sky are so few? It creates an ugly box-like shine, whereas the landscape is scanned for every edge, creating a nice round shine.

If we want to do normals, then we could have something like that mock-up that I attached.
Attachment: mock.jpg (178k)
Parent - - By Pyrit Date 2015-06-07 18:09

>It creates an ugly box-like shine, whereas the landscape is scanned for every edge, creating a nice round shine.


Noticed that, too. Does it need a bugtracker?
Parent - By Marky [de] Date 2015-06-07 20:52
Yes, add an entry please.
Parent - - By Clonk-Karl [us] Date 2015-06-08 13:27

> Is it necessary though?


I'd skip it for now. Also, for objects on the surface, the light would then come mostly from the top. Not sure that's what we'd want.

> What happens with material light, for example when lava floods a tunnel? Is it updated?


Yes; I didn't test it particularly with flowing lava, but it should.
Reply
Parent - By Marky [de] Date 2015-06-08 18:46

>Also, for objects on the surface, the light would then come mostly from the top. Not sure that's what we'd want.


I would implement it so that light in the yellow region comes from the "front"/screen. Then at the boundaries in the direction of the normal of that line, ie outward. Well, skipping it is easy and we can implement that later if we deem it necessary.

Regarding lava: yes, it gets updated.
Parent - - By Pyrit Date 2015-06-07 18:12
Could we have objects emit ambient light, too? It could be used to show in earth objects, like I did in the glacier map.
Parent - - By Anonymous [se] Date 2015-06-08 11:51
What would be the point? That would be like a regular light with only falloff range, wouldn't it?
Reply
Parent - - By Pyrit Date 2015-06-08 16:24
For one, it wouldn't add to the clonk's light, when it is carried. For second, regular lights in materials don't work well.
Parent - By Marky [de] Date 2015-06-08 16:32
It will remove fog of war. Concerning gameplay there is no difference between object and material light, the difference is just in the implementation.
Parent - - By PeterW [gb] Date 2015-06-08 18:41
If you refer to the light "blockiness" - that should be relatively easy to fix. Just subdivide all beams above a certain angle threshold.
Parent - - By Pyrit Date 2015-06-08 21:37
Yes, it's the blockieness, but also the light goes out when the objects center is in earth. (AT least last time I checked :x) The right behaviour would be that it shows light with the radius of the defined falloff distance.
Parent - - By PeterW [gb] Date 2015-06-09 08:54
Pretty sure I fixed that in February.
Parent - By Pyrit Date 2015-06-09 11:29
Cool, nevermind then! :D
Parent - - By Marky [de] Date 2015-06-28 10:16
If nobody objects I'd merge this branch into the master branch. Clonk Karl already gave his consent.
Parent - - By Maikel Date 2015-06-28 10:20
There is still documentation lacking from what I can see, otherwise I don't have any objections.
Parent - By Marky [de] Date 2015-06-28 10:24
Right!
Parent - - By PeterW [gb] Date 2015-06-28 11:40 Edited 2015-06-28 11:43
Please don't use merge - instead squash & rebase and write a good overview commit message for the whole thing.

A few thoughts about the patch:
* LIGHT_DEBUG_COLOR seems to work very differently from LIGHT_DEBUG. A comment explaining the difference would be nice.
* You often put two spaces between type and name in variable declarations. Is that another style thing people have come up with?
* That "lightColorCoord" definition looks really funky. How about just "lightCoord.st - vec2(0.0,0.5)"?
* What is the "pink shade for debugging" about? Should that be LIGHT_DEBUG_COLOR?
* Could use better names than "C4DP_First" and "C4DP_Second". But that's probably something I should change afterwards.
* Also huh, the "shadow" naming really doesn't make sense, does it.
* You are declaring "alpha" in "DrawVertex" so it scopes over multiple "case" alternatives. That is a warning for multiple C++ compilers.
* SetColour: We have "GetRedValue" & co for extracting bytes from a RGB word
* The change to C4FoWLight::Update only consists of changing the curly brackets to a different style? You have lots of these. If you feel strongly about the code style, I would suggest making it a separate commit.
* A few commented-out "GL_SCISSOR_TEST" in "C4FoWRegion::BindFramebuf".

There's probably a few conflicts with my current work on the lights, but I'll take care of those.
Parent - - By Marky [de] Date 2015-06-28 12:03 Edited 2015-06-28 16:44
A few thoughts about the patch:

>* LIGHT_DEBUG_COLOR seems to work very differently from LIGHT_DEBUG. A comment explaining the difference would be nice.


Maybe I'll remove it entirely. Done

>* You often put two spaces between type and name in variable declarations. Is that another style thing people have come up with?


No, I'll check where I did that. My intention is using one space onyl.

>* That "lightColorCoord" definition looks really funky. How about just "lightCoord.st - vec2(0.0,0.5)"?
>* What is the "pink shade for debugging" about? Should that be LIGHT_DEBUG_COLOR?


I'll check it. Done

>* Could use better names than "C4DP_First" and "C4DP_Second". But that's probably something I should change afterwards.


Ok.

>* Also huh, the "shadow" naming really doesn't make sense, does it.


Where was that?

>* You are declaring "alpha" in "DrawVertex" so it scopes over multiple "case" alternatives. That is a warning for multiple C++ compilers.


Do you have a suggestion how to improve it?Done

>* SetColour: We have "GetRedValue" & co for extracting bytes from a RGB word


Cool, I'll implement that then.Done

>* The change to C4FoWLight::Update only consists of changing the curly brackets to a different style? You have lots of these. If you feel strongly about the code style, I would suggest making it a separate commit.


We have a code style document for C4Script somewhere. Usually I apply that also to the engine code when I see something. It's a habit from my work place. Creating a separate commit seems like a lot of effort for this patch. I'll proceed as you said in future commits.

Done.

>* A few commented-out "GL_SCISSOR_TEST" in "C4FoWRegion::BindFramebuf".


Thanks, I'll check those.Done.

>Please don't use merge - instead squash & rebase and write a good overview commit message for the whole thing.


I am not too familiar with the git workflow. I am  comfortable with squashing and rebasing on my own branch, but I want to keep the single commits somewhere. So... I cherry pick my commits to the master branch, squash them into one commit with good description and then push that?
Parent - - By PeterW [gb] Date 2015-06-28 14:37

> Do you have a suggestion how to improve it?


Just put a block around the case alternative.

> Creating a separate commit seems like a lot of effort for this patch.


Well, this sort of thing is very likely to cause conflicts if the code is changed in other ways. And it's always nicer when you know that the commit in question didn't include any functionality that your merge could break.

> I am  comfortable with squashing and rebasing on my own branch, but I want to keep the single commits somewhere.


Simply create a copy of your branch, then rebase/squash either of them.
Parent - By Marky [de] Date 2015-06-28 17:30 Edited 2015-06-28 20:09
Done in this patch/branch. I even undid the code style format in C4FoWLight where it did not change the functionality.

I found the "shadow" parameter, you can rename it as you like. I added the comments based on what I observed.

[Edit] I am currently testing this on my master branch. There were changes in C4FoWRegion, but the conflict was easy to resolve.
Parent - - By Maikel Date 2015-07-15 20:54
I found a bug, the default color of the lights seem to be black which makes SetLightRange do nothing unless you set a light color, this breaks the torch and fire arrow.

Also how does the clonk get his light range and its color?
Parent - - By Maikel Date 2015-07-16 11:12
Also savegames seem to be broken, since lightColor does not seem to be stored.
Parent - By Maikel Date 2015-07-19 08:07
Might all be fixed by this commit.
Parent - - By Pyrit Date 2015-07-16 11:09 Edited 2015-07-16 11:11
I played the test map and there are some things that appear a bit unnatural.

- the clonk emits blue light. When he walks on the surface this blue light makes the buildings actually appear darker than in normal ambient light.
- the blue light does only affect the borders of the red foundry light. The most part of the red light looks like it stays 100% red.
- there is something weird going on in the acid in this screenshot.

But over all it really adds a good athmosphere and I can't wait for my mines to be tinted in the orange glow of torches and smelting foundries. :)
Attachment: Screenshot002.png (1543k)
Parent - By Marky [de] Date 2015-07-22 20:10
Hmm, maybe there is a problem with how the light intensity is blended... the blue light has less than 100% brightness, so if blending goes wrong, then the area appears darker.

What you see in the acid is the light emitted by the Clonk. It has a blind spot under the cliff, that's where the normal ambient light is. Same issue as the blending thing above probably.
- By Maikel Date 2015-07-14 21:32
Since this now has been pushed to master: Is there any testing that still needs to be done? And is it already used somewhere? We should try to make scenario using this :)
- - By Marky [de] Date 2019-04-12 18:01 Edited 2019-04-12 18:05
Coming back from the grave :D

Well, did some additional work, because I wanted ambient light with color for a long time, too. Currently this is implemented as an uniform "ambientColor" that is forwarded to the shader, then in the shader I do some non-correct light mixing on the fragments, and you can see the result here:



For some reason the ambientColor uniform is available for "dynamic light" only :/. Here are some mockups setting the color in the shader directly, so that the landscape gets the correct color, too:

Normal light RGB(255, 255, 255)

"Sundown" RGB(255, 128, 150)

"Night" RGB(20, 20, 100)

No light RGB(0, 0, 0)


FInally, the issues that I have with it, will not merge this soon:
- the GUI is affected, too => preferrably it should not
- it overrides the actual Clonk light (which just reveals FoW, but it is already white and that is changed to the ambient color). Ideally, I'd like to use the ambient light color when the light texture is generated in the engine, but could not find where the color value is set in the "draw light pixel" or what it is called.
- the landscape does not get the ambient color, so it draws at the darkest possible color, as mentioned above
- there are weird artifacts if everything is set to the darkest color
Attachment: lights_sundown.jpg (154k)
Attachment: lights_normal.jpg (158k)
Attachment: lights_night.jpg (119k)
Attachment: lights_darkest.jpg (87k)
Attachment: lights_actual.jpg (144k)
Parent - By Sven2 [us] Date 2019-04-14 04:16
Nice, very atmospheric :-)

I always found the blue-ish night tone a bit too extreme in CR. Maybe if a shader would just modify the contrast and de-saturate, it could look more night-ish?
Up Topic Development / Developer's Corner / Colored lights
1 2 3 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill