Talk:Lightmapping levels

There was probably some thought behind rendering particles between the env and the shadow: Oni has no sharp shadows, and it allows the particles to be rendered in the same light\shading that the env is in.

...if that makes any sense. Gumby 21:05, 4 October 2010 (UTC)

No, this doesn't make sense, for at least N reasons.

1. An object can totally be in plain light even if there's a shadow somewhere behind it, along the line of sight. My screenshot is a good example of such a situation: the Screaming Cell is not behind the pillar, where the shadow lies, and yet in the rendering pipeline the sprite is "trapped" between the opaque env and the transparent shadow quads.
2. Most particles are various flashes and glows, which shouldn't be affected by shadows anyway.
3. Oni wasn't meant to support lightmaps, at least not in the hackish way that I've "implemented".
4. There are so many glitches in the rendering pipeline, it's not even funny. So, unintended, IMHO.

geyser 21:20, 4 October 2010 (UTC)

---

Lightmapping looking good.

Here are my screenshots of the room. I hope the links don't break. (I can't upload to oni2.net at the moment.)

It doesn't look too good, actually. If you look carefully at the piece of furniture with 8 small screens, some of the smaller polygons are completely black, meaning there have not been enough radiosity iterations (or whatever) for them to receive any light. Or maybe it's another of Blender's radiosity settings, like the resolution of the hemicubes (or whatever). Probably fixable, but I can't claim victory until I've actually tried to fix it.

Another (related) problem is that for larger level parts, some rooms (e.g., staircases) stay dark even though there are light emitters in there. Looks like Blender can't handle too much radiosity in a single job, and overlooks those small rooms while overdoing bigger ones. So it looks like neither I nor anybody else will be lightmapping whole levels at once. It's more likely that we'll have to split them up into rooms (similarly to the AGDB partition).

There are other problems which I'm becoming aware of while looking at the original levels and preparing them for lightmapping. There's geometry that's messed-up (all the furniture in that room except the 8-screen thingy needed fixing; some trusses in the big halls of the warehouse; dunno what else). There are spots that are begging to be remodeled (but there's no time or workforce for that). And of course there are the objects with moving counterparts, which should be lightmapped sparingly if at all.

Thinking of all that, it seems very unlikely that a lightmapped Oni will be available by January, even if OniSplit becomes able to import doors and such. We'll have a bunch of teaser screenshots, at most. Then again, there's the case of new levels (arenas, mini-games, stuff like that). For those we can probably have a release (complete with lightmapping and pathfinding). Maybe I should just lightmap the arena, nicify it a bit, and leave this proof-of-concept business at that. Sigh.

geyser 02:18, 24 November 2010 (UTC)

Here's a comparison screenshot:

Warehouse no lightmap:

With lightmap

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 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.

geyser (talk) 17:13, 9 December 2021 (CET)