![[de]](/mwf/flags/de.png "Germany")
So, a Clonk can only create a particle on one of his skeleton's bones, but not on the bone of a skeleton of an attached mesh (the weapon). The latter would be more practical. Also getting the x and y position of a bone relative to the offset of the object would be cool (a projection from the 3d space of the model to the 2d space of the world).
>..would be cool (a projection from the 3d space of the model to the 2d space of the world).
That won't work, because the position is not synchronized to such a degree that would allow for getting a value into c4script. You would need to write a completely new, synchronized calculation or something for that, I think.
Allowing to create the particle at a position is another story, of course :)
Yes, there is some weird behaviour when you have multiple lights.First compare the face of the right clonk (in 1light.jpg and 2lights.jpg): Alone his face is good visibly, but when there is a light behind him (the clonk on the left) his face gets dark. That doesn't look natural.
Secondly there is a really bright highlight on the wall between the clonks. But at the clonks themselfes the light on the wall looks darker then the spot between them. Shouldn't the wall directly where the clonks stand be at least as bright as the highlight between them?
------
Also imo it's weird that the clonks can emit such a strong light although they don't have a visible lightsource. Maybe the light of clonks alone shouldn't get stronger as ambient light. Multiple torches and other artificial lights should be able to add up and get really bright though.
Another thing I noticed: When you are in ambient light all lightsources don't seem to get brighter than ambient light itself. Look at the earth between the clonks in ambient.jpg and ambient1.jpg.
![[us]](/mwf/flags/us.png "United States")
> First compare the face of the right clonk (in 1light.jpg and 2lights.jpg): Alone his face is good visibly, but when there is a light behind him (the clonk on the left) his face gets dark. That doesn't look natural.
It's probably a consequence of the fact that the two lights are stuffed into the same light texture, and we only have one normal vector per pixel even if light is coming from many different directions. This is probably hard to change without a completely different concept...
Are the normals added up be the respective strength of their light source at the given position? E.g. picture two, for a pixel at the right Clonk:light = light of light source 1 (bright because directly at clonk) + light of light source 2 (dark because far away)
normal = (light strength of light source 1 * normal of light source 1 + same with light source 2) / (light strength of all light sources)
No - and yes, that *would* be the ideal formula. Two problems though:
1. Normals are signed, so we need to put several "-0.5 * light strength" in there. No big problem, I implemented that in the alternate-lights branch.
2. The sum of all light strengths would overflow. That's harder to get around.
1. Normals are signed, so we need to put several "-0.5 * light strength" in there. No big problem, I implemented that in the alternate-lights branch.
2. The sum of all light strengths would overflow. That's harder to get around.
Hi, I came across the following "issue"...When an object is a lightsourrce and it's midpoint is in material, it goes completely dark.
I wanted to make a map, where you have to find objects in the earth. I wanted to make it easier to find them, so I made them a light source, but since they are stuck in earth, they don't emit any light.
It can also happen that when you climb with a clonk, and the clonk's midpoint gets covered in earth, the screen goes dark. (I had that only once though)
Of course I could just make the objects spawn in little caves or something.
Or maybe the objects could emit ambient light? So the clonk wouldn't glow super bright when carrying that object, in case you really just want to make the object visible in FoW, but not a real light source.
Well, that's just how light works right now - it stops when it hits solid material. Maybe it would help if we ignored material up to the light size? Otherwise I'd just suggest to make the fade-out longer until you have the effect you want.
It doesn't stop when it hits material. It still penetrates material up to a certain distance, doesn't it? I would expect to see at least this minimum circle when the light source is in solid material.
Yes, normally the fading part of the light would go through material. But when the source is in material there is no light at all.Hey, I just noticed: When you give the range a negative value, e.g.
SetLightRange(-1, 30), it actually ignores ALL material and thus making it shine inside materials! That's pretty cool, because that's basically what I wanted. Unfortunately, you can only make a kind of rounded square with it and not a nice round circle shape. There are also some glitches when the object hits the border of the screen. Was it intended to be able to give the light range negative values? :D
Hm, that's interesting. That's the effect that I'd expect when the object is surrounded by solid material, too. The "fade" (yellowish lines here) should always be there.
Edit: Well, in either case, I have now changed it so material up to a certain distance gets ignored. This can cause some strange effects (moving towards a wall causes "windows" to open up inside it), but this is more robust if nothing else.
Edit: Well, in either case, I have now changed it so material up to a certain distance gets ignored. This can cause some strange effects (moving towards a wall causes "windows" to open up inside it), but this is more robust if nothing else.
You can put sky material behind the objects. Then you'd have a light radius from ambient light.
Yes but then there'd be holes in the landscape when you dig it away. It would be great to have materials that emit ambient light that don't require a sky background. It would also make the Krakatoa map much better. The last time I played it, the lava was dark. But glowing lava with sky background would make the map look weird when you pump it away.
Another unpretty thing:When the light is not blocked by anything the geometry becomes rather simple: It becomes a square instead of a circle. You don't really notice it for clonks, because the range is so big. But torches in big caves already look like this.
Just wanted to bring up an issue again: The really dark parts on trees... But I'm not sure if it's OC's lightning system fault, because in ogre meshy there are dark spots, too. I also made a bugtracker for it.
ck is working on it.
But this is a different problem than the one on trello, no? Here it's mostly about the green part of the trees in general, while in trello it's a about the back side of the tree trunk?
Holy shit! What are you hiding from us there?! It looks gorgeous!
Nice textures!
You are referring to the green of the tree, not the trunk, right? This does not have anything to do with the lights branch, since the trees already look this way when the are overground, and I think they looked just the same before the lights branch was merged.
I think the problem with this simply is that we have only one directional light from the front, and so triangles that are perpendicular to it are very dark. This makes sense for most objects, I guess, but for trees it's a bit funny because one triangle represents a lot of leaves that, in reality, would be all oriented in different angles with respect to the viewer.
For overground objects, we could go away from using a directional light and instead just illuminate the whole object uniformly. However, this would change the appearance of several objects considerably, and things would look much "flatter". We could also make a compromise like 50% uniform and 50% directional... plenty of options, but someone needs to play around a bit and see what looks good. All these settings are changeable without engine changes by editing the shader code in Graphics.ocg/*.glsl, so I encourage you and others to play around a bit :)
I think the problem with this simply is that we have only one directional light from the front, and so triangles that are perpendicular to it are very dark. This makes sense for most objects, I guess, but for trees it's a bit funny because one triangle represents a lot of leaves that, in reality, would be all oriented in different angles with respect to the viewer.
For overground objects, we could go away from using a directional light and instead just illuminate the whole object uniformly. However, this would change the appearance of several objects considerably, and things would look much "flatter". We could also make a compromise like 50% uniform and 50% directional... plenty of options, but someone needs to play around a bit and see what looks good. All these settings are changeable without engine changes by editing the shader code in Graphics.ocg/*.glsl, so I encourage you and others to play around a bit :)
Just playing with ambient/diffuse lighting parts should solve it for the trees, right? It's nothing that needs to be done in the engine.
'Solving' the problem for every single object might lead to inconsistency, though. So if the general notion is that objects are too dark on their sides/on the back, it might be a good idea to solve that globally
Yes. At the moment the shader only uses the diffuse component (even for overground...), even if the model has non-zero ambient material properties defined. I would expect that just introducing some ambient lighting could already get us a long way...
What language are these shader files?
GLSL -- OpenGL Shading Language. To be precise, these are GLSL shader fragments (slices). The combined shader code is written to OpenClonkShader.log, and the slice order is documented.
![[gb]](/mwf/flags/gb.png "United Kingdom")
The ability to configure the lighting in script would be great.
Heads-up: I have just committed (to) a new "alternate" light update model. This is basically a mix of old and new, which for some reason I didn't see was possible:
- Overlapping lights mix normals, but use maximum intensity. Will likely continue to look a bit funky if we have a "ray" of a light from a different direction coming in, but at least Clonks will be able to group up now without brightness getting too high.
- Normals fade out much quicker than before, intensity slower. This fixes the "trailing light", but should be less "busy" than the first alternate light model.
Anyway, let me know if anything breaks.
- Overlapping lights mix normals, but use maximum intensity. Will likely continue to look a bit funky if we have a "ray" of a light from a different direction coming in, but at least Clonks will be able to group up now without brightness getting too high.
- Normals fade out much quicker than before, intensity slower. This fixes the "trailing light", but should be less "busy" than the first alternate light model.
Anyway, let me know if anything breaks.
Is it supposed to fix any of the remaining lights bugs in the bugtracker? Like the black dots or the sometimes bad interpolation?
I'll test soon!
I'll test soon!
Did you break the windows autobuilds (and my non-auto build, too)? :(https://autobuild.openclonk.org/builds/ec09d03b-677b-46bd-8628-fbe6ad621583/#make_3A_20openclonk
../source/src/platform/C4WindowWin32.cpp: At global scope:
../source/src/platform/C4WindowWin32.cpp:980:42: error: 'bool C4AbstractApp::SaveDefaultGammaRamp' is not a static member of 'class C4AbstractApp'
bool C4AbstractApp::SaveDefaultGammaRamp(_GAMMARAMP &ramp)
^
../source/src/platform/C4WindowWin32.cpp:980:42: error: '_GAMMARAMP' was not declared in this scope
../source/src/platform/C4WindowWin32.cpp:980:54: error: 'ramp' was not declared in this scope
bool C4AbstractApp::SaveDefaultGammaRamp(_GAMMARAMP &ramp)
^
../source/src/platform/C4WindowWin32.cpp:981:1: error: expected ',' or ';' before '{' token
{Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
