View Issue Details

IDProjectCategoryView StatusLast Update
0000230DarkRadiantMap Editingpublic01.01.2017 18:09
ReporterSneaksieDave Assigned Togreebo  
PriorityhighSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.0 
Target Version2.0.4Fixed in Version2.0.4 
Summary0000230: Rotation of multi-ent objects problematic
Description-Open torchtest.map
-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.
TagsNo tags attached.

Activities

greebo

greebo

24.03.2007 18:58

administrator   ~0000465

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.
SneaksieDave

SneaksieDave

11.10.2007 16:00

developer   ~0000758

This issue came up here:
http://modetwo.net/darkmod/index.php?s=&showtopic=6599&view=findpost&p=127186

for the sake of prefabs. As such, I'll give it a little priority bump.
SneaksieDave

SneaksieDave

11.10.2007 16:32

developer   ~0000759

Last edited: 11.10.2007 16:33

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.

greebo

greebo

11.10.2007 16:35

administrator   ~0000761

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.
greebo

greebo

07.12.2007 10:30

administrator   ~0000909

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 (!).
SneaksieDave

SneaksieDave

11.12.2007 00:30

developer   ~0000914

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.
greebo

greebo

11.12.2007 08:37

administrator   ~0000917

Yes, that's always been that way. GtkRadiant/DarkRadiant never handled the rotation matrix of models very well.
Fidcal

Fidcal

23.11.2010 15:04

developer   ~0003317

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.
greebo

greebo

05.01.2016 11:07

administrator   ~0007981

Mostly solved as of a8ce5928ff81f1a7bbe40ff96d92382c58a4f33b

Issue History

Date Modified Username Field Change
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