![[de]](/mwf/flags/de.png "Germany")
Today, Clonk-Karl merged the lights branch into master. That means, everyone can try out the new lights using the development snapshots now!Even though the originally mentioned major issues have been solved, it does not mean that all issues are gone. Please, everyone, have a look at the bugtracker, especially the major ones of course. One bug that particularly bugs me:
Wanted
Dead or alive
Lights - Odd effects when having 2+ light sources
$ 10000 Clunker Reward
This has something to do with the blending of the light texture. The solution will probably involve using a shader to compose the light texture and is thus interconnected with two other issues:
* The fade-in of the light is too slow, especially when moving fast. It looks like not the clonk himself is the light source but some kind of invisible fairy that follows him. The slow fade might be the source of some other minor display oddities.
* the lights of 2+ light sources are added in a way that the light becomes very intense. Rather than light1+light2, it should perhaps be Max(light1,light2).
Who can do this?
Congratulations to all who have worked hard on this!
Related question: Should we merge the bugs from Roadmap 5.2 and Roadmap 6.0 into Roadmap 6.0 such that we have a single roadmap for the release?
Related question: Should we merge the bugs from Roadmap 5.2 and Roadmap 6.0 into Roadmap 6.0 such that we have a single roadmap for the release?
It's fine how it is. There we see the requirements for 6.0 and 5.2 seperately. to release 6.0, both requirements need to be met.But looking at it, there is quite a lot to do. You sure those are all necessary=blocking for a release?
Yaaay \o/
I already made some of the still required normal maps. I'm continouig to make the rest these days, but the crazybump demo run out of time, so i'm stuck with the gimp Plugin.
As long as the normal map quality isn't inferior, that's ok. Otherwise, someone could do this perhaps on a different computer where the trial did not run out?
There seems to be a pretty newly launched (but in version 1.0) open source project AwesomeBump which looks promising at first glance. Perhaps give it a spin and compare the quality to your previous textures? the author also provides some videos which showcase the features: ( Okay so HOW does the vid-tag work in here? O_o ) https://www.youtube.com/watch?v=fKdCglwEacI
Like this
[vid=youtube]fKdCglwEacI[/vid]
That looks pretty awesome.CrazyBump,
InsaneBump,
AwesomeBump,...
I detect a naming pattern there.
I seems InsaneBump was a Gimp-Plugin that tried to mimic CrazyBumps features. AwesomeBump is partially based on InsaneBump as InsaneBump seems to be frozen. In a forum thread, the AB-author mentions that his tool gives poor results when the source image has a strong directional light. I expect this restriction to apply to the gimp plugin as well, then, but the landscape textures don't have very strong lights, so that's probably not a problem, probably.
>The fade-in of the light is too slow
Could this be the cause of the following glitch? When you are running around and the viewport moves to a formerly dark area, this area is lighted. But it seems the light is only updated every few frames. Because the viewport moves faster than the light is updated, there occur stripes at these areas.
Also switching clonks causes some light artifacts until everything has faded to it's right state.
> Lights - Odd effects when having 2+ light sources
Yeah, just saw this is the record for #1227. Fun how easily it is to see when normals aren't quite right. This is terrible, I might have a shot at it shortly.
And agree on the fade problem. It's actually quite bad that Clonk faces are always dark because of the trailing light source. For my local branch I already reduced the fade substantially, which makes it a bit better. Was also experimenting with having the light source "lead" moving objects a bit. That worked... less well.
I think the better solution would be to rewrite fading such that the combination with the previous surface also happens in the shader. At the moment, I think there even is a shader but it only create a surface that is then blit on top of the real light surface (which seems like an unnecessery fullscreen blit to me).That way, we can do thinks like increasing light instantly but decreasing it only over some time. We could even add a nonlinearity to this to avoid trailing lights.
Trouble is that of all things, blending is still not something that you can control with a shader. All you can do is set a blend func and pack as much meaning as you can into the RGBA vector you return. To get the full functionality of blending you would have to render to a texture, then combine that surface with the background into *another* texture. See that whole situation in C4FoWDrawLightTextureStrategy (explanation in C4FoWLight::Render) - I would *love* to use a shader there, but I don't think it's possible.
Not saying that it's always impossible, just that shaders still have some very puzzling limitations.
Not saying that it's always impossible, just that shaders still have some very puzzling limitations.
It makes a lot of sense to have your destination surface unreadable. Otherwise it would be impossible to parallelize operations. But you can always achieve the same effect by having a temporary surface - which we already have.In other words, just pass a pointer to the last lights surface (for which a copy is already generated) into the lights calculation and do the blending manually in the end. Then, as the non-programmable blend op, the surface is just copied.
I can't see how this would hinder parallelisation - at least not more than the current blending does. And working around it isn't quite that easy either - after all, we are drawing a bunch of (potentially overlapping) triangles to the frame buffer. Every drawing operation will obviously only update their own region. This means that we need to manually keep track of what exactly was written where, culminating in different drawing plans for points that are blended over 0, 1, 2... times.
Or we copy the whole frame buffer for every triangle (strip?) we draw. Either way, it's madness.
Or we copy the whole frame buffer for every triangle (strip?) we draw. Either way, it's madness.
Ah I see the problem now. It could still be prevented by switching between three surfaces instead of two.One surface is always used for drawing the current light state. For the faded light state, the engine alternates between the other two surfaces so it can use the previous frame state as a source.
That would incur one extra frame buffer switch, one extra surface and the blit operation would have two sources instead of one. But the final blit would be simpler because it would be without alpha.
One extra frame buffer copy per triangle strip, as I said. Admittedly, we don't have to do it per triangle strip - as long as nothing overlaps (!) we would only have to do it once per light source. And if we know the lights bounds, we don't have to blend over the whole frame buffer either. On the other hand, if we overwrite the whole thing at least once, we could combine it with the fade-out shader.
So, yes, it's probably acceptable. What problem were we trying to solve exactly? Use
[Edit XVIII] The problem with the "lagging" light is actually the normals, not the light intensity. Hm, maybe we could make normals adapt faster than intensity? I might actually give this a try. Might become messy though, that's nothing I'll hack together overnight.
So, yes, it's probably acceptable. What problem were we trying to solve exactly? Use
max for setting light intensity, possibly?[Edit XVIII] The problem with the "lagging" light is actually the normals, not the light intensity. Hm, maybe we could make normals adapt faster than intensity? I might actually give this a try. Might become messy though, that's nothing I'll hack together overnight.
No, not one copy per strip. Just one frame buffer change. Like this:* Three surfaces: a, b, c
1. Swap b,c
2. Select a as render target
3. Clear a
4. Draw all triangle strips to a
5. Select b as render target
6. Draw to b from a,c using our blending shader
-> b contains the current lights surface
I would guess that switching the render target is a pretty expensive operation since it needs to flush stuff in the rendering pipeline. But then, drawing the lights triangles is probably not an expensive operation anyway.
Yes, I know what you meant - but that still only works as long as the triangle strips don't overlap. But as I said, that's the case as long as we only draw one light at a time, so it's not *too* bad.
Why? "4. Draw all triangle strips to a" is the same thing that is done now, isn't it? I meant all triangle strips of all lights of course.
What would happen then when two lights overlap? Unless we want another piece of "blending" magic, the lights would just overwrite each other then, no?
No, they would be merged by the same code that merges them now.
Ah, okay, now I understand the confusion. Sorry, my answer referred to the second part of the posting. It's not a solution for the blending of multiple light sources, but for the blending of the light sources with the previous frame buffer - i.e. the problem with the trailing lights.For multiple light sources, I think standard blend ops should be sufficient. Can't we just push light intensity into the alpha channel, then blit alpha with blend equation of GL_MAX and do regular alpha blending for the normal vectors in the color channels?
Possibly. But blending over the old state is not the complicated part in the first place... Using
glBlendFuncSeparate to get max on intensity is a nice idea, and I'll probably try it. But this is still adding extra complexity exactly where I'd like to get rid of it :/
Actually, we could then blit the previous frame buffer in the same way using GL_MAX for the intensity channel. It would ensure that light is lit up immediately (so no trailing lights) and fades out gradually.
Just FYI - the approach I mentioned here is now implemented, in the
alternate-lights branch. It updates lights a lot faster. I don't like it, but if somebody wants to see this in action, that's now possible.
Btw, there are still two light parameters that we might want to expose to script:
- Light intensity. Right now it's hard-coded at 0.5, which means that two lights will add up to maximum intensity.
- Light size. This decides how "soft" the light is. Higher values means soft shadows, but possibly less light shining through narrow passages. Right now hard-coded at 20.
Does that sound useful to anybody?
- Light intensity. Right now it's hard-coded at 0.5, which means that two lights will add up to maximum intensity.
- Light size. This decides how "soft" the light is. Higher values means soft shadows, but possibly less light shining through narrow passages. Right now hard-coded at 20.
Does that sound useful to anybody?
What is shining through narrow passages? I find it very strange that in a cave you can see infinitely far into a narrow passage (along the straight line).
Hm, the effect is less obvious than I would have thought... Reason is that I'm "capping" the light size for close distances - otherwise a single pixel right in front of the Clonk would cast a huge shadow.
Anyway, here's screenshots for sizes 5, 10, 15 and 20 (current default). It's probably easiest to see that the normals fall off at different speed, which leads to the middle becoming "brighter". But if you look closely, you will see that the shadows on the left and the upper-right also change shape a bit:
Anyway, here's screenshots for sizes 5, 10, 15 and 20 (current default). It's probably easiest to see that the normals fall off at different speed, which leads to the middle becoming "brighter". But if you look closely, you will see that the shadows on the left and the upper-right also change shape a bit:
I find 20 to look more appealing than 5 at least - but my main reason for that is not the general brightness or the shadows but that in the 20-picture, the Clonk itself has no noticable shadows.In the 5-picture it does not look like the Clonk (or the player) is the source of the light but that there is a very tiny lightbulb in front of the Clonk, leading to hard shadows on the Clonk itself.
I guess that is an effect of capping close lights? In the 20-picture the area around the Clonk has full (or even more) brightness and the falloff only starts further away from the Clonk, right?
> - Light intensity. Right now it's hard-coded at 0.5, which means that two lights will add up to maximum intensity.
Oh. Really, that little? I had the impression that ambient light and light from clonks are about the same brightness. In my opinion, lights from clonks may not be any lighter than the ambient light (so ~any lighter than how they are currently). If two lights meet, it should not get any brighter. Instead, the light range is obviously larger (if the lights are not at the same point).
Let's say that the current light intensity for one clonk is 100%, then I think this could be exposed to C4Script together with when colored lights are introduced - as the alpha value. SetLightColor(RGBa(x,y,z,a))
> - Light size.
I think that shouldn't be exposed but rather be playtested to find an optimal value. I see no gain (= no use case) for making this definable in script (for possibly each light different).
> In my opinion, lights from clonks may not be any lighter than the ambient light
I actually thought about reducing the light intensity for Clonks... Wouldn't it be nice if you could really see everything being brighter in your well-lit cave?
> I see no gain (= no use case) for making this definable in script (for possibly each light different).
It actually governs how fast the normal shifts around the light source, too. It could make a lot of sense to make this bigger for "ambient" type lights.
> I actually thought about reducing the light intensity for Clonks... Wouldn't it be nice if you could really see everything being brighter in your well-lit cave?
If everything being dark is the "normal" thing to happen during some rounds (i.e. those without torches and lit caves), then we just end up in a situation like the current night implementation using gamma: Your eyes adapt to the darker screen and you need to make everything excessively dark for the effect to be noticed at all (and then you can hardly see anything). But I guess it can be worked around by making clonks lights an easy-to-adjust scenario property.
Btw: An interesting way to implement night time now would be to just switch off the ambience light caused by sky material. The nice property of this method is that it automatically doesn't affect caves. If we have colored lights, we could also just reduce ambience and give it a blue-ish color.
Well, I *was* talking about relative brightness (base vs. Clonk). Having the player's eyes adjust to the dim surroundings only to be blinded by their base? Well, let's not overdo it.
The problem Newton was talking about was actually that having a bunch of Clonks together would now also produce this effect. As I wrote above, *this* might be a reason to use
And yes, switching off (or fading out) sky ambience at night would probably work well. I really like the effect together with a non-black background (such as stars): The landscape becomes a silhouette then, just like in real life.
The problem Newton was talking about was actually that having a bunch of Clonks together would now also produce this effect. As I wrote above, *this* might be a reason to use
max instead of addition for updating light intensity.And yes, switching off (or fading out) sky ambience at night would probably work well. I really like the effect together with a non-black background (such as stars): The landscape becomes a silhouette then, just like in real life.
![[us]](/mwf/flags/us.png "United States")
> And yes, switching off (or fading out) sky ambience at night would probably work well.
By the way, there is already a script function to do that: http://docs.openclonk.org/en/sdk/script/fn/SetAmbientBrightness.html
A valid point. Looks like lava-glow and global ambient light cannot be be killed with one stone.
We could just have one int light_range[256] that defines a custom range per material/texture. Then there can be functions to set all sky background ranges or ranges of certain materials.Altenatively just has_light[256] if multiple light ranges are hard to implement.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
