Archived

This topic is now archived and is closed to further replies.

Combining Lightmaps

This topic is 5308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, Not entirely sure which forum to post this in, but i suppose its kinda relevant here. Im currently implementing a system whereby each polygon in my scene (BSP Tree) creates its own texture for use as a lightmap, however, this is expensive in terms of switching texture states, so i considered the problem and decided each polygon should reference a section of a larger lightmap held at a parent node further up the tree, therefore a whole branch of the tree can be rendered without having to switch the lightmap. So, on to my question, is there an existing algorithm for combining textures of varying sizes into one larger textures. I am thinking each lightmap will be 512x512, and each dimension of the sub lightmap will be either 8 or 16 or 32. So not always guarenteed to be square. Thanks for any help you can give.

Share this post


Link to post
Share on other sites
If I understand correctly, you are asking for something like a packing algorithm for rectangles into larger squares. The trouble is, you want as many 'nearby' rectangles as possible in the same square (lightmap). I don't know how to do this (well), but there's an extra google keyword for you to try - 'packing'.

[edited by - g on June 5, 2003 9:20:36 AM]

Share this post


Link to post
Share on other sites
There is an algorithm for packing lightmaps, which uses binary trees. You have a large lightmap (512x512), and you try to find free space on it, in which a smaller lightmap can fit. I don''t know exactly how it works, because i didn''t understood it!!! But you can search "lightmap packing" in Google and find it out.

An other way of doing lightmap packing is the following.

1) Calculate connectivity between every polygon in the BSP. I mean not only connectivity for one leaf, but for all the polygons in the tree. Thats it, a polygon from one leaf, can have an adjacent polygon from an other leaf.

2) Calculate every polygon''s projection plane. This is, the plane you calculate for making up the lightmap as normal.

3) Initiate the packing loop, by making one lightmap, which have only one polygon in it (the first polygon). Put this lightmap in a vector(???).

4) Begin the loop. For every polygon, that hasn''t a lightmap so far, check to see if it can fit in an existing lightmap. If it can fit, push it to this lightmap. Else, make a new lightmap, push this polygon to it, and push it to the lightmap vector.

5) Clean the lightmaps, by trying to fit their polygons to an other lightmap. In this step you don''t create any other lightmaps.

6) Repeat step 5 as necessary!!!

About fitting a polygon in an existing lightmap. First of all it must have the same projection plane as the first polygon in the lightmap. If it hasn''t then it can''t be put in this lightmap.
If it has, check if it is adjacent to a polygon already in lightmap''s polygon list. If it hasn''t, it could fit, but it couldn''t!!! Who knows. There may be overlap with other polygons in the list, so you will mess it up. So if it hasn''t dont put it here. It will fit at the clean step!!!! If it has an adjacent, then it is guaranteed that it fits.
Now, about connectivity. In case to say that a polygon is adjacent to an other, it isn''t necessary to share two vertices. They may share an edge, so it is not enough to check their vertices, but you must check the edge line equations, in case to say that they share an edge.

I think i said it all. The results are better than having a single lightmap for every texture, but it is worst than the algorithm i said in the beggining! I don''t have code at this moment, but if you want some i''ll post it when i return to my pc. And something last. It has many limitations, some of them appear in the steps above, and some will arise while implementing it. But it''s a start, isn''t it??? It will help for texture switching, and for disk space. But a better approach for less disk space, is by making your own format of texture, that will hold all the lightmaps for a single level. In this case, and if you are using compressed textures, you can save many kb!!!

I hope that helped.

HellRaiZer

Share this post


Link to post
Share on other sites
I simply use a quadtree/brute force combination to pack lightmaps into textures. Takes longer, but it''s a preprocess anyway, and it packs very tightly. I never thought about making it faster. If I wait 30 seconds for the packing, or 5 minutes, doesn''t really make a difference for me. If you consider, that good quality radiosity solutions take 2 to 3 days to compute...

Share this post


Link to post
Share on other sites