 |
Added test map from http://forums.thedarkmod.com/topic/19714-render-issue/page-2#entry429482 |
 |
@stgatilov Can you confirm that the ifdef in idMath::InvSqrt is affecting this? What is the difference between idMath::RSqrt and idMath::InvSqrt? I would suggest adding a 'slow' version of idVec3::Normalize that calls a more precise version of InvSqrt |
 |
This might also be the root cause for old maps like "Rightful Property" and "Samhain Night" getting "AAS Out of Date" errors. Broken AAS geometry? |
 |
I also noticed that it can affect models. E.g. I have a model with two opposite planes very close to each other (below 1 unit). In 2.05 there was no problem with that. In 2.06 I see z-fighting. |
 |
I tried both test maps and don't see any missing triangles in any of the stairs. I have AMD Ryzen CPU. 1) Did someone reproduce the problem successfully? 2) Could someone who can reproduce the problem write #undef __SSE__ before idMath::RSqrt and write #define __SSE__ after idMath::Sqrt64, then try again? 3) If that does not help, please try to remove StreamingSIMDExtensions2 clause from Common_x86.props, recompile the whole game and try again? The different between various versions of rsqrt/sqrt are the precision they provide. If these functions cause problems, I would start with making RSqrt work the same as InvSqrt16 (i.e. add the line with NR iteration). If this does not help, we can try reverting to old and slow implementations. |
|
|
Using the attached stairs.map, run in console dmap stairs.map map stairs.map How does it look to you? My screenshot attached For me it's caused by the ifdef in idMath::InvSqrt |
|
|
Attached screenshot. The problem is in InvSqrt? Not in RSqrt? If that's really the case, try adding one NR iteration for InvSqrt, i.e. replace implementation with: //stgatilov: one NR iteration is almost enough for float32 precision, let's make second one float r = InvSqrt16(x); r = (0.5f * r) * (3.0f - x * r * r); //max precision return r; |
|
|
Sorry, I meant using "float" for variable "r". If that still does not help, then try the same, but with "r" declared as "double", and all float constaints replaced with double constants (0.5f -> 0.5, 3.0f -> 3.0). |
|
|
As last resort, try using full-precision instruction: return 1.0f / SSE_SQRT(SSE_MAKEPOSITIVE(x)); This gives max precision. And it has almost the same speed as two NR iterations =) |
|
|
Try the 32 bit build |
|
|
Also works properly on Release 32-bit on Ryzen. I tried my laptop (some modern Intel CPU): it fails to build stairs.map: something leaks. But I can reproduce the problem on fstmp.map. |
|
|
I have committed a supposed fix (svn rev 7788). It replaces the "approximate rsqrt + NR" magic with an ordinary 1.0f / sqrtf(x) implementation inside idMath::InvSqrt. The output of the new version is precisely defined by IEEE standard (on any input), so now this function should work exactly the same way on all CPUs. |
|
|
We now have four inverse square root functions, not counting the crt one Can we get rid of one or two of them or at least make it clear which one is used for what? |
|
|
I had the same question when I was implementing SSE versions =) Here is how I see it. Every function in idMath is available in three precisions --- that's a matter of uniformity. There are: 1) Ordinary function (InvSqrt / Sqrt) --- full float32 precision. 2) Low-precision one (InvSqrt16 / Sqrt16) --- only float16 = half precision. 3) Double precision one (InvSqrt64 / Sqrt64) --- float64 = double precision. Which one to use: a) The CRT version is most likely never used in ID code. In fact, you should not use it either, but if you do, nothing bad will happen =) b) When you want to use some math function, you have to decide how much precision you need. In 99.99% cases you need full float32 precision, so you use the version without digits on the end. In rare cases 16 bits are enough, so you can use 16-bit version (although you don't have to). I cannot see any case when double precision version could be useful, but for some reason ID implemented it too. Now there is one minor exception: RSqrt is an additional very imprecise version of inverse square root. It is very fast, and sometimes it is enough for your needs. Summary: Unless you use square root in a tight loop which has bottleneck in arithmetic operations, you should use Sqrt/InvSqrt and other similar functions without suffix. Don't use RSqrt unless you know what you are doing |
- Anonymous
