mirror of
https://github.com/dhewm/dhewm3.git
synced 2025-03-19 17:21:42 +00:00
cc5f1d9fd2
somehow the collision code managed to spread NaNs on Win32, which caused
a horrible framerate, "GetPointOutsideObstacles: no valid point found"
warnings in the console and assertions in debug builds.
Didn't happen in Vanilla Doom3 though.
At the location I changed the code in, I saw the following values in the
debugger:
normal: {x=0.00610326231 y=5.58793545e-09 z=1.19209290e-07 }
trmEdge->start: {x=-1358.00000 y=913.948975 z=25.2637405 }
start: {x=-1358.00000 y=916.000000 z=34.0000000 }
end: {x=-1358.00000 y=810.000000 z=34.0000000 }
dist (normal*trmEdge->start): -8.28822231
d1: 9.53674316e-07
d2: 9.53674316e-07
f1 (d1/(d1-d2)): inf
"normal" isn't normalized and also very small (in all directions),
"start" and "end" have quite different y values, but still doing scalar
multiplications of each with "normal" gave the same result..
No idea what this all means exactly, but checking if d1 - d2 is (almost)
0 to prevent INF solved the problems. In the end it will be some tiny
differences in floating point calculations between different platforms
and compilers..
In my test d1-d2 was exactly 0, but I compare with FLT_EPSILON to be
on the safer side.
|
||
|---|---|---|
| .. | ||
| CollisionModel.h | ||
| CollisionModel_contacts.cpp | ||
| CollisionModel_contents.cpp | ||
| CollisionModel_debug.cpp | ||
| CollisionModel_files.cpp | ||
| CollisionModel_load.cpp | ||
| CollisionModel_local.h | ||
| CollisionModel_rotate.cpp | ||
| CollisionModel_trace.cpp | ||
| CollisionModel_translate.cpp | ||