Lightmapping frustration

Blitz3D Forums/Blitz3D Programming/Lightmapping frustration

John Blackledge(Posted 2004) [#1]
I'm having a really frustrating time with lightmapping.
As stated in another thread, I am using Quill to lightmap, not model (god forbid); but loading in anything which has a reasonable polycount takes 20 minutes, then 10 minutes to lightmap.
LightBulb(Demo) to 40 minutes to lightmap the same model, then light bleeds under the walls!
Please would as many as possible reply, and tell me ewhat you are using for lightmapping.


Rob Farley(Posted 2004) [#2]
Giles I think will be the answer... Never used it, but from what I gather various blitzers would like to 'pleasure' Fredborg now.


Gabriel(Posted 2004) [#3]
Gile[s] - Easily the best thing ever written in Blitz.

It gives you so much flexibility with a bucketload of raw power and functionality. And best of all, it has the best interface of any Blitz app ever. And, of course, it uses x2 blending.

I'm rather embarrassed to say that I actually took a few hours away from work the other day to create a scene just so that I could see how Gile[s] lightmapped it. The scene wasn't for anything.. just wanted to play with the Global Illumination and shadows.


Rob(Posted 2004) [#4]
giles is commercial quality.


Rook Zimbabwe(Posted 2004) [#5]
Giles... without a doubt. I don't really have speed issues since I upgraded my cpu... Quill takes 20 min??? Dang!!!
-RZ
Athlon 64 3200+ 1024ram 80gigHD ATI9200 yadda yadda yadda...


John Blackledge(Posted 2004) [#6]
Thanks, everyone. You seem to be unanimous.


sswift(Posted 2004) [#7]
"LightBulb(Demo) to 40 minutes to lightmap the same model, then light bleeds under the walls!"

I'm not saying lighbulb is good or not... I haven't looked at it lately. But I'm pretty sure I've seen a screenshot form giles with light bleeding under a walkway connected to a wall in a red room.

But worse, Giles has problems with shadows leaking everywhere. Ie, every corner is darker than it should be. Looks wrong. Looks like Unreal actually. Gives it kind of a cartoonish look.

The problem is sampling texels from only one point.

If you sample with one point, either you can look to see if the texel can see the light, which results in light bleed, but no dark corners, or you look to see if the light can see the texel, which results in shadow bleed, which ends up being a much worse problem than light bleed because every single corner in the level has texels that are half in shadow. Of course some people like the look of shadow bleed, but nobody seems to like the look of light bleed, because light bleed makes the level seem non-solid.

The only way to solve this problem is to sample texels from multiple points, or to create a frustum that contains each texel and then determine if all of the frustrum is blocked from the light source.

I don't know if one could make a frustum method run at an acceptable speed... I'm not even sure how one would do it really... determining how much of the frustum is blocked I mean. But I do know that sampling from multiple points will only increase the time by the number of extra samples you take. So if you take four samples at each corner then you could quadruple the amount of work you have to do... OR DO you? But before I go into that... One problem with sampling only at the corners is that ligth can still bleed under walls in extreme cases, like a sharp corner poking into a texel of a lightmap which is low res. But it greatly reduces the problem.

Now... how does one take more samples of each texel without doing extra work?

Well, consider this. Each corner of each texel is shared by four texels. There's no reason to sample the same point four times. So, if one works from the lightmap, one can sample just the corners of texels and transform that point to the world, and then figure out whether or not the texels that surround that point are lit or not. And in this case you would go from light to texel, not texel to light. Doing that, if the light sees the texel corner, then all four texels that surround that corner are lit. Once you know that, you can figure out how bright each is by interpolating between the color of each corner after you've calculated all four corners for that texel.

Of course I've gone way off track here with this discussion but maybe some of the lightmapping folks will find it useful to improve their lightmappers.


Rob(Posted 2004) [#8]
Gile[s] is perfect IMHO. It is up to the user to make it crap or shine.

If you apply a 256x256 texture to an entire level, you're gonna get bleeding on everything including 3dsmax, believe me.

If you know how gile[s] works or you run the auto lightmap wizard, then it's very doubtful you'll ever meet bleeding.


sswift(Posted 2004) [#9]
If that's true then why do their own screenshots show light bleeding? Are you saying they, the authors of GIles themselves, don't know how to lightmap a level?

I know how lightmapping works, and it is IMPOSSIBLE to correct these issues completely without using the "frustum" method I outlined above. But increasing the number of samples per texel and using smarter sampling methods like the 4 corner optimization I eoutlined above are a good start. Just the 4 corner thing alone will fix most cases, even with low res light maps. And it doesn't cost you any speed. So it's worth implementing.

I'm not slighting Giles. Most lightmappers I've seen have these problems. But that doesn't mean they can't be fixed.


MadJack(Posted 2004) [#10]
I have to agree with Sswift.

I did a quick test with Giles vs Luminescence beta. Giles showed 'leakage', L3d did not and seemed to show better overall fidelity.

However, although L3d was due to be released last month, it wasn't and the website hasn't given any news about why not, which isn't encouraging.

www.insight-concepts.com


MadJack(Posted 2004) [#11]
If anyone's interested, I can post the b3d geometry I used for the test.


Zethrax(Posted 2004) [#12]
Sounds like your next lib should be a lightmapper then, Sswift (not just another addition to YAL, which was slow as a wet week when I last ran the demo).


Dreamora(Posted 2004) [#13]
light bleeding should be out since 1.21 ( was a known problem before that which resulted in a quite specific way of setting up the light bias value without the advanced lightmap setting possibilities like we have them now )

haven't seen it since then with GI settings anymore.
For an actual screenshot check out http://www.frecle.net/forum/viewtopic.php?t=18

I think this shows quite good the power of Gile[s]


sswift(Posted 2004) [#14]
"Sounds like your next lib should be a lightmapper then, Sswift (not just another addition to YAL, which was slow as a wet week when I last ran the demo)."

No money in it. :-)


"light bleeding should be out since 1.21"

Well if you have fixed something maybe you should update your screenshots. :-) People do look at screenshots to make purchasing decisions... don't give them a reason not to buy. :-)


fredborg(Posted 2004) [#15]
I will update the screenshots :) I'm very busy with my graduation project, so I haven't had time to do much on gile[s] for the past few months.

One might say the same about your demos Sswifty lad :)


sswift(Posted 2004) [#16]
MY demo screenshots ARE up to date, so I don't know what YOU are talking about. :-)


Rob Farley(Posted 2004) [#17]
Speaking of your systems Sswift... Can I have you shadow system for free please?


Dreamora(Posted 2004) [#18]
sswift: yeah your screenshots are up to date ... at last for most systems ... the shadow system demo is several versions behind if I'm right ( actual version is 0.9x or something like that ... :) )

btw: sswift i payed over paypal for shadow sys, how long does it normally take to proceed