lightmapping question

Blitz3D Forums/Blitz3D Programming/lightmapping question

jfk EO-11110(Posted 2007) [#1]
I am currently doing some tests with a lightmapping code that I write from scratch, just to try out some ideas I had. Now to fix the problem of the socalled "bleeding seams" I will check the visiblity of a location seen from the lights position (and not the other way round), this solves the issue almost perfectly. A pivot on the surface of the mesh is checked with entityvisible from the lightsource.

But this won't work with alpha and masked textures. How would you mod the EntityVisible method to make it work with alpha and mask modes as well?


jfk EO-11110(Posted 2007) [#2]
nevermind, got it almost working. No sophisticated maths, just a quick'n'dirty hack:

(basicly)
test if light can pick pivot. yes? it's fully lit.
no: entitycolor mapmesh black, fx17, do a 1 pixel renderworld towards light dummy mesh, other than black? no: must be obscured by opaque tri.
yes: must be alpha or masked texels: set entitycolor of mapmesh to white, render the pixel again, then multiply light color * renderd rgb.

There is still a strange problem when I use alpha and/or masked textures then I get eg. strange artefacts on the lightmap. Guess that's only a bug or so.


Danny(Posted 2007) [#3]
1 pixel renders? wow that's pretty sneaky ;)

What I did with my vertex lighting to prevent bleeding - or at least 'soften the blow' was to slightly 'blur' the map afterwards. Yes you will still have 'some' bleeding, but it (litterally) softens the effect and you can call it 'global illumation' instead.
And actually I liked the effect of light being able to 'bleed around the corner' just a little.
Perhaps you can use this with the lightmapping as well??

Just a thought..

-Danny

p.s. about the artifacts might that perhaps be because your pivot is EXACTLY IN the surface you're trying to test?
And get similar artifacts when you have 2 planes sharing the same space & try to render them?
If so, maybe offset the pivot by a fraction - along the normal of the surface ??


jfk EO-11110(Posted 2007) [#4]
thanks Danny. I already have a little offset for the pivot, away from the surface normals. So it´s not a z-fight of shared locations.

The one-pixel render is actually pretty fast! But there ´s a problem when you want to detect a lights dummy mesh that is relative far away. Since the entire render is only one pixel, the light dummy mesh must be big enough to be seen. So the choice is: scale the light dummy mesh (may cause unwanted intersections) or use a very high camerazoom that makes distant things bigger in the render.

I do however get these artefacts, it's as if the lightmap is applied to the shady side of the masked parts of the mesh - I don't get it right now. Up to this point the whole thing was straight forward Brain>Code>Screen, but this is really confusing me.

(Simple) global illuination is perfomed in a very easy way: simply take a 32*32 pixel render from the surface pivots position, the cam aligned to the tris normals, then calculate the average RGB of the render, mix this with the other lightmapping texel data. Mixing is a littke tricky since you don't want to add this, so you have to subtract the relative rgb amount to "tone" the texel. It may also be a little darker after "toning" because a filter (like eg. stained glass) will always reduce the light more or less.

Bleeding is ok in some situations (eg. when it looks like a little dirt in the corners), but in some other moments it sucks. So I really wanted to get rid of it in the first place.

Antialiasing would be the first choice. Blur is an option, but it will also blur the shadow contours on geomerty.

I'm not sure, maybe I should post the source as it is. At the other hand I don't want to offend some people who are selling lightmappers around here.


Danny(Posted 2007) [#5]
That's pretty cool stuff you're doing with those little renders. Never considered tricks like that - although I've never done anything serious in the lighting department ;)

don't want to offend some people who are selling lightmappers around here
LOL! No you don't want the lightmapping industry to crumble, I can imagine - But I won't stop you ;)

Could you perhaps post an image (before/after?) of the effect you're trying to get rid of?
Is this only happening though alpha/masked textures? Again, I don't know anything about it, but could easily imagine that texture interpolation has a impact on it. Could you for example in stead of a 1 pixel render, do it with a 16x16 render and see if you get similar results (in the hope that a larger render will produce better texture interpolation/render and thus a better/more 'accurate' result???????????)

D.
p.s. You got Fog switched off right?! :)


Wayne(Posted 2007) [#6]
I say post it, maybe it can be made faster than YAL


Gabriel(Posted 2007) [#7]
I say post it. I've always been interested in lightmapping and raytracing, all that sort of thing, but never had the time to really read up on it.


jfk EO-11110(Posted 2007) [#8]
Well my code is a hack and I got to clean it up a little first, but if some of you will try to fix the strange artefacts issue then I´ll post it ASAP.


_33(Posted 2007) [#9]
Is it some real time sort of thing? Are you rendering textures, or doing it per vertex?


Wayne(Posted 2007) [#10]
I have YAL working, but it's not optimized at all.
I'm considering dividing the triangles up into 3d bounding boxes that make up the volume of the model, and test for ray collisions on those first.

I'm also considering the unique color scheme, where one applies huge 2048x2048 (or smaller) texture (unique colors), takes a picture from the light source, compares the colors that are seen, and makes them lit for the light map.

I think I need to unweld and remap the UV's so I can properly apply the texture to any b3d model to make it work. My experience with earlier experiments has shown while it works it's grainy and spotty like a bad photo.


jfk EO-11110(Posted 2007) [#11]
Far away from realtime. A simple lightmapper with a GI feature. I was a bit tired of the YAL yet another lightmapper source since the coding style feels somewhat alien to me and I hardly can modify it productively, so I started something from scratch. But as I said, it still needs a ton of optimation and bugfixing.


jfk EO-11110(Posted 2007) [#12]
Ok, here it is! I'd be really happy if some people help to solve the mentioned issues.




jfk EO-11110(Posted 2007) [#13]
BTW, Wayne ("...I'm also considering the unique color scheme, where one applies huge 2048x2048 (or smaller) texture (unique colors), takes a picture from the light source, compares the colors that are seen, and makes them lit for the light map....)"

Wow, this could be great, got to think about it... to bad I started with the above thing :) The planar mapping may however be useful for both, as well as the still missing UV packing.

EDIT: currently I have no idea how you could use the ICU scheme together with alpha textures and/or geometry... any ideas? (Where for masked textures it's perfect!)


jfk EO-11110(Posted 2007) [#14]
knock knock


Wayne(Posted 2007) [#15]
I went thru the code and played around with it some.

It appeared to me that alpha and masked surfaces are being light mapped.

How would you like alpha and masked surfaces to behave ?

Do you want alpha and masked textures to receive shadows?

Ran pretty well overall

I agree packing needs work
8 )



Do you want alpha and masked to cast shadows (colored) ?


John Blackledge(Posted 2007) [#16]
I like it!
Wayne and jfk gets their heads together over a whole new lightmapping system.
Go for it, guys.


Wayne(Posted 2007) [#17]
I examined the red object more closely and I see what you mean. The black artifacts.


jfk EO-11110(Posted 2007) [#18]
Yeah, thanks!


Danny(Posted 2007) [#19]
sorry, been playing with the code, but still having trouble trying to figure out what you're doing and how ;) - let alone trying to figure out what might cause those artifacts...


d.


Danny(Posted 2007) [#20]
I saved the lightmap (lima_img) to a bmp file to check it out.
In that image itself I think you can see what's causing at least some of these artifacts...
Even on straight horizontal edges in the bmp you will see gaps and irregularities - and chunky pixels on slopes.
I'm nearly sure this is to rounding & inaccuracy of the routine that's supposed to decide from 'where' to start checking for light input.

If you're familiar with Lightwave you might recognise the term 'Relative gap size' when you let LW create an atlas UV map - in stead of placing all the tri's in the uv map straight together - it will create a small gap in between the poly's.
I think the solution is that besides prepping your uv map like that, you then need to calculate the light not only ON the edges of poly's but also 'slightly OUTSIDE' those edges (filling that relative gap size in your uv map). So when mapped back on your geometry - you won't see these 'dirty edges' as you see them now.
Not sure though if this will also fix those smudges you got especially on the red cylinder...

Hope this helps,
Danny


jfk EO-11110(Posted 2007) [#21]
Thanks for your help Danny. I think the gaps and irregularities you see are caused by the draft-set scanner stepwidth. You have to lower this stepwidth "sstep", probably down to 0.5 to make sure every texel is also scanned. Once reduced to 0.5 you may also replace the RECT texel drawing code by the PLOT texel drawing code. but be aware, a stepwidth of 0.5 is going to take 16 times longer to render than a stepwidth of 2.0.

This is why it really needs to be speed-optimized.

There is already a variable named "margin" that allows to set a gap between the edges. And the scanner will start scanning at x1-1 to x2+1, so the whole triangle should be covered. It may be neccessary to use multiple picks, or a higher picking radius to make sure the edges are picked accurately, in this point I agree with you. But I guess this is not the cause for the masked textures problem.

Well, Waynes Idea of the ICU lightmapper is still in my head and as soon as I have an idea on how to solve the alpha problem I will try to prototype it.


jfk EO-11110(Posted 2007) [#22]
Any news about this?


Wayne(Posted 2007) [#23]
I'm testing this with new ray casting code. ODE and Newton.


jfk EO-11110(Posted 2007) [#24]
Thanks Wayne. new ray casting code sounds good.

A Packing function is still required, for those who have too much time.

As for the checkerboard artefacts I think I know the cause: It's a rounding error sawtheeth artefact by the alpha/mask determination: at a certain distance the light dummy mesh may be seen by one texel, and not by it's neighbour and so on. So the bad guy in here is the one-pixel render. This may be solved by doing eg. a 16*16 pixel render - maybe. But this would be even slower.

Right now I tend to try your ICU suggestion and simply skip the alpha support. Masks would still be supported this way. This is so dead simple and incredibly fast. Imagine: only one six-sided render for every light, then do some readpixelfast, all done! This must take not longer than a few hundred millisecs to lightmap an entire map.

Again I see probems with rounding errors, a well as with texture filtering that may cause false colors (flag 256 may or may not fix this).


Danny(Posted 2007) [#25]
sorry jfk, I haven't had much time to play these days.

But yes, what you say is what I suspected earlier. Still, if increasing the resolution (16x16 pixel render) is very slow - you could use it as an option for 'final quality render'.
Sure long render times suck, but if the end result is worth it; Still better than the alternatives I think..


Leto(Posted 2007) [#26]
Sounds great - I hope this project continues :)