transform origin moves when resizing line

[loukash]

5 hours ago, thomaso said:

This feels like a bug to me

I don't think so. The rotation and position of a duplicate object is relative to the previously rotated object. The relation between object2 and object3 is the same as between object1 and object2. But not absolute. So it's just the math it's using, not a bug. To duplicate strictly horizontally, every copy would have to remember the attributes of object1. (Wasn't there a new feature in v2 that might make that possible? I haven't explored everything yet…)

[thomaso]

13 minutes ago, loukash said:

The rotation and position of a duplicate object is relative to the previously rotated object. (…) So it's just the math it's using, not a bug.

Can you point out this math in particular? – To me it seems not to matter here, respectively it does not explain to me why an object moves vertically if the user did not set anything to move vertically. That is why I mentioned the position of the transform origin: If this is set to the bottom left corner then any rotation should happen around this position (and indeed works this way for a power duplicated object, too). If a horizontal move gets added (before or after the rotation) then still no vertical movement is required. The bottom left corner should move on a horizontal line, regardless what rotation is applied. Then the bottom left corner = the rotation point = the transform origin of every object is an absolute (not relative) parameter of each single object, the initial object included. Each of the three parameters is requested to move horizontally only. – What maths would make them move vertically?

[Old Bruce]

12 minutes ago, thomaso said:

Can you point out this math in particular? – To me it seems not to matter here, respectively it does not explain to me why an object moves vertically if the user did not set anything to move vertically.

Not so much math as Geometry. I think what is happening is that the first rotation is done in relation to the object's bounding box, then the move is done relative to that rotated bounding box, not actual x,y co-ordinates. The second rotation is done in relation to that new bounding box.  

To sum up my theory, it appears to rotate then move the x, y distance relative to the rotated bounding box (to the right is now "to the right a bit and down a bit"). What we want is for it to move the distance then rotate.

[loukash]

26 minutes ago, thomaso said:

Can you point out this math in particular?

If you duplicate object1 to object2 and rotate and move the latter horizontally relative to object1, then the upcoming object3 will be moved in the same angle relative to object2. Since object2 is already rotated, the movement isn't absolutely horizontal anymore. 

But I'm no "math" person – the last time I had math lessons in school must have been around 1982 – so I can't give you any equations and stuff. 

26 minutes ago, thomaso said:

That is why I mentioned the position of the transform origin

It's relative as well. The next object's position is always relative to the previous object's transform origin.

2 minutes ago, Old Bruce said:

what is happening is that the first rotation is done in relation to the object's bounding box, then the move is done relative to that rotated bounding box, not actual x,y co-ordinates. The second rotation is done in relation to that new bounding box.

Ah, Old Bruce to the rescue!  
Yep, that's exactly what I wanted to say but didn't know how to express it (nota bene in my 3rd language).

Stil, this is not a bug. It's just the method being used.

[SteveR_UK]

IMO as it is,  this Power Dup feature is so unintuitive and illogical.

[thomaso]

1 hour ago, Old Bruce said:

I think what is happening is that the first rotation is done in relation to the object's bounding box, then the move is done relative to that rotated bounding box, not actual x,y co-ordinates.

Do you mean a custom set transform origin is ignored actually, respectively for each single operation always the currently geometric centre of a virtual bounding box of a rotated object? And thus I actually do not see a rotation around the bottom left corner in my mentioned example but just see the transform origin being displayed there at every object while in fact another transform origin gets used in the background for each object and 'power' operation? – If yes, and if by design, isn't this a visual fraud of the interface on purpose?

1 hour ago, loukash said:

Stil, this is not a bug. It's just the method being used.

Sounds like a quote from a Monty Python movie.

Can't the method be the bug? Imagine: A car moves horizontally while its wheels rotate: What method, math or geometry would make it fly?

[loukash]

Just now, thomaso said:

Can't the method be the bug?

No, because the result can be exactly what I want.
Power duplicate is simply missing an option to accomplish what you want.

It's a feature request, not a bug.
As such, definitely a +1 from me.

1 minute ago, thomaso said:

A car

I never had a driving license so any car analogies are totally lost on me. Please try harder.  

[loukash]

8 minutes ago, thomaso said:

Sounds like a quote from a Monty Python movie.

Or: You're holding it wrong!  

[Old Bruce]

17 minutes ago, thomaso said:

A car ... gets pushed horizontally: What method, math or geometry would make it fly?

All you need is a pier or a bridge.

[thomaso]

4 hours ago, Old Bruce said:

To sum up my theory, it appears to rotate then move the x, y distance relative to the rotated bounding box (to the right is now "to the right a bit and down a bit"). What we want is for it to move the distance then rotate.

Yes, this is what I'd expect to happen.
Or: independent of its rotated rectangular bounding box.
Or: with an unmodified bounding box (–> "Cycle Selection Box")
Or: done in the order the user applied the changes to the original object / or maybe done in the order of the fields in the transform panel.

And: in any case with a displayed transform origin in the UI which is indeed used.