New code produces same result without loop at all, so
it cannot fall in infinite loop, and it is faster in
use cases requiring more than one loop in previous code.
The Unvanquished vega map is known to trigger the bug:
https://github.com/UnvanquishedAssets/map-vega_src.dpkdir
I reproduced it multiple time on various hardware (8 core FX-9590,
12 core/24 thread Ryzen 9 3900X) with commit af40508 and using
final compilation profile edited to use -fastbounce instead
of -fast option.
The symptom is simple, q3map2 stucks there:
--- Radiosity (bounce 1 of 8) ---
--- RadCreateDiffuseLights ---
0...1...2...3..
Or somewhere else in that progression bar given your hardware
and the amount of core your CPU has.
When stuck, all the CPU cores are running 100% but the thread
never returns (a strace can reveals it, a gdb backtrace too).
Thanks to @slipher for the precious advices and improving my first
attempt to fix it.
For more information on the issue, I asked:
> which negative value never can become positive
> when incremented infinitely?
slipher said:
> for a double, any value less than -2^53 would have this property
> don't know for float off the top of my head
But then, it means that's theorically verified this loop was able
to run forever in some case.
I don't know what this code is doing anyway, but at least we can
keep the behaviour without requiring to understand it.
Correct math requires the ambient component of the lightgrid to be zero
in that case. However, q3 ignores lightgrid cells with all zero ambient
value, EVEN if the directed value is nonzero.
This change sets the ambient value to #010101 if it'd be pitch black. This
should be a minimal change without affecting light hue that fixes
lightgrid rendering. In engines like DarkPlaces, almost no map should
look different from this.
Fixes https://gitlab.com/xonotic/netradiant/-/issues/137
q3map2: fix inconsistency, introduced in d92c32d453
(_remap result could depend on _remap keys order, e.g. remapping src: moo/rock, moo/sand-rock by: rock, sand-rock suffix matches; rock could be used for moo/sand-rock)
fix -bsp crash with .bsp sent as map path
* fix: qer_editorimage, q3map_lightImage etc work with file names, containing period
(i.e. 'file.name.ext' names; don't StripExtension() twice in ImageLoad() for that)
The arrays were always meant to be variably sized, and objects are only ever allocated dynamically. Object size computations are simplified with this change.
Flexible arrays were introduced in C99, so this change means that we will require a C99-conforming compiler henceforth.
Move -keeplights help from -light stage to -bsp. Add other ~40 arguments
that were missing from help. My main focus was on the -convert stage
but I tried to document the rest as well. Some descriptions are copied
from message when enabling the option.
Running `q3map2 -fs_forbiddenpath -v mapname.map` would crash because
-v gets replaced with NULL in main().
Running `q3map2 -threads` would crash because missing next argument
for number of threads.
