Closed illwieckz closed 4 months ago
The guide for the complete neophyte.
git clone --recurse-submodules https://github.com/Unvanquished/Unvanquished.git
cd Unvanquished
mkdir -p build ; cd build
cmake .. -DUSE_BREAKPAD=OFF \
-DCMAKE_BUILD_TYPE=Debug -DUSE_DEBUG_OPTIMIZE=OFF \
-DBUILD_GAME_NACL=OFF \
-DBUILD_GAME_NACL_NEXE=OFF -DBUILD_GAME_NATIVE_EXE=OFF \
-DBUILD_GAME_NATIVE_DLL=ON
make -j$(nproc)
Note: if you missed submodules, do: git submodule update --init --recursive
aria2c
first to workaround Unvanquished#1100):../download-paks pkg
wget https://github.com/illwieckz/pimi/raw/master/pimi
chmod +x pimi
./pimi etmain
oasis
map:./daemon -set vm.cgame.type 3 -set vm.sgame.type 3 \
-pakpath ~/.etlegacy/etmain \
-set fs_legacyPaks 1 \
-set fs_extraPaks 'pak0 pak1 pak2' \
+set g_neverEnd 1 \
+devmap oasis
This makes easier to see compare:
ET:Legacy:
Dæmon:
Note: the Daemon screenshot is darker because of that non-Dæmon bug (bug in Unvanquished game, probably UI related): https://github.com/Unvanquished/Unvanquished/issues/1151
If I somewhat revert that Unvanquished bug within GIMP, I get something that looks like ET:Legacy (except the bug we talk about there):
So, the important things are those special vertex-lit surfaces on the house, on the foliage etc.
There was some talks these days on ET: Legacy discord about the idea to plug the Dæmon renderer in their engine. The idea come from the observation:
At some point it may be better to plug our renderer in their engine. They already have multi-renderer mechanism and in the past we had this feature too. So maybe it's doable, given some glue may have to be written.
On a side note, since the Dæmon engine is based on ET:XreaL, I personally make special effort to test our renderer against Wolf:ET maps to prevent regressions. See that railgun map thread for example. Even if a plug of the Dæmon renderer in ET:Legacy never occurs, I consider our engine must not regress in rendering Wolf:ET maps, and I consider any rendering feature Wolf:ET had to be something that deserves to be supported in Dæmon. To me those are part of the basic set of features to support.
So, that said, what's the issue about?
Wolf:ET maps make use of a
q3map2
option, namely-approx
, that controls the amount of surfaces that will be forced to vertex lighting. When a map is compiled with this option, some surfaces of the map are not lightmapped even if the map is lightmapped, maybe to save on lightmap size (hence GPU memory) and on rendering passes when there was no material collapse code.This
-approx
option being part ofq3map2
, nothing guarantees no one Tremulous map uses it.This is what
q3map2
builtin help says about this option:This is clearly something we would not recommend to use in new maps, but that's something we can find being used in legacy maps.
The issue is that the renderer replaced the vertex lighting with lightgrid lighting (that permit more features, like computing light direction), but in such case, the scene mixes surfaces rendered with lightgrid lighting and surfaces rendered with lightmap lighting instead of mixing surfaces rendered with vertex lighting and surfaces rendered with lightmap lighting.
While lightgrid lighting does not look that bad and is consistent by itself, it does not mix well with lightmap lighting.
The best test bed for this issue is the Oasis map from Wolfensetein: Enemy Territory, one of the stock maps of ET:Legacy.
Note: this map suffer from bug #169 in polylib, see #312 for a patch to load it in Dæmon.
Oasis map rendered with lightmap with some lightgrid because of approx:
Oasis map rendered with lightgrid only:
We can see how one surface on the house is rendered with lightgrid while other surfaces are rendered with lightmap. Lightgrid lighting is not close enough to lightmap lighting to keep it that way.
It would be good to implement vertex lighting for such case. At first the feature would be globally enabled by hand using a cvar to test the feature, then once the feature works we may detect the surface does not have lightmap but belong to a bsp model that is lightmapped (see #309 for code that would make this possible).
See how lightgrid does not mix well with lightmap:
Vegetation seems to not be lightmapped, probably on purpose:
It's possible mappers have optimized the map by marking some surfaces to not be lightmapped on purpose when there was obviously no shadow to render: