   Texture Maps Instead of kd-tree in Photon Mapping?
  I have currently been messing around with photon mapping to calculate and then save light maps (that include indirect illumination) for 3D scenes. In the process of doing this I have noticed that I can skip creating a kd-tree and just store the photon values in a light map texture that is accessed based upon the UVs of my models.Assuming the texture data isn't mapped to two different surfaces and that the maps are of sufficient resolution this seems to be producing reasonable results.Has anyone else tried going directly to texture maps to store photon values, or is there a better way to be doing something like this?   
Quote:Has anyone else tried going directly to texture maps to store photon values, or is there a better way to be doing something like this?I'm doing it that way as it's simpler (and I like straight forward solutions), it allows to keep constant memory amount and you can preview the scene while it's generated, that way artist can still edit a lightmap compilation while running it and restart if the result wasn't as expected.Quote:Original post by richardmonetteIn the process of doing this I have noticed that I can skip creating a kd-tree and just store the photon values in a light map texture that is accessed based upon the UVs of my models.Assuming the texture data isn't mapped to two different surfaces and that the maps are of sufficient resolution this seems to be producing reasonable results.I had several problems, 1. some texels (on borders of triangles) are getting far less hits, as their area in the level is quite smaller, one solution I came up with is to calculate their area and takin that into account, but still, it's not trivial and although it works out, it's more noisy on borders.2. As I have one texture per triangle during generation (for simplicity) another issue that arrises with borders is that you can notice the triangles on the texturemap due to the hits that are not 100% equally distributed, my solution was at first to merge co-planar areas that are connected, but artist managed to fuck that up. so now, every hit is managed like a sphere, after the hit position is known, I query into the bounding tree with this sphere and every triangle that intersects with it gets that photon added it it's texture. notice, that sometimes the photon hit is actually even outside the triangle area, but this also reduces filtering issues quite a lot, so it reduces another issue that is related to lightmaps in general :).the final stage is to collapse those individual triangles into groups, by also colapsing the textures, there I had to generate the UVs in worldspace, merging ends up in accumulating texels. once this is done, I do some dilation filter to get rid of color bleeding on borders.at the moment i'm workin on texture atlas generation/packing, but as I was using quadratic textures, it ends up searching for space for those quads which is a way simpler than texture packing per triangle (and some programs do that, at least pervious that I wrote :) ). on my list is to test mipmaps, my pervious experience with lightmapping were painful with mipmaps, lot of bleeding between textures which result in bigger borders etc. but with this quad approach I hope to get some better results.also on my list is compressing quads, by reducing the resolution if the content of the texture is very smooth, my previous experience in that is also painful, as it's usually not about the content of the actual texture, but more about those that it share's the border with. sometimes you might thing you can 'compress' it to one texel and it's fine, sometimes some neighbor textures/triangles share a border with a fine gradient and you instantly notice the border after this compression. but again, my hopes are that using quads reduces that issue :)