View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003570 | DarkRadiant | Map Editing | public | 12.10.2013 14:19 | 25.09.2016 18:33 |
Reporter | grayman | Assigned To | greebo | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.7.2 | ||||
Target Version | 2.0.4 | Fixed in Version | 2.0.4 | ||
Summary | 0003570: Multiple func_statics, when rotated, leave origins untouched | ||||
Description | When several func_statics are selected and rotated, their origins remain where they were. This can cause origins to end up in the void, or--worse--in the wrong leaf. dmap will find the ones in the voide, but the ones in the wrong leaf go undetected. | ||||
Steps To Reproduce | Create a brush and make it a func_static. Clone it and move the clone away from the original. Select both brushes. Rotate the group about the Z axis. The origins don't rotate. | ||||
Additional Information | I know this has been an identified problem for quite a long time, and I'm surprised that someone long ago didn't file an issue for it (myself included). | ||||
Tags | No tags attached. | ||||
The cause of this issue goes back to a fix of mine 2007 - after looking at this again I think I know now how to fix it for good. | |
Fixed in dcc30c473d00bd39471e5b0e0d8f6f06c8222c15 | |
The first prefab I tried rotating with the new build was containers/chest_wood_old.pfb. The atdm:target_set_frobable inside the chest, while rotating properly, sent its origin way far away. |
|
In fact, the example I gave in "Steps to Reproduce" doesn't work. The origins of the two func_static brushes get sent very far away. |
|
I can see the difference - it happens when using the z-axis rotation commands (90 degrees) in the toolbar. It's working when I'm using the mouse-based rotator controls (select and hit R). I have to check why the commands work differently, but at least I can reproduce it. |
|
Fixed. The code was using an "optimised" execution path for 90-degree-rotations about the major axes, but the hardcoded Quaternions were wrong for the negative-90-degree rotations (which were used by the toolbar buttons). It was going back to the code initially forked from GtkRadiant, and I'm stumped that it went unnoticed for such a long time. The problem only ever became apparent now that we have proper pivoted rotation handling, where these wrong cos(phi/2) were sending the func_static origins off limit. A nice example of premature optimisation. Nobody would notice the difference in execution speed when using this shortcut over calculating the quaternion from the matrix (the code is all there), but hell, we need to optimise what we can, don't we? Well, yes, you can optimise, but at least do it right. |
|
Heh. Thanks for flushing this nasty bit from the code. | |
tested | |
Date Modified | Username | Field | Change |
---|---|---|---|
12.10.2013 14:19 | grayman | New Issue | |
20.04.2016 06:51 | greebo | Status | new => confirmed |
20.04.2016 11:38 | greebo | Assigned To | => greebo |
20.04.2016 11:38 | greebo | Status | confirmed => assigned |
20.04.2016 11:43 | greebo | Note Added: 0008102 | |
20.04.2016 12:11 | greebo | Target Version | => 2.0.4 |
20.04.2016 12:11 | greebo | Note Added: 0008103 | |
20.04.2016 12:11 | greebo | Status | assigned => resolved |
20.04.2016 12:11 | greebo | Fixed in Version | => 2.0.4 |
20.04.2016 12:11 | greebo | Resolution | open => fixed |
21.04.2016 12:42 | grayman | Note Added: 0008109 | |
21.04.2016 12:42 | grayman | Status | resolved => assigned |
21.04.2016 13:00 | grayman | Note Added: 0008110 | |
21.04.2016 13:19 | greebo | Note Added: 0008111 | |
23.04.2016 12:19 | greebo | Note Added: 0008112 | |
23.04.2016 12:19 | greebo | Status | assigned => resolved |
23.04.2016 12:34 | grayman | Note Added: 0008113 | |
25.09.2016 18:33 | grayman | Note Added: 0008351 | |
25.09.2016 18:33 | grayman | Status | resolved => closed |