   Static Lightmaps - Radiosity Simulator
  So I'm having troubles with the radiosity simulator for my 2d sidescroller engine - both of which are written in c++, by me, from scratch. The radiosity simulator builds a lightmap when the map is compiled. The lightmap consists of a giant square texture which gets blended (multiply) over the scene when the map is played. I got this setup to work, but I'm not happy with the quality of lighting.First, it looks pixelated and blocky and horrible. Now the easy remedy for this, is to increase the texture resolution. But suppose I want a 128x128 size map, and I want 16 sample points (I think they're called luxels or something?) per tile, that's a whopping 2048x2048 texture (can older video cards support loading & rendering textures that big, in opengl??). The other solution would be to have the radiosity simulator anti-alias the lightmap, but it already does that and it doesn't help much.The other problem, is just in general, the lighting quality is pretty crummy. I'm basically running this (simplified) algorithm for each sample point:for each samplepointfor each lightintensity => 1if (intensity > light.maxdistance) then intensity => 0if (not samplepointIsInLightCone( samplepoint, light )) then intensity => 0if (raycastHitPoint( light, samplepoint )->Distance( samplepoint ) > 0.5) then intensity => 0samplepoint.r += light.r * intensitysamplepoint.g += light.g * intensitysamplepoint.b += light.b * intensity// NB: If r, g or b exceeds 255, clamp it to 255nextnextThis produces the following results. Before compile:(One fluorescent blue light, one tungsten bulb brown light, both pointing towards the center point)After compile:Without blend:As you can see, the lighting looks crummy and my lights fail to emit realistic lighting as seen in the real world. Tungsten lighting + fluorescent lighting adds up to white. Google has failed to find me any sort of radiosity algorithms and I don't want to buy/implement someone else's simulator. Has anybody here got a better idea/algorithm for calculating the colour value at any given sample point?   
  Do some falloff.light.maxdistance = distance from light / radiusAnd same thing on the edge of the spotlight. There is a dense lighting in the middle, and fade to black on the edges.It will look way better, and you will almost lose that blocky look.EDIT: Also, the shadows might look blocky too. You can blur that texture in the end. To smooth everything up.   ;  you should generated that in higher resolution and then sample it down (if performance of generation is not that critical), this way you'd get at least wird of those jaggy edges.rendering 2d doesn't mean you have to light it in 2d, you could still asume every normal is pointing towards the screen (or later on you might want to have normalmaps), therefor you could move the light source slightly above the image plan and do usual 3d math.beside that, there is a very nice article about 2d lighting on this every gamedev.net, http://www.gamedev.net/reference/programming/features/2dsoftshadow/;  I already have falloff, two values of falloff in fact - lower and upper, the light is at full intensity until it reaches lower, then it fades away as it approaches upper. I don't have falloff on the edges of the spots though, the "penumbras". I'll take a look at that article Krypt0n, it looks useful - although I'll probably still be sticking with a static texture over the top, I can probably make use of some of the concepts.I also found a nice article about radiosity on wikipedia, using patches, it even gives maths formulas. My radiosity code is in a big mess atm (it's all in 1 header file!!!) so I'm gonna recode it all using the patch thing and hopefully it will work out better.   ;Quote:Original post by thomasfn1I already have falloff, two values of falloff in fact I don't see them in the screenshot. And that will certainly fix most of your issues :)And I like Krypt0n idea of simulating 3D maths, and use the normal for a more realistic effect.   ;  Sorry for the late reply.I've completely rewritten the radiosity code now (no more messy everything all in 1 header), it works much better. I also implemented angular falloff and revised distance falloff.Looking much better, still a bit pixelated especially near the light source itself but once the simulator is actually running passes and filling the space with more light generally it should be fairly unnoticeable.Next on the list is optimising the thing so it doesn't take 4 minutes to perform 1 pass.But then again, can you optimize something that requires ~4 billion loop revelations to do 1 pass of 256x256 patches?   ;  If you don't want to use a 2048x2048 texture why not split the lighting up into 4 1024 textures? That way it will be supported even by older cards.Simply do your calculations on a 2048 texture then split that up into quarters when you load it in. You could do a check to see what the highest res texture the GPU can handle and if it's smaller then 2048 then do the split.You really aren't going to be straining even older GPUs with something like this.   ;  Besides from coding tricks, you can optimize with interpolation. Although it can slightly reduce quality again. Instead of calculating each pixel, you can do it alternatelyx 0 x0 0 0x 0 xLet's say you first calculated the x pixels. Then for the 0's, check the neighbour x pixls. If they all have the same value (with a certain threshold), you can assume this pixel will be the same as well. Instead of calculating it, you can simply use the average value of the neighbours. If one or more neighbours differ too much, then calculate the 0 as usual with the full math.Check this link for some more details. Somewhere on the bottom optimization tricks are handled.http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htmThat said, there is a risk you'll miss small details though. So it's really a performance versus quality issue. But you could play with an adjustable threshold parameter of course, and see how it works out.Greetings,Rick   ;  The interpolation thing is already happening, to some extent. If I lower the lightmap quality, say from 8 to 4, it will build a 4x32 = 128x128 size lightmap instead of a 8x32 = 256x256 size lightmap and space out the patch size accordingly. Then just render the thing using linear filter and let opengl interpolate for me.And splitting up the textures at runtime shouldn't be hard either, I'll have a crack at that when I need to expand the grid size.   ;Can I make one suggestion? I think it would look way better with a more aggresive distance falloff. Unless you want it the way it is, of course.   