The camera key control routine now accumulates angular and positional velocity, and applies them per frame. There is also a friction component to reduce and then clear them over a few frames. This feels a lot closer to "noclip" movement, and allows mappers to navigate more precisely, which makes selecting brushes and faces in intricate areas much easier. YouTube preview of the movement here: https://www.youtube.com/watch?v=oiKwr3w0o5c
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.
Add parentheses to print statements
Use subprocess.check_output instead of commands.getstatusoutput
to run external processes
Use pickle instead of cPickle library
This allows building on Linux distributions that have switched to
python 3 by default but also retains backwards compatibility with
python 2.7
Loading Wavefront OBJ models in picomodel (used by radiant and q3map2)
did not reset the surface vertex index when starting a new surface. This
caused there to be unused vertexes, equal to the number of vertexes in
all previous surfaces, at the beginning of each surface. Exponential OBJ
vertex memory usage as number of surfaces increases. It did not affect
displaying or processing the surface faces.
