View Issue Details

IDProjectCategoryView StatusLast Update
0003570DarkRadiantMap Editingpublic25.09.2016 18:33
Reportergrayman Assigned Togreebo  
Status closedResolutionfixed 
Product Version1.7.2 
Target Version2.0.4Fixed in Version2.0.4 
Summary0003570: Multiple func_statics, when rotated, leave origins untouched
DescriptionWhen 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 ReproduceCreate 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 InformationI 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).
TagsNo tags attached.




20.04.2016 11:43

administrator   ~0008102

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.


20.04.2016 12:11

administrator   ~0008103

Fixed in dcc30c473d00bd39471e5b0e0d8f6f06c8222c15


21.04.2016 12:42

viewer   ~0008109

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.


21.04.2016 13:00

viewer   ~0008110

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.


21.04.2016 13:19

administrator   ~0008111

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.


23.04.2016 12:19

administrator   ~0008112

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.


23.04.2016 12:34

viewer   ~0008113

Heh. Thanks for flushing this nasty bit from the code.


25.09.2016 18:33

viewer   ~0008351


Issue History

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