Talk:Lightmapping levels: Difference between revisions

Talk:Lightmapping levels (view source)

Revision as of 16:13, 9 December 2021

6,466 bytes added , 9 December 2021

brain dump on sensible lightmap texel sizes

Geyser

Administrators

5,389

edits

@@ Line 34: / Line 34: @@
 http://edt.oni2.net/images/Warehouse_LM.jpg
 :[[User:EdT|EdT]] 03:09, 26 November 2010 (UTC)
+----
+Copy-pasting a translation of my own elaborations on lightmap texel size (and the adequate size/resolution of a level's lightmaps):
+:Good to know: Oni's developers have set a limit of 1GB for overall texture memory (this was regarded as "limitless" at the time).
+:Good to know too: According to the 0x7C float in [[OBD:AKEV|AKEV]], the lightmap texels once had a standard world size of 12 inches = 1 ft = 30.48 cm.
+:One gigabyte of texture memory is indeed limitless considering the texture size of Vanilla game data. There are relatively few textures in a level, and even when fully decompressed (i.e., after conversion to BGR888 or BGRA8888) they aren't even close to 1GB. For example, if you take all the textures contained in the Vanilla level1_Final and unpack them to 32-bit BMP, you get only 21 MB. And even if you globalize all TXMPs and load all of them at once (never happens, as it would require simultaneously displaying all character/weapon/particle classes and all kinds of environment), the overall size would still be about 60 MB. The additional storage of MIPs leads to a 4:3 size increase, so the actual memory usage would theoretically rise to 28 and 80 MB, respectively.
+:In the case of lightmaps, textures are fundamentally not shared across geometries, and the "texels" accumulate in proportion to the surface area of the environment. If every polygon is assigned an lightmap UV and texture, then each square meter of a level's surface corresponds to N unique lightmap texels, and each texel (assuming uncompressed storage) is taking up 4 bytes both in memory and on disk (5.3333 bytes if you count MIPs).
+:Imagine a bunker-like level (no exterior), consisting of rooms that are 10x10 metres across and 5 meters tall. Each such room has a surface area of 400 sq.m (100 sq.m for the floor, 100 sq.m for the ceiling, and 50 sq.m for each of the four walls). If the bunker consists of floors, with 25=5x5 rooms on each floor, then each floor will have a surface of 10000 sq.m. If there are 10 floors (i.e., 250 rooms in total), then the total lightmappable surface is 100000 sq.m. At this point there is no furniture or stairs. As for doorways, we can adapt them to the thickness of the walls or ceilings between the rooms, in such a way that the presence or absence of a doorway does not affect the surface: for example if there is a 2x2 meter door through a 1-meter-thick wall, then the addition of four side polygons (2 sq.m each) exactly compensates the deletion of the two doorway polygons (4 sq.m each).
+:If we are willing to believe that Oni's lightmaps used to have around 10 texels per square meter (actually 1 sq.m = 10.764 sq. ft), then 100000 sq.m amount to 1 million pixels, i.e. 4 megabytes of lightmap textures stored as 32-bit RGB or RGBA (not counting MIPs). The much more compact DXT1 format is not suitable because it doesn't handle subtle gradients well - at least with the default compression algorithms. One could consider JPEG compression, but it's separate discussion, and it wouldn't affect the size of the uncompressed textures in memory, only the disk storage in TXMPs.
+:So, we have 4 megabytes of texture memory (not counting MIPs) for a 10-floor bunker with no furniture: 25 rooms per floor, each room measuring 10x10x5 meters.
+:Next we start adding some basic furniture: cubes with the bottom face missing. A 1x1x1 meter cube ("washing machine") has a surface of 5 sq.m. Four half-meter cubes (1.25 sq.m each) contribute the same 5 sq.m to the total, whereas larger cubes, measuring 2x2x2 and 4x4x4 meters, contribute 20 and 80 sq.m respectively.
+:For simplicity let's say that in each room of the bunker we have one huge 4x4x4 meter cube, one big 2x2x2 cube, ten 1x1x1 meter cubes and 40 half-meter cubes. The total contribution (per room) is 100 sq.m for the two large cubes, 50 sq.m for the 1x1x1 meter cubes and another 50 sq.m for the half-meter ones, thus 200 sq.m contributed by the furniture (per room), or 5000 sq.m per floor, or, for the 10 floors of the bunker, 50000 sq.m, i.e. exactly half of the surface taken up by the walls/floors/ceilings/doorways. For more detailed furniture its surface can grow several times larger, but for now let us remember that the rooms (walls) of our bunker are taking up 100000 sq.m, and the furniture takes up about half of that. If we convert this to pixels and megabytes, then we have 4 megabytes (1 million pixels) for the walls and 2 megabytes (half a million pixels) for the furniture. Considering MIPs, the total size will be 4:3 larger, i.e., 8 megabytes in total.
+:Now let us see what happens if we reduce the size of the lightmap pixel. For inch-sized texels (taking 1 in = 2.5 cm for simplicity) one square meter will hold 1600 pixels instead of 10. So the rooms will take up 160 million pixels (640 MB) and the furniture will take up 80 million pixels (320 megabytes). The total is 960 MB for lightmaps (1280 considering MIPs), which is in excess of Oni's 1-gigabyte threshold for texture memory, even without adding all the other textures required by the game.
+:Clearly inch-sized lightmap pixels (and the texture memory usage that they imply) are completely out of proportion with the rest of the game data, whereas foot-sized pixels are much more sensible.
+:Arguably foot-sized pixels are too coarse for a good visual impression, so one could consider slightly smaller 20-cm pixels: since 20 cm = 8 in, using 20-cm pixels for the above bunker example will divide by 16 the figures obtained for inch-sized pixels for for the surface area and the texture memory. 10 million pixels for the rooms, 5 million pixels for the furniture, and 40+20=60 MB for the storage (or 80 MB considering MIPs) - which is commensurate to the size of non-lightmap textures for a moderately detailed level as well as to the size of a level's non-texture game data.
+:At the very most, a 10-cm pixel size can be considered, which would correspond to 60 million pixels for the bunker example, and 240MB of texture memory (320MB considering MIPs). These are large texture sizes, but they could be justified if all the game data scaled accordingly (detailed 512x512 textures for all geometries, and a similar increase in detail for the geometry itself). For such a hypothetical "HD Oni" the size of a level could grow to about 1GB, and the texture memory usage would approach the 1-gigabyte limit.
+::[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 17:13, 9 December 2021 (CET)