Lightmapping levels

This page's content overlaps with information found on the AE:Lightmapping page. Merging the articles will prevent confusion and help streamline the wiki.

Information is subject to change. The time of writing is 14:54, 4 October 2010 (UTC).

Lightmaps and Oni

Oni doesn't really support light maps, but we like to pretend that it does. See HERE for why we do and HERE for why we shouldn't.

In these screenshots, the lightmaps are part of the environment. They form a second layer of quads over the notmally textured ones, but they have their own texture coordinates, and they have their own unique texture. This shadow texture has a much lower resolution than the regular textures, but that is not a problem because of the blur effect. The only problem is that right now this texture is transparent, but doesn't have a BSP tree (supposed to be used for sorting when rendering particles etc, see ABNA). Apparently these shadows are always rendered in front of the opaque environment (which is good), but particles are always rendered behind the shadows (i.e., between the opaque environment and the shadow), and this is quite noticeable, unless the shadows are very subtle.

At the time of writing (14:54, 4 October 2010 (UTC)), OniSplit can import level geometry from several COLLADA files. For example, there could be one file for geometry and furniture, another file for the lightmaps of all that, another file with invisiwalls and invisiramps, another with a pathfinding mesh, etc.

Our options

Lightmaps can be generated in several ways. On my left, DelEd and IrrEdit are two lightweight tools that allow basic lightmapping, although it is far from optimal. On my right, (formerly "XSI") Mod Tool can generate much more sophisticated maps, but only for one mesh at a time, and with one texture file per mesh, which sucks.

In the middle, we have Blender, for which there apparently are a lot of scripts, enough to do what we need. It's fast to preview and to render, it's reasonably good-looking even with low quality settings, and it supports radiosity (see below) rather flawlessly. We like radiosity because Oni designers used area lights.

Radiosity

IrrEdit supports "radiosity" in the sense that every surface acts as a secondary light source. However, oddly enough, IrrEdit does not allow primary light sources to be area lights. The interface allows you to set up an emissive material and to assign it to polygons, but these materials and polygons are not taken into account when rendering lightmaps. Only regular lights contribute as primary light sources (point, spot, infinite, whatever), but the surfaces act only as secondary emitters. DelEd doesn't support radiosity at all. (formerly "XSI") Mod Tool supports it, but perhaps in a much too complicated way, apparently intended more for character authoring and complex renders than for moderately realistic lightmapping on a large scale (which is what we need for levels).

Oni was designed to be lit by area lights, in fact in most of Oni's environments the supposed light sources are clearly visible, with textures originally meant to be emissive, such as LIGHT_GRID. This means that the original levels can be lit relatively painlessly, in a tool that supports area lights. We don't need to place any light sources manually, instead we just assign an emissive material to polygons textured with LIGHT_GRID and other such textures. Then, ideally, the tool allows us to compute the lighting everywhere, as generated by these area lights.

The tool that does all that is Blender. The task is not exactly "mainstream", so there is not much support for it, but the ingredients are there. Here they are:

1. A tutorial for the "Lightmap UV Pack" script. The good thing about this script is that it can batch-process several meshes at once. The bad thing is that for every mesh, it packs the UVs into a single texture, so for large or detailed meshes meshes either the lightmap will be pixellated, or you need to make the texture's resolution huge.
2. An alternative Multi Lightmapper script, which generates new textures as needed, but can only process one mesh at a time.
3. Some more scripts for the batch processing of many meshes (e.g. for saving the generated textures to files; neither of the above scripts save the baked lightmaps, and since there can be hundreds of them, automatic saving is badly needed).

No tutotial of our own, for now, but if you want to experiment with this, you can.

Give me another reading

This is the room from which Griffin and Kerr monitor Konoko's progress. One of the simplest (ugliest) rooms in Oni. Very well suited for a tutorial.

However, you can see that the lightmaps don't look very spectacular, at all. The room looks OK, and that's it. At least that's how it is in the case of this simple room.

You can also see that my current GFX card (or, rather, lack thereof) is not OK (there's no anisotropic filtering, and the texture detail decreases very fast with camera distance).

This means that no matter how good the lightmaps are, the screenshot session that I had planned will probably look crappy if done on my current rig. I should've known that. F##k.

Tomorrow (Tuesday) there will be some time for Konoko to upload some screenshots from Monday's errands.

For now, here are the instance files of the above test (level5), for PC, Intel Mac and PPC Mac. Enjoy.

geyser 22:53, 25 November 2010 (UTC)

Catch him Konoko

This is the "blue" area of the Syndicate Warehouse, the one with the first Comguy and alarm console.

The lightmaps are mostly OK, but "mostly" is not enough, as you can see for yourself: PC, Intel Mac, PPC Mac. (WARNING: It requires globalized environment textures, so it will NOT work with the current AE, only with the previous one).

The most remarkable thing is that some quads are either black or very dark. Sometimes they stay out of the way of radiosity iterations, but sometimes it's the texture-baking part that ignores them. The first problem can (apparently) be solved by separating the level into even smaller parts than what you see here (for example, the staircases can be lightmapped separately, to compensate for the large number of smallish quads). The second problem can (apparently) be solved by baking to very large textures (1024x1024, 2048x2048 etc) and then downsampling the result. A third solution would be for the lightmaps to use another background color than black, so that all the abnormally dark quads would get some default brightness (probably normal-looking enough to the casual eye). I rather like that last solution best, because it's quick and dirty, and I'm getting sick enough of lightmapping as it is ^_^

Bottom-line is, maybe it is possible to generate a flawless-looking lightmap automatically, but the procedure will require some tweaking in any case, as soon as there's furniture and doors and moving objects and suchlike. Also, since it's not much fun, I can't imagine it done by anyone else than me, unfortunately.

geyser 22:53, 25 November 2010 (UTC)