Just dropping by to say: Awesome!
I'm more lurking these days here, but I always follow the development of your colored light sources.
I'm more lurking these days here, but I always follow the development of your colored light sources.
Done :P
(Not entirely, now it's time for fine tuning and some new functions)
(Not entirely, now it's time for fine tuning and some new functions)
It's a cool effect, but I'm a bit afraid that it will nake our ground materials indistinguishable fron each other. How will we tell ore/earth/ashes apart?
I agree, but it can still be used for temporary light sources like a flash grenade, a normal explosion (which would be a red light), etc.
I don't even think we need to be that conservative. We just need to make sure that any light used in exploration isn't coloured too aggressively. If you put your furnace somewhere where you positively need to distinguish slight tones of red, you will just have to put some appropriate lights there yourself.
Especially note that the Clonk itself emits a white light, so anything closeby shouldn't be impossible to distinguish.
Especially note that the Clonk itself emits a white light, so anything closeby shouldn't be impossible to distinguish.
That'll always be a somewhat awkward compromise. E.g. maybe you want to design a scenario with a special blue-ish shining cave but you cannot because then earth and ore becomes indistinguishable.
I wonder if we could redesign our materials somehow such that the textures are sufficient to distinguish them under any lighting condition. The main materials affected are earth, ashes, ore, rock, granite and coal. The rest has vastly different colors and shouldn't be too problematic.
For newbies, we could also consider things like optional tool-tips near the mouse cursor when you have selected a digging tool. Like "dig earth" or "pick granite" (with a forbidden cursor in that case) if you move your mouse with that tool selected. Experts could turn off these tool-tips or they could only be shown during the tutorials or for the first 10 rounds.
I wonder if we could redesign our materials somehow such that the textures are sufficient to distinguish them under any lighting condition. The main materials affected are earth, ashes, ore, rock, granite and coal. The rest has vastly different colors and shouldn't be too problematic.
For newbies, we could also consider things like optional tool-tips near the mouse cursor when you have selected a digging tool. Like "dig earth" or "pick granite" (with a forbidden cursor in that case) if you move your mouse with that tool selected. Experts could turn off these tool-tips or they could only be shown during the tutorials or for the first 10 rounds.
Wouldn't the cleaner solution be to apply a blue gamma then? I am all for more contrast, but there's just no way that, say, purely red light is not going to lose us quite a bit of visual information.
Giving some hints about the sort of material you're about to dig could work. Would we want to, say, identify unstable materials this way too, so you can tell FlySand from Sand? I would prefer cursor icons to tooltips though.
Giving some hints about the sort of material you're about to dig could work. Would we want to, say, identify unstable materials this way too, so you can tell FlySand from Sand? I would prefer cursor icons to tooltips though.
Whether it's solved by gamma or light sources doesn't make a difference. For example, I already found it difficult to distinguish between ore and earth in Iron Peak when it had its blue gamma.
Just saying that slightly colored light has large atmospheric potential that wouldn't be achieved if we only use it in special places or for short effects. In fact we aren't good at color vision with flashes of short duration(1). But even very slight shifts in color can ruin our perception of material because Clonk doesn't provide good holistic cues to calibrate color constancy[Citation needed].
Just saying that slightly colored light has large atmospheric potential that wouldn't be achieved if we only use it in special places or for short effects. In fact we aren't good at color vision with flashes of short duration(1). But even very slight shifts in color can ruin our perception of material because Clonk doesn't provide good holistic cues to calibrate color constancy[Citation needed].
Hm. Wasn't gamma better at this because it's a nonlinear distribution? The way I understood it, it would allow us to push things way more into one direction without losing too much information.
Gamma could only cover the whole screen so it would be on or off, which might be weird when you zoom out or do a whole map screenshot.
Anyway, gamma might be nice, but needs to be reimplemented in the shader without using the gamma functionility because that interfers with OS-wide settings.
Anyway, gamma might be nice, but needs to be reimplemented in the shader without using the gamma functionility because that interfers with OS-wide settings.
Indeed, can we please not have the horror of overall gamma ramps again.
Yeah, should be trivial to do in the shader - pretty much just
Right?
uniform vec3 gamma;
slice(finish+2) {
color.rgb = pow(color.rgb, gamma);
}
Right?
I think currently you can specify gamma ramp settings for the three color channels individually, though
How does this map to the three different RGB values that one can pass to SetGamma (one for dark, one for medium, and one for bright colors)?
It doesn't. How would that be expected to work? And do we need it?
I don't know, just asking whether we'd lose any relevant functionality that way.
Interestingly enough, the existing gamma implementation seems to be mostly linear. Something like this:
Not sure whether this is directly better or worse than anything. From what I've read on the internet, using "pow" is considered the "standard" solution.
vec3 gamma[3];
slice(finish+2) {
bvec3 ishigh = greaterThan(color.rgb, vec3(0.5,0.5,0.5));
vec3 weight = 2.0 * abs(color.rgb - vec3(0.5,0.5,0.5));
color.rgb = (vec3(1.0,1.0,1.0) - weight) * gamma[1] +
weight * mix(gamma[0], gamma[2], ishigh);
}
Not sure whether this is directly better or worse than anything. From what I've read on the internet, using "pow" is considered the "standard" solution.
Fantastic! This should come handy for deeper cave atmospheres. Colored crystals and strange plants come to mind, as well as lava glowing a bit in red.. :)
This looks really nice, do you have a github repos where we can pull and test this ourselves?
Thanks, I get the following errors when running a round:
[09:12:45] FATAL ERROR: [!] Could not initialize landscape shader!
[09:12:45] FATAL ERROR: Landscape error.
[09:12:45] FATAL ERROR: [!] Could not initialize landscape shader!
[09:12:45] FATAL ERROR: Landscape error.
Is this happening repeatedly? I once had this error, restarted the engine and everything worked well. What scenario did you load? Maybe I can recreate the problem.
Yes always, tested Gold Rush and Minimal.ocs both editor and normal game mode.
Can someone else confirm the problem? How is your local repository set up?
Can confirm, here's the fix:
diff --git a/planet/Graphics.ocg/LightShader.glsl b/planet/Graphics.ocg/LightShader.glsl
index dc808f7..61189f3 100644
--- a/planet/Graphics.ocg/LightShader.glsl
+++ b/planet/Graphics.ocg/LightShader.glsl
@@ -28,7 +28,7 @@ slice(texture+5)
vec3 lightDir = extend_normal(vec2(1.0, 1.0) - lightPx.yz * 3.0);
// Query light color texture (part of the light texture)
- vec2 lightColorCoord = lightCoord;
+ vec2 lightColorCoord = lightCoord.st;
lightColorCoord.t = lightCoord.t - 0.5; // offset for the color texture
vec4 lightColor = texture2D(lightTex, lightColorCoord.st);
I agree with the middle one, the right one should be abandoned immediately though :)
New implementation, now darker color affects the darkness correctly, so to speak. From left to right: RGB(255,0,0), RGB(128,0,0), RGB(50,0,0). RGB(0,0,0) will make the color have no effect. Or do we want to set brightness manually? I cannot decide which is more handy for the user, but I suspect the latter.
Now, with the newest implementation. It is hard to pick a favorite... I think I'll go with the leftmost, since the color in the righmost can be achieved by picking a slightly desatured color with the leftmost version, but not the other way round. The difference to the middle is that brightness is handled differently, see the post above.
Implementation is here
[Edit] On second thought the white base texture looks better, still not sure what to do with that :)
Implementation is here
[Edit] On second thought the white base texture looks better, still not sure what to do with that :)
I highly prefer the middle one again, the red lights are on the both other options way too extreme and the green light near the mushrooms also looks very good here.
To have the option if needet is good, looking generally like that is not.
This is absolutely awesome. It astonishes me how a little colored lights can add so much. The mushroom cave looks great.
If you added colors only to dynamic lights, why is the lava glowing?
At that resolution, I cannot really see any difference between the three. You got the image at a larger resolution?
If you added colors only to dynamic lights, why is the lava glowing?
At that resolution, I cannot really see any difference between the three. You got the image at a larger resolution?
I placed an invisible orange-glowing rock in the lava :P Yes, I have a larger resolution, will attach to this post later.
The .xcf file has the screenshots not side-by-side, so you can compare better by disabling and enabling layers.
The .xcf file has the screenshots not side-by-side, so you can compare better by disabling and enabling layers.
Attachment: comparison4.xcf (5634k)
We chould have an environment object like the old "glittering materials" that places slowly shifting light sources inside lava. Could be quite athmospheric to have a cave actually light up from the lava.
Hm, could also be relatively easy to have light sources shift their brigthness depending on the angle, which could give a nice "flickering" effect. Lots of things to try...
Hm, could also be relatively easy to have light sources shift their brigthness depending on the angle, which could give a nice "flickering" effect. Lots of things to try...
Finally I came around to adding ambient light. Can I have a second opinion on the implementation?
The first/left implementation normalizes the ambient light before writing it to the color texture (which creates a smooth shade from the light color to the ambient color).
The second/right implementation halves the ambient light color values before writing it to the color texture (which creates harder edges, but weak=dark ambient light is not as prominent on the screen).
Normalization:
+ coherent with the rest of the implementation
- weak ambient light such as RGB(50,0,0) is noticeable at the edge of the Clonk's light even underground
Halved values
+ weak ambient light is not noticeable underground
- hard edges
- colors seem to be more saturated when the light is weak, because of the harder edges
The attached picture is just a sample, the .xcf file has more screenshots for comparison.
The first/left implementation normalizes the ambient light before writing it to the color texture (which creates a smooth shade from the light color to the ambient color).
The second/right implementation halves the ambient light color values before writing it to the color texture (which creates harder edges, but weak=dark ambient light is not as prominent on the screen).
Normalization:
+ coherent with the rest of the implementation
- weak ambient light such as RGB(50,0,0) is noticeable at the edge of the Clonk's light even underground
Halved values
+ weak ambient light is not noticeable underground
- hard edges
- colors seem to be more saturated when the light is weak, because of the harder edges
The attached picture is just a sample, the .xcf file has more screenshots for comparison.
Attachment: comparison_ambient_scaled.xcf (4069k)
I only had a brief look, but to me it looks like you stuffed some things into C4FoWAmbient that don't actually have anything to do with it. The C4FoWAmbient class takes care of making things that are overground light, and things that are underground dark. I think you call this the "light from the sun" (which is maybe not very accurate since we also already played with making lava emit this kind of light).
So, at the moment, there are two different things that we call "ambient light". That's a bit unfortunate, and I think we should come up with a clear terminology, and also strictly separate the two functionalities in the engine (i.e. C4FoWAmbient should only handle the sun-kind-of-ambient light, whereas your new "ambient color" should be stored somewhere else, maybe it makes sense to put it in C4FoW directly). What do you think?
So, at the moment, there are two different things that we call "ambient light". That's a bit unfortunate, and I think we should come up with a clear terminology, and also strictly separate the two functionalities in the engine (i.e. C4FoWAmbient should only handle the sun-kind-of-ambient light, whereas your new "ambient color" should be stored somewhere else, maybe it makes sense to put it in C4FoW directly). What do you think?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill