![[de]](/mwf/flags/de.png "Germany")
Sometimes, technical limitations sometimes create interesting gaming conditions. I like Carlo.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Yes, Carlo again. The change I wanted to make is that the light is drawn to the light buffer additively - so we can easily have multiple light sources blend into each other. But rendering the light in a way that it doesn't draw over itself (and therefore doubles the light at the point) is a bit tricky.
The issue here is that for each ray, the fadout area is a quad:
That quad might start (and end) at a different distance from the light, depending on where it hit solid material. Notice the "jumps" in the screenshot above? Now as we have rounding when converting to GL floats, it is impossible to make those quads "fit" right next to each other - there's always either overlap or pixels that aren't covered. Hm.
Dear quasi-blog... This might have a chance of going away once I implement soft shadows - this can be seen as interpolating properly between neighbouring rays, so this might be solved as a side-effect. Downside being that this is something that I need to properly work out first. Hm.
I don't understand the problem with overlapping sections. Shouldn't rounding always be the same whether a line is calculated as the beginning or an end of a section?
Okay, here's a drawing:
I want to fill the space between the black lines (terrain) and red lines in order to have rays (yellow lines) extend a bit into material. In theory, that's easy - just draw quads A1-A2-A4-A3 and B1-B2-B4-B3. In practice, I can never guarantuee that A2, B1, A4 and B3 are really on a straight line after rounding - meaning that on the line between A4 and B1 I either get overlap or missing pixels.
The fix is probably to draw the polygons A1-A2-B1-A4-A3 and B1-B2-B4-B3-A4. But for that I have to change how I draw those rays, trying to find out whether or not to do this. That's pretty much what I'd have to do for round shadows, hence above comment.
I want to fill the space between the black lines (terrain) and red lines in order to have rays (yellow lines) extend a bit into material. In theory, that's easy - just draw quads A1-A2-A4-A3 and B1-B2-B4-B3. In practice, I can never guarantuee that A2, B1, A4 and B3 are really on a straight line after rounding - meaning that on the line between A4 and B1 I either get overlap or missing pixels.
The fix is probably to draw the polygons A1-A2-B1-A4-A3 and B1-B2-B4-B3-A4. But for that I have to change how I draw those rays, trying to find out whether or not to do this. That's pretty much what I'd have to do for round shadows, hence above comment.
What about projecting each point to one horizontal top and one horizontal bottom line? I.e., Quad A is actually drawn as A1-A2-B3-A6, and quad B is drawn as A2-B3-B4-B5. Of each quad, you draw only the limited, vertical sections defined by A1/A3 for quad A and section B1-B3 for quad B. But horizontal limits are always calculated using coordinates projected to the respective baselines.The top line used for all calculations would probably be the light source; the bottom line would be the bottom of the landscape or max range of the light.
Well, can I still get the right color distribution in the quad then? My goal is to get a smooth gradient from (0,0,0) at A1/A2/B1/B2 to (x,x,x) at A3/A4/B3/B4.
I don't see why not? Color is based on y position relative to y borders. All you do is base x border calculation on a different rectangle (or triangle in that case).
Well, how do I get a gradient from white to black from A1 to A3 if I'm really drawing from L to A6? Can I give negative values as the vertex colors?
Ah, so you're using the GPU's drawing functions and you don't have access to the actual drawing code (i.e. the loops that fill the triangles)?That's rather problematic then. Maybe you could define texture coordinates out of the [0, 1] range, and set the clamp mode to "don't draw anything outside texture range".
Well, yes, that's the idea - leave the actual filling operations to the GPU. That way, the FoW can have almost arbitrary resolution.
And yes, I suppose I could clamp one way or the other - but that still leaves me with the gradient that I can't define :/
And yes, I suppose I could clamp one way or the other - but that still leaves me with the gradient that I can't define :/
And just because I am all in the drawing mood already - here are my current completely untested and offensively wrong (as far as physics go) plans for round shadows:
Idea is to cast an additional ray (green) and find out where it hits the end of the ray (C). Then I'd draw A1-A2-C-A3, A2-B1-A4-C, C-A4-B3 and B1-B2-B4-B3-A4. No idea whether that will work, to be frank, but it should be the right direction. I have to cheat massively for this anyway, as the proper solution would be ridiculously expensive.
Idea is to cast an additional ray (green) and find out where it hits the end of the ray (C). Then I'd draw A1-A2-C-A3, A2-B1-A4-C, C-A4-B3 and B1-B2-B4-B3-A4. No idea whether that will work, to be frank, but it should be the right direction. I have to cheat massively for this anyway, as the proper solution would be ridiculously expensive.
I talked with a colleague who used to do a lot with 3d graphical programming about lighting today. He told me that nowadays, ambient lighting is done with raytracing and voxels: For each voxel (can be any size) it is calculated how much light from the various light sources and reflections enters the voxel. The summed light then is the indirect ambient light.For clonk, this could look like this (see captions). (I assume that the sky material itself is a source of lighting in this example).
The lighting between the tiles could of course be interpolated, graphics cards are quite good with that. Or, we could define another tile-set for these interpolations. Another good thing would be that the light values of these tiles can be used to light the models as well.
What do you think of this approach, Peter?
I like this idea, though it still will have problems with properly handling small openings which should let light through but sometimes wouldnt be able to, I assume.
Certainly possible - that's a bit like how it was working before the change. And yes, doing reflection would then be easier. The main problem is that we want fast-moving lights with line-of-sight checks (well, at least I do). When done on such a coarse grid, that gives you very visible rounding artifacts. The best you can do is to try to hide them by slowly blending between versions.
I don't know, all I can say is that I kind of ran out of inspiration with this approach - whereas I still have a pretty long to-do list of crazy stuff I could add to what I'm currently doing :)
(Even though I'm currently a bit frustrated as the whole thing just semi-randomly stops drawing altogther. Using the time to try to work out properly how I want round shadows to work)
I don't know, all I can say is that I kind of ran out of inspiration with this approach - whereas I still have a pretty long to-do list of crazy stuff I could add to what I'm currently doing :)
(Even though I'm currently a bit frustrated as the whole thing just semi-randomly stops drawing altogther. Using the time to try to work out properly how I want round shadows to work)
Well, i was thinking of this being only one part of the light calculation - the ambient light, not a replacement or anything.
Well, this is a very "Jein" kind of thing. In one way this it is even what I'm already doing - just with a much finer grid (one pixel = one landscape pixel).
I have to read a bit between the lines here - I guess what your friend meant was *ambient* reflection? That's something I can comment on - and I have to acknowledge that it would be kind of cool to have the sun really flood your cave instead of having it "spotlight" as it would right now.
First, the good news is: I am pretty flexible once I have got this working - it's all about what kind of stuff you draw on the light map, after all. The ray data is merely the starting point, we are free to go nuts with any post-processing we want to do after that.
But. We must account for the fact that rays may change. And not only because of moving lights - the extreme case where all rays change - but also because of changing landscape. See above - if you open the roof of your cave, you must calculate everything that's connected more or less from scratch. You especially have to care about stuff that's off-screen.
And then there's the issue that proper ambient light is really expensive even on a coarse grid. Just doing blur probably might not cut it? Do we have to raytrace pixels separately?
Eh. Bottom line: Maybe I can figure something out. But at the moment I have too many technical doubts to promise anything. And there's still loads of stuff to do before we can think about these kinds of experiments. Let's get the basics working first.
I have to read a bit between the lines here - I guess what your friend meant was *ambient* reflection? That's something I can comment on - and I have to acknowledge that it would be kind of cool to have the sun really flood your cave instead of having it "spotlight" as it would right now.
First, the good news is: I am pretty flexible once I have got this working - it's all about what kind of stuff you draw on the light map, after all. The ray data is merely the starting point, we are free to go nuts with any post-processing we want to do after that.
But. We must account for the fact that rays may change. And not only because of moving lights - the extreme case where all rays change - but also because of changing landscape. See above - if you open the roof of your cave, you must calculate everything that's connected more or less from scratch. You especially have to care about stuff that's off-screen.
And then there's the issue that proper ambient light is really expensive even on a coarse grid. Just doing blur probably might not cut it? Do we have to raytrace pixels separately?
Eh. Bottom line: Maybe I can figure something out. But at the moment I have too many technical doubts to promise anything. And there's still loads of stuff to do before we can think about these kinds of experiments. Let's get the basics working first.
What about combining both approaches? Using a grid for the base landscape lighting, and adding local dynamic lighting by overlaying additive pathtraced brightnesses (you could easily switch pathtracing for the dynamic lighting overlay off, to reduce load for older computers).
After some grueling weekends sorting out corner-cases and producing really complicated algorithms for really easy ideas, a bit of progress: Nice round shadows, with guaranteed no overlap between triangles. Phew.
![[at]](/mwf/flags/at.png "Austria")
Michael the ceiling lamp never looked better. ;)
Next step will be to have light shine in all four directions, to get rid of the "ceiling lamp" phenomenon. I foresee more problems along that path though, so we'll see :/
![[ie]](/mwf/flags/ie.png "Ireland")
But can you keep the four directions addressable separately?
Internally, they will be handled separately anyway - I just run the same algorithm four times with different coordinate transforms, then combine the results (this is where the problems are likely to start).
Technically, it wouldn't be a problem to restrict light sources to arbitrary angle ranges where needed - but as usual there's a bit of legwork to do for that, so for now I'm aiming for the 360° case.
Technically, it wouldn't be a problem to restrict light sources to arbitrary angle ranges where needed - but as usual there's a bit of legwork to do for that, so for now I'm aiming for the 360° case.
![[ca]](/mwf/flags/ca.png "Canada")
Looks great! :)
yes looks great!
Can the light level be applied on the objects at that point (or per-pixel?) in the landscape too?
Yes, it can and will - per sub-pixel even once I increase the light surface resolution. That part "just" needs me to update all the drawing code to carry around references to the light texture, then calculate it in either by using multi-texturing or shaders. Nothing too funky.
Well, it's correct behaviour. Since we don't have a 3D landscape, there's no cheating around this one. I think the weird part is actually the lit chest. Might look less odd if shadowed areas weren't 100% black? I wouldn't put too much thought into that now and rather wait and see how lights will be actually used ingame.
Now with multiple directions! This should also illustrate why I need to put some effort into making sure the different sections are actually put together neatly.
cool!
BTW, are you testing this in a seperate repository? How can I have a look at the progress? Would it make sense to push the changes you made so far into a branch?
I am testing this on my computer ;)
As I said to Ringwaul - I want to get it into a state where it is roughly usable. Right now the whole thing is still a bit buggy, with some clearly wrong triangles appearing and MSVC complaining about memory corruption. Once I have stabilized it I'll commit a preview branch.
As I said to Ringwaul - I want to get it into a state where it is roughly usable. Right now the whole thing is still a bit buggy, with some clearly wrong triangles appearing and MSVC complaining about memory corruption. Once I have stabilized it I'll commit a preview branch.
Tiresome debugging with questionable tools in progress... The upper one is the input to the soft shadows algo, the lower the result. Who can spot the error?
My questionable tools were pencil and paper... I guess you are more advanced there ^^Bug: if the ray does not hit a wall at all it counts as if it hits a wall at the source point?
The source point is always at
And the bug was actually that the algorithm first decided that for a light size of 20, the full light would not reach the bottom of the "well", then trying to calculate the bottom-most full-lit point using a different light size (10 - see where it crosses the X axis). Sigh... never code when tired.
(0/0) - the light rays use a separate coordinate system internally, so I can easily transform it to cover different directions.And the bug was actually that the algorithm first decided that for a light size of 20, the full light would not reach the bottom of the "well", then trying to calculate the bottom-most full-lit point using a different light size (10 - see where it crosses the X axis). Sigh... never code when tired.
Edit: And if the ray doesn't hit anything, it counts as the ray stopping at the end of the field of view (that's what's happening at the "bottom", which is actually "left" in the landscape).
Okay, I have finally committed something into the repository - the new "lights" branch. I simply wanted to stop teasing so much and show how things really look like on my end. Which isn't too good, but should give some idea about where things are headed.
Warning to anybody looking at the code: This is very work in progress, so there's TODOs and not-quite-up-to-date comments all over the place.
Warning to anybody looking at the code: This is very work in progress, so there's TODOs and not-quite-up-to-date comments all over the place.
Are you already interest in bug reports (crashes) or not?
If so maybe you should make a bug tracker category for that.
Looks good (apart from the corner cases)!
If so maybe you should make a bug tracker category for that.
Looks good (apart from the corner cases)!
Hm, crashes are unfortunate. I thought I had those mostly worked out. If you can reproduce them, I'd like to have a look at it.
Maybe in a week or two, currently enjoying the fruits of being a phd.
Edit: a phd student (to be precise, I am not even close to graduation...luckily)
Edit: a phd student (to be precise, I am not even close to graduation...luckily)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
