Rotating groups of things

[grayman]

I have a collection of items, and I want to rotate the collection. Is there some way to do it that retains the spatial relationships among the items?

 

Worldspawn brushes and patches work fine, but when you try to rotate collections of entities, they just scatter to the wind. Worse yet, many origins go off on their own, ending up far from their owners.

 

It seems that selecting a group of entities, and asking to rotate them, involves finding the center point of the collection, and rotating each item about that point. The x,y,z axes of each item would adjust accordingly.

 

What logic is being applied to rotating collections?

 

I've tried toggling the "Free Model Rotation" mode, but I can't see what it's doing, and I can't find any explanation on the wiki pages.

 

Thanks.

Edited July 6, 2010 by grayman

[grayman]

And a minor nit about mirroring...

 

The "mirror about X/Y/Z" functions are swapped in each orthogonal view.

 

For example, when using the X/Y view, and you ask to mirror about the X axis, it mirrors about the Y.

 

And vice versa.

 

Ditto for the Z/X and Z/Y views.

 

Might be worth straightening out in the future.

[jdude]

Just create a rotating no draw or caulk brush and then bind your items to it

[Mortem Desino]

(I believe he means in the editor, not a func_rotating in-game.)

 

Rotating large sections of items in the editor has always been questionable practice (in any editor and engine, even Hammer and HL2). Ours just happens to be...more...questionable?

 

Worldspawn rotates just about perfectly.

Func_static brushes/patches rotate well, but their "origin" often goes out of whack, sometimes reaching into the void and causing a leak (even though it might still look okay).

Any non-brush, non-patch items (models, lights, speakers, AI, etc.) may not rotate as expected.

 

Suffice it to say, this bug has been tracked for a loooo.......oong time. Since 2007 to be exact.

[grayman]

Func_static brushes/patches rotate well, but their "origin" often goes out of whack, sometimes reaching into the void and causing a leak (even though it might still look okay).

 

 

Right. I've even had trouble with origins being left behind in a group translation.

 

Suffice it to say, this bug has been tracked for a loooo.......oong time. Since 2007 to be exact.

 

That long, eh?

 

Okay, thanks. I'll do what I have to do by hand, then, item by item.

[DeTeEff]

Will it work if you merge the entities?

[Fidcal]

Most likely I would think.

 

Just tried the mirroring and it seems OK. I think it is a conceptual thing. It doesn't actually say 'axis' but eg, mirror x. In xy (top) view that mirrors left to right which is the x direction or along the x axis if you will but not around the x axis.

[grayman]

Most likely I would think.

 

Just tried the mirroring and it seems OK. I think it is a conceptual thing. It doesn't actually say 'axis' but eg, mirror x. In xy (top) view that mirrors left to right which is the x direction or along the x axis if you will but not around the x axis.

 

In mathematics, the term "mirror about x" means to mirror across the x axis to the other side.

 

I'm not saying it doesn't work. I'm saying that as used in DR, it's misleading. It's an easy correction to make, though.

[grayman]

Will it work if you merge the entities?

 

 

How do you merge entities?

[grayman]

I found the "merge entities" button.

 

However, it only works with func_statics.

 

There doesn't appear to be any way to merge other entities into a group so that they can be correctly rotated.

 

I have a corridor of mushrooms with their little attached lights that I want to rotate. A single working rotate button would be a godsend, since you can imagine my hesitation at doing this by hand. Yikes!

 

But into the fray I go, since, after all, there's a deadline ...

[Komag]

But it's not "mirror along x", it's "x-axis mirror" as in "flipping the axis itself", not along it, and the picture shows an x on the left and an x on the right, which is conceptually good because I know the x axis goes left and right so I intuitively know that the mirror will be "left will flip to right and right will flip to left", all good.

[grayman]

But it's not "mirror along x", it's "x-axis mirror" as in "flipping the axis itself", not along it, and the picture shows an x on the left and an x on the right, which is conceptually good because I know the x axis goes left and right so I intuitively know that the mirror will be "left will flip to right and right will flip to left", all good.

 

 

Here's a page on mirroring: http://www.mathsisfun.com/geometry/reflection.html

 

Scroll down to the "Some Tricks" section. See how X-mirroring flips the object vertically? And y-mirroring flips the object horizontally?

 

DR does the opposite in each case, mirroring the object horizontally and vertically, respectively.

 

Ditto on the ZX and ZY views.

 

So, while DR is doing mirroring, the buttons are mis-labeled. That's why I contend that's it's a simple fix: either rename the buttons, or swap the links in the code to call the correct routines.

[SneaksieDave]

I don't really know if it's correct or not, to be honest. I don't have problem using it though when I started thinking of it is "mirrored along [axis]." So if I see the Y axis pointing at the top of my screen, I know that clicking mirror along Y will flip the object vertically. And so on.

 

I guess if it is backwards, and does get fixed, I shall have to reverse my thinking on it..

[Bikerdude]

Func_static brushes/patches rotate well, but their "origin" often goes out of whack, sometimes reaching into the void and causing a leak (even though it might still look okay).

In fact this has been bugging me for a while and now that I think about its been getting worse since DR-1.2.2. if I rotate a WB and then rotate it back its never actually goes back to its original position I have to use Ctrl-Z which I Im reasonably sure I never had to do in DR-1.2.2. Is this worthy of a bug report if I do a correct and proper replication..?

[SneaksieDave]

Yes if it's a separate issue from the original entry speaking about general multi rotation probs:

http://bugs.angua.at/view.php?id=230

[Fidcal]

Sorry but I still don't see it. That example seems to be 2D only and those graphs don't really show which direction is which although one might assume x is horizontal and y is vertical from the preceding graph.

 

This is the way I see it:

 

Firstly, in TDM, x, y, z can be axes or directions depending on context. Here they are directions. (substitute alignment for direction if that suits better.)

 

Z is the vertical direction

Y is north/south

X is east/west

 

If you choose x-mirror (it says nothing about axes) then it can do one of three things:

 

Mirror:

up/down (z direction)

east/west (x direction)

north/south (y direction)

 

Now why choose either up/down or north/south if x is not appropriate? And which is the correct one to choose and why?

 

I can see in a 2D graph that mirroring might take place from one side of dividing line to another but in 3D there are two other 'sides' to the dividing line. In the case of x it could be up/down or it could be north/south.

 

I think x is the correct direction to mirror if you choose x. At most one might say change the words in the menu from Mirror - x to be... Mirror to x or Mirror to x direction but for me Mirror - x seems a decent shorthand. (and I'm a nitpicking sob when it comes to words as Sneaksie will vouch for.)

[grayman]

The algorithm applied in a 2D view is a simplification of the 3D algorithm; one of the axes is held constant.

 

All I can say is Google "geometric mirroring" or "mathematical mirroring" and look at the 2D and 3D examples. In every case, the object is flopped across the plane (3D) or line (2D). It's not flopped "along" it.

 

And "axis" and "direction" are interchangeable in this context.

 

So I still maintain that (in 2D) Y mirroring flops the object across the Y line, X mirroring flops the object across the X line, and Z mirroring flops the object across the Z line. Our discussion here won't change the geometric meaning of mirroring.

 

We can all interpret DR's "mirroring" term in our own contexts. You've established yours. I've established mine as having to remember that when I hit the "X mirror" button, I'm getting a Y-mirror applied. Ditto for Y and Z. No biggie.

[Bikerdude]

Yes if it's a separate issue from the original entry speaking about general multi rotation probs:

it is a seperate issue looking at your bug report, so I'll post a bug report.

[Fidcal]

Grayman: Yes I accept what you are saying but the problem remains in 3D if you wish to mirror across an axis you also have to nominate the plane. For example, suppose...

 

• 
   
  
• You are in top view looking vertically down the vertical z axis which is just a point in the centre.
  
• At top right in the north east quadrant is an object
  
• You wish to mirror it across the z axis to the west - to the north west quadrant.
  
• You nominate mirror - z axis.
  
• Fair enough but what if you want instead to mirror it across the z axis to the south?
  

 

Both of the above mirror across the z axis. But the first is in the zx plane and the second in the zy plane. The result will be different so you have to nominate zx or zy.

 

But mirroring across the z axis in the zx plane is identical to mirroring across the y axis in the xy plane (think about the example above. In front view (zx) you see the object mirrored to the west. In top view (yx) you would also see it mirrored to the west.) So it is sufficient to nominate the direction x which can have only one result.

[grayman]

• You are in top view looking vertically down the vertical z axis which is just a point in the centre.
• At top right in the north east quadrant is an object
• You wish to mirror it across the z axis to the west - to the north west quadrant.
• You nominate mirror - z axis.
• Fair enough but what if you want instead to mirror it across the z axis to the south?

 

Since we work in 2D views (XY, ZX, ZY), we can limit the discussion to 2D.

 

In your example, the 2 axes in the view are XY. If you want to mirror a NE-quadrant object into the NW quadrant, you want to mirror across the Y axis. For each point (x,y) in the object, you change the x value to its negative. So (x,y) becomes (-x,y). An editor would provide you with a "Y-mirror" button to do this.

 

If you want to mirror the object to the SE quadrant, you want to mirror across the X axis, using an "X-mirror" button. In this case, each (x,y) point becomes (x,-y).

 

If you want to mirror the object all the way across to the SW quadrant, you'll do either an X-mirror followed by a Y-mirror, or a Y-mirror followed by an X-mirror. So (x,y) becomes (-x,-y).

 

ZX- and ZY-view discussions follow the same logic.

[Fidcal]

But that would need a change to the code to take account of the ortho view in order to get the correct plane instead of as now, the player tells it by giving the direction. The current method will always produce the same result no matter what ortho view is showing or even if none is showing. For instance it can mirror towards/away from you in ortho - will look like nothing happened but you can see the action in the camera view.

[DeTeEff]

When I rotate things it often happens that I will jerk about a lot with the Rotation-buttons before the stuff end up the way I want...and I love the Undo-button BTW, (Sorry for Off-Topic) the Rotation-property, (or is it Rotate?) which of the numbers is which? I often need to test "Rotate(ion) 90 0 0" and play..."nope, wrong rotation..." 0 90 0...Nope, still wrong...

 

 

[Fidcal]

I've lost track of this thread now. Erm... rotation is the property that is applied when you rotate something in the editor (with some entities it is angle) so it tells the game what angle to spawn the entity at. This takes the form 1 0 0 0 1 0 0 0 1. (I'm not sure this has any effect on brushes and patches.) If you mean the rotate property such as is used on doors to state how it should rotate in game then that Y X Z (unless it has been changed.) Also I remember the values are positive to give anti-clockwise (default) and negative for clockwise (looking down from above in a z rotation.

[DeTeEff]

I've lost track of this thread now. Erm... rotation is the property that is applied when you rotate something in the editor (with some entities it is angle) so it tells the game what angle to spawn the entity at. This takes the form 1 0 0 0 1 0 0 0 1. (I'm not sure this has any effect on brushes and patches.) If you mean the rotate property such as is used on doors to state how it should rotate in game then that Y X Z (unless it has been changed.) Also I remember the values are positive to give anti-clockwise (default) and negative for clockwise (looking down from above in a z rotation.

 

 

Thank you! It's my fault the thread went a bit off Grayman had problems with rotating things in the editor and with entities rotating around their own axis rather than keeping the internal orientation, among the entities rotated, correctly...