OK, I've identified the cause of the corrupt lightmap bugs. Unfortunately it's as I feared; ID changed the lighting algorithm slightly between that used for the released Quake maps and that used in the released light.exe source. What this means is that on occasion the released source will generate a slightly different number of lightstyles to those which are in the otiginal maps; usually one less. I've confirmed that this is the case by doing a diff between the lightstyles generated on faces from a fresh release build of the earliest source available (on the ID FTP) and those contained in the original maps, using e2m1 for the comparison.
Options?
The most obvious (and easiest) appears to be to abandon the effort. Realistically, I'm never going to get an exact match with the original here. A proper replacement that's usable for all LIT supporting engines will require a full relight of the maps and a release of new BSPs as well as LITs. This seems preferable for a number of reasons, but it's unrealistic too, as expecting people to replace their BSPs seems a step too far. There are also legal implications; while the GPL will allow a release of the compiled BSPs, it doesn't cover the textures in them.
A second option is to drop the general light utility functionality and focus purely on colouring. This would involve building a "colour map" for each surf, which would just contain an amount (in R/G/B) to multiply the original lightmap by, then just multiplying the original lightmap to derive the LIT. Fast and accurate, but would require some fairly radical restructuring of the code.
A third option seems to be to do something to approximate the data. Using a combination of the original light data, the new light data and style info, it should be possible to get reasonably close to what the original had. I'm not certain how well it would work, or if the effort required would be worthwhile, but this seems to be the a reasonable second-best approach, assuming that a release of some kind is the objective.
Other options involve various brute force methods, which are not really up for consideration.
I think what I'm going to do is take the "colour map" approach on a forked copy of the code and see how far I get with that, and save the data approximation as a fallback.
Tuesday, April 14, 2009
Bugfixing
Posted by
mhquake
at
1:59 AM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment