View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000230||DarkRadiant||Map Editing||public||23.03.2007 16:03||01.01.2017 18:09|
|Target Version||2.0.4||Fixed in Version||2.0.4|
|Summary||0000230: Rotation of multi-ent objects problematic|
-Select all parts making up the candle at the top end of the map in the center (because it has an oddly shaped clipmodel - I think that might be key in this case)
-set grid to 1 for an accurate rotation origin
-special rotation modes (left panel) don't seem to help or hurt in either case
Note that when you rotate the group of items, they don't follow a joint origin. In fact you can see more than one origin rotating. The clipmodel is definitely not centered and as a result the light swings around although it technically shouldn't. Even if my description here isn't the best, just take a look and you'll see the problem.
A solution that comes to mind is a way to set such non-homogeneous entities as a "rotation group", either permanently or (much) preferred, only during rotation, so that they have one single origin to rotate around (I'm actually surprised this doesn't work, because it seems to work perfectly for brush objects). This type of behavior will be needed to get any kind of use out of prefab or otherwise duplicated complex items - if their origins do not stay fixed with regard to one another, rotation will be a mess.
For a much worse case, try the torches on the wall. I think there's a separate bug in here, because usually the torch stick itself doesn't even rotate on the same axis (probably due to its angle). But if it does, it still shows the 'wobble' in the rotation of this group. If you hide the stick part of the torch, and instead just rotate the light and the arm, it seems to work perfectly.
|Tags||No tags attached.|
|I don't think that I can solve that one, actually I don't have a clue of how to approach this. Either I'll have some sort of enlightenment or I will have to skip that one.|
This issue came up here:
for the sake of prefabs. As such, I'll give it a little priority bump.
I just had a (simplistic) thought on this. Wouldn't it be simple enough to:
-get the origins of all of the selected objects
-calculate a new, temporary unified origin based on all of the selected origins (an average center)
-rotate the whole group around that
When the selection is cleared, the temporary rotation origin is discarded.
|This is basically what happens in the SelectionSystem. The problem is that this virtual origin (it is called the pivot point in DarkRadiant) is not always at the center, and not all entities respond to transformations in the same way. Maybe it's easy to fix that, maybe not, but debugging that will be tough.|
I've found another clue: This seems to be to related to the "rotation" spawnarg on model entities. For models with empty "rotation" spawnarg, the coupled rotation operation works fine for the first time.
As soon as the "rotation" key is set, the rotation of multi-selections is going wrong.
This can be easily observed on models that are rotated 90° around the Z axis. Just select such a model together with a brush and rotate these two objects. The model rotates about a different axis (!).
Bizarre, I was just noticing that (your last sentence) myself a couple of weeks ago, and I wasn't sure if it's always been that way or not. I had a painting on a wall which was apparently rotated several times at some point, and I was just trying to use it on a separate wall, so a quick Z-rotation would do. Well it didn't - it rotated in ways which were NOT my choosing. In the end I figured, "Oh I get it - it's rotating around LOCAL, not WORLD coordinates."
I don't know if I was right or not, but I didn't feel like bending my brain around it. :)
Has it always been this way? In testing software, I've often found that when something jumps out at me like this all of a sudden, it's because some change happened somewhere.
|Yes, that's always been that way. GtkRadiant/DarkRadiant never handled the rotation matrix of models very well.|
I confirm models rotate OK unless they are already have a rotation.
Entity brushes (and presumably patches) rotate OK but the origins remain where they were. If our code calls a rotation on each entity one by one then a crude fix might be:
Create a temporary model.
Copy the origin of the brush entity to it.
Rotate the model as required.
Rotate the brush entity as required.
Copy the model entity origin back to the brush entity.
Delete the temporary model.
|Mostly solved as of a8ce5928ff81f1a7bbe40ff96d92382c58a4f33b|
|23.03.2007 16:03||SneaksieDave||New Issue|
|23.03.2007 19:43||greebo||Status||new => acknowledged|
|24.03.2007 18:58||greebo||Note Added: 0000465|
|11.10.2007 15:58||SneaksieDave||Priority||normal => high|
|11.10.2007 16:00||SneaksieDave||Note Added: 0000758|
|11.10.2007 16:00||SneaksieDave||Status||acknowledged => feedback|
|11.10.2007 16:32||SneaksieDave||Note Added: 0000759|
|11.10.2007 16:33||SneaksieDave||Note Edited: 0000759|
|11.10.2007 16:33||SneaksieDave||Note Edited: 0000759|
|11.10.2007 16:35||greebo||Note Added: 0000761|
|07.12.2007 10:30||greebo||Note Added: 0000909|
|11.12.2007 00:30||SneaksieDave||Note Added: 0000914|
|11.12.2007 08:37||greebo||Note Added: 0000917|
|23.11.2010 15:04||Fidcal||Note Added: 0003317|
|03.01.2016 11:39||greebo||Assigned To||=> greebo|
|03.01.2016 11:39||greebo||Status||feedback => assigned|
|03.01.2016 11:39||greebo||Target Version||=> 2.0.4|
|05.01.2016 11:07||greebo||Note Added: 0007981|
|05.01.2016 11:07||greebo||Status||assigned => resolved|
|05.01.2016 11:07||greebo||Fixed in Version||=> 2.0.4|
|05.01.2016 11:07||greebo||Resolution||open => fixed|
|01.01.2017 18:09||greebo||Status||resolved => closed|