YAL lightmapper - light leaks and shadows problem
Blitz3D Forums/Blitz3D Programming/YAL lightmapper - light leaks and shadows problem
| ||
| Hi everyone, I'm using a tool called BSP Factory to create 3d maps in. It uses the YAL lightmapper, and as you can see from the pictures below, shadows don't start from the right point, and light leaks through the geometry. In this example, the light behind the wall somehow leaks through: http://invis.free.anonymizer.com/http://www31.brinkster.com/mrchrisgreen/temp/yal1.jpg In this shot, the shadow of the box does not start at the base of the object: http://invis.free.anonymizer.com/http://www31.brinkster.com/mrchrisgreen/temp/yal2.jpg Any ideas why this is? I believe the program uses the bleeding-edge fix that sswift made a couple of weeks ago, but it isn't using the final code that was added to the code archives. Thanks! |
| ||
| There is a fixed version of YAL that was done a few days ago but it introduces a new bug. If two of the lightmapped polygons are coplanar you can see a noticeable shadow along the seams and the SUNLIGHT and POINT_LIGHT light types were removed. Your ligting problem would be fixed by that version. |
| ||
| I think the solution to the problem would be to add a texel boarder to each polygon on the lightmap and duplicate the outer texel shade to that outer boarder. |
| ||
| "If two of the lightmapped polygons are coplanar you can see a noticeable shadow along the seams" Come again? If I'm interpreting what you say right, that would mean almost ALL walls would have a diagonal shadow on them. |
| ||
| put 4 quads coplanar and try a light from a distance. 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. I also get a few triangles on meshes that aren't lighting properly. Haven't had time to dig into it and figure out how to fix that. I was going to try another way of combining lightmaps for multiple meshes on one texture. My levels are built sort of out of lego blocks. premade meshes and I have YAL cycling through the level and lighting each mesh in its correct position with the same lights, namely sunlight since it's out doors. Your update looks like it works better for indoor levels and maybe that's where the difference lies. |
| ||
| "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. |
| ||
I'm working to improve YAL at the moment, now it uses vertex normals to smooth out the result: To speed up YAL we need to speed up the raytracing (the slowest part, if you turn off the shadows the lightmap takes only a few seconds to finish), we can do it by using BSP trees for example. |
| ||
| Thanks for the replies, I can't follow most of what you say sswift as I'm none too hot with math and hardcore 3d. @Marcelo: Speed is not a major concern, as generating a static lightmap is very much a post-production tweaking process (well, for myself). I'd be happy to wait an hour or so for a good quality render. Back in the days of POVray I'd leave a sphere being raycast overnight :O And I hope to see the new YAL in action soon :) |
| ||
| In my levels to speed up the lightmap rendering I do use a sort of culling to hide all but those map-lego pieces that are immediately surrounding the mesh being lit. The lightmap is saved for that mesh only. I saw very little fps hit when I ran it in the game. That method did greatly speed up light mapping though |
   |