View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001521 | Spring engine | General | public | 2009-07-31 01:35 | 2009-08-01 21:58 |
| Reporter | tvo | Assigned To | tvo | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001521: Clicks for unit selection "pass through" the unit | ||||
| Description | In master, selecting units by single clicking on them is *a lot* harder then in 0.79.2.1. It seems the clicks go through the unit almost always. (tested with 7b596801d743bfd3e20e29ce43462fbdc0dcc75a) | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
How to reproduce: Start spring, pick any mod/map, try to select a unit by clicking on top. Won't work. (I tested XTA commander and gertiger in Spring:1944) |
|
|
Maybe the recent FastMath/float3 (esp. http://github.com/spring/spring/commit/30332c92dcfc70dd17590c3bbf1dae1b4c08e4c2 ) changes introduced inaccuracies in the raytracing code that are of the same or greater order as the precision required? If so, that could also be a problem for hit detection in general. |
|
|
I replaced fastmath::isqrt with fastmath::isqrt2 in Normalize, it is more accurate. But it still needs some tests to see why isqrt and under what conditions is such inaccurate. (the .h says its max error is <1%, but this bug let me think it can be much higher) |
|
|
I wrote a test-program that basically did this: maxErr1 = 0.0f maxErr2 = 0.0f maxErr3 = 0.0f for each possible valid floating-point input value f fr1 = fm::apxsqrt1(f) // 1 iteration in fm::isqrt_nosse fr2 = fm::apxsqrt2(f) // 2 iterations in fm::isqrt_nosse fr3 = fm::apxsqrt3(f) // 3 iterations in fm::isqrt_nosse fr1_sq = fr1 * fr1 fr2_sq = fr2 * fr2 fr3_sq = fr3 * fr3 err1 = (f / fr1_sq) // relative error err2 = (f / fr2_sq) // relative error err3 = (f / fr3_sq) // relative error if (err1 > maxErr1) maxErr1 = err1 if (err2 > maxErr2) maxErr2 = err2 if (err3 > maxErr3) maxErr3 = err3 And got these results: [fm::sqrt1] maxErr1 = 1.003392333984000 [fm::sqrt2] maxErr2 = 1.0009307861 [fm::sqrt3] maxErr3 = 0.9999847412 So that comment in FastMath.h is pretty much right, but only for _individual_ calls to sqrt. The precision error will of course snowball when there are multiple intermediate values involved in a computation, as is the case for the raytracing code. |
|
|
Also, for large f, a ratio (f / (fm::apxsqrtX(f) * fm::apxsqrtX(f))) of 1.003 can still represent a huge absolute difference, so such accuracy guarantees don't mean much. |
|
|
this works fine now again, thanks :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-07-31 01:35 | tvo | New Issue | |
| 2009-07-31 01:43 | tvo | Note Added: 0003822 | |
| 2009-07-31 12:08 | Kloot | Note Added: 0003823 | |
| 2009-07-31 12:09 | Kloot | Note Edited: 0003823 | |
| 2009-07-31 20:16 | jK | Note Added: 0003824 | |
| 2009-07-31 20:18 | jK | Note Edited: 0003824 | |
| 2009-07-31 20:18 | jK | Note Edited: 0003824 | |
| 2009-07-31 23:55 | Kloot | Note Added: 0003827 | |
| 2009-08-01 00:02 | Kloot | Note Edited: 0003827 | |
| 2009-08-01 00:04 | Kloot | Status | new => feedback |
| 2009-08-01 01:49 | Kloot | Note Added: 0003828 | |
| 2009-08-01 21:58 | tvo | Note Added: 0003831 | |
| 2009-08-01 21:58 | tvo | Status | feedback => resolved |
| 2009-08-01 21:58 | tvo | Resolution | open => fixed |
| 2009-08-01 21:58 | tvo | Assigned To | => tvo |
