"as I understand it the original yal was checking for the center of the texel to see if it is blocked, the update checks to see if any of the corners of the texel are blocked. For some reason it is putting a dark edge on it."
Ohh...
I understand now.
Yeah, the version of YAL which Um.. Marcus? released will do that. The version I released will not.
The reason his will do that is because:
Marcus sees if the light source can see the texel, rather than the other way around. This means the ray starts at the light source, and sees if a pivot located within the plane the texel is in is visible.
The result of this is that none of these pivots will be visible because the plane they lie in is considered to be in the way.
Marcus solves this by moving the surface far away in the scene. But apparently for some reason, with the setup you have, the adjacent quads are not being added to the same surface. So those quads are not being moved away. As a result the texels in the quad which your lumels is in might be partially under those other quads Marcus didn't move away from the scene, and thus they will be dark.
I have another way of solving this issue in my version. (But this isn't even an issue in my version because I cast from texel to light, not from light to texel) In my version I move the texel pivot away from the texel in the direction of the normal of the surface by a tiny bit. This allows Blitz to see it. No need to move the surfaces away, so surfaces which don't get moved can't block the light.
I don't know why Marcus chose to continue using the method he chose, when moving the lumel away from the surface should work properly 99.9% of the time.
That said, the last version I uploaded still had quite a few issues with it that needed to be solved. I wasn't happy with how it was working. I tried to light the "maplet" maplet level with my version of YAL and it messed up in several places badly. It's tough to test properly when you're testing with a square room with one square cube in it. :-) I should have made that room more complex during testing.
I'm also really unhappy with the speed. It's REALLY slow to lightmap this way in Blitz. I am of the opinion that one would never want to use YAL to light a real level like you'd find in a professional game. Ignoring the fact that YAL can only generate one large lightmap for an entire level, which greatly limits the lightmap resolution you can use, it would simply taake forever to lightmap the amount of geometry which would be found in a real level. I've got a 2ghz system and it was taking a hell of a long time to lightmap even the little maplet level, and no, I didn't have debug on by mistake. :-)
I'm sure there's got to be a faster way to do this. First off, I already know how to avoid casting 4 tays per texel and still get the same results as doing so. But even doing the 4 sample thing is inadequate in some situations.
I was thinking that one might be able to create a view frustrum with 4 planes for each lumel, but that surely would be even slower. But it would be more accurate.
If you did that though, you would almost gain the ability to have light sources which are area lights rather than point lights. If you can have area lights you can have much softer more realistic looking shadows which are harder near the base of the caster.
But there's still a lot of problems to be overcome doing that. I haven't figured that whole thing out yet.
Basically what you'd need to be able to do is determine how much of a sphere or rectangular solid a particular lumel can see. One way to do that would be to cast a number of rays instead of just one per lumel. But that would limit the accuracy of the blur by however many rays you had. You'd only have a 4 color gradient in the blur if you only did 4 samples.
Ohh...
I understand now.
Yeah, the version of YAL which Um.. Marcus? released will do that. The version I released will not.
The reason his will do that is because:
Marcus sees if the light source can see the texel, rather than the other way around. This means the ray starts at the light source, and sees if a pivot located within the plane the texel is in is visible.
The result of this is that none of these pivots will be visible because the plane they lie in is considered to be in the way.
Marcus solves this by moving the surface far away in the scene. But apparently for some reason, with the setup you have, the adjacent quads are not being added to the same surface. So those quads are not being moved away. As a result the texels in the quad which your lumels is in might be partially under those other quads Marcus didn't move away from the scene, and thus they will be dark.
I have another way of solving this issue in my version. (But this isn't even an issue in my version because I cast from texel to light, not from light to texel) In my version I move the texel pivot away from the texel in the direction of the normal of the surface by a tiny bit. This allows Blitz to see it. No need to move the surfaces away, so surfaces which don't get moved can't block the light.
I don't know why Marcus chose to continue using the method he chose, when moving the lumel away from the surface should work properly 99.9% of the time.
That said, the last version I uploaded still had quite a few issues with it that needed to be solved. I wasn't happy with how it was working. I tried to light the "maplet" maplet level with my version of YAL and it messed up in several places badly. It's tough to test properly when you're testing with a square room with one square cube in it. :-) I should have made that room more complex during testing.
I'm also really unhappy with the speed. It's REALLY slow to lightmap this way in Blitz. I am of the opinion that one would never want to use YAL to light a real level like you'd find in a professional game. Ignoring the fact that YAL can only generate one large lightmap for an entire level, which greatly limits the lightmap resolution you can use, it would simply taake forever to lightmap the amount of geometry which would be found in a real level. I've got a 2ghz system and it was taking a hell of a long time to lightmap even the little maplet level, and no, I didn't have debug on by mistake. :-)
I'm sure there's got to be a faster way to do this. First off, I already know how to avoid casting 4 tays per texel and still get the same results as doing so. But even doing the 4 sample thing is inadequate in some situations.
I was thinking that one might be able to create a view frustrum with 4 planes for each lumel, but that surely would be even slower. But it would be more accurate.
If you did that though, you would almost gain the ability to have light sources which are area lights rather than point lights. If you can have area lights you can have much softer more realistic looking shadows which are harder near the base of the caster.
But there's still a lot of problems to be overcome doing that. I haven't figured that whole thing out yet.
Basically what you'd need to be able to do is determine how much of a sphere or rectangular solid a particular lumel can see. One way to do that would be to cast a number of rays instead of just one per lumel. But that would limit the accuracy of the blur by however many rays you had. You'd only have a 4 color gradient in the blur if you only did 4 samples.