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.
> 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 ;)
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?
> Do you know where the from other materials is applied?
Hm? If you mean the "material lights", it should be in AmbientShader.glsl.
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?
> 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.
>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.
>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?
> 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.
>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.
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.
>* 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?
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?
>* 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.
>* 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.
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".
>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?
> 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.
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.
Also how does the clonk get his light range and its color?
- 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. :)
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.
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
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill