Cmd+J Duplication (Rotation out of alignment?)

[firstdefence]

Hi all, not sure whether I've found a bug or its just me not seeing a simple mistake. duplication issue.afdesign

 

Here's what I do...

• I create a document 2000px x 2000px
• I use Guide Manager to place guides at 50% horizontally and vertically.
• I create a path with a stroke of .25px Align: centre. Stroke size doesn't really matter, as it does not affect the outcome. The path can be placed either vertically, horizontally or restricted to 45º The 45º angle was to get a path length that would not fall short in the document but it doesn't matter really these are just the placements I have tried as starting points.
• Checked paths rotational node placement was 1000, 1000px
• I moved the paths rotation centre to the centre of the document (1000,1000px)
• Initially I wanted to rotate by 5º but noticed as I duplicated the paths the duplicated paths were out of alignment at 90º, 180º and 270º 
• To test I created the path again and duplicated by the restricted 15º by holding shift down as I rotated, this aligned to the 90º, 180º and 270º correctly.
• So, I tried rotation by 5º again and this confirmed the misalignment. 
• If you continue the duplication the offset is equal and you will end up with consistent bands.
• Continued duplication by the restricted 15º always keeps alignment
• I made two groups one coloured black and one coloured pink, the starting path's are both accurately aligned at the vertical point, once you start rotating thats when it all goes wrong.

 

So it really shouldn't be misaligned if 15º can align why can't 5º

 

 

Pink is the 5º duplication

 

 

[dutchshader]

looks like it is going wrong after this curve

 

 the upper pink curve has a rotation of -4.7 

[firstdefence]

[firstdefence]

Morning @dutchshader It seems to vary, I tried with pixel alignment and whole pixels, removed all snapping and a few combinations in-between. I'll try some different degrees, like 2.5º, 7.5º and maybe 10º

 

Edit: 10º fails,

I thought at first it was something to do with document bounds because I created the path within the document just for ease as I was going to make the video above, so, I ran a test and at one point I did actually get the 5º to rotate on point, so I deleted the paths and tried again to make the video, bear in mind I changed nothing in between, no zoom etc, l checked node locations and rotational centres were accurate and lo and behold it went out of whack?

[dutchshader]

it seams to work ok when you enter the rotation in the transform pannel

[firstdefence]

Yeah I just tried that and it works every time 

[firstdefence]

Must be when rotated manually it reads as 5º but its actually more like 5.01º

You reckon this is a bug?

[carl123]

The Rotation field allows you to enter values such as 4.98 degrees and that value will be honoured but it will display at 5 degrees because the Rotation field only has one decimal place available.

This to me is more a display/design issue for the Rotation field rather than a bug as the other main fields in the Transform panel allows you to display up to 6 decimal places

[Dan C]

Morning firstdefence

This is not a bug as such, it is a byproduct of the manual rotation degree amount being rounded in the overlay tag. As you have mentioned, if you set the rotation amount precisely in the transform the the smart duplication continues as it should, however if you have manually rotated the object the tag (and transform panel) will display to the nearest one decimal place however the rotation will not be this precise having being transformed manually and the overlay tag is kept simple to avoid screen clutter.

As @carl123 has said; 

4 minutes ago, carl123 said:

This to me is more a display/design issue for the Rotation field rather than a bug as the other main fields in the Transform panel allows you to display up to 6 decimal places

I am logging this directly with our developers, as I see little reason why the rotation field could not show the exact rotation amount down to 6 decimal places as with the rest of the transform panel. Precision is key!

[R C-R]

1 minute ago, Dan C said:

I am logging this directly with our developers, as I see little reason why the rotation field could not show the exact rotation amount down to 6 decimal places as with the rest of the transform panel.

That would be nice (& it is something I think I remember asking for in the feature request section), but it won't help when users manually rotate things on the canvas by dragging on the rotation handle -- I seriously doubt there is any way to do manual rotation at 6 decimal places of precision! This addition could show you how far off the desired rotation angle you are, but to get that kind of precision you still have to use the R field.

 

I am also not sure what the actual internal rotation precision is, but I know that by using expressions like 360/17 in the R field & using power duplicate the 18th duplicate precisely aligns with the first one. I have tested R values up to 360/359 & the 360th dup still aligns precisely: 360 lines.afdesign

 

This suggests to me that internally the precision may be substantially higher than 6 decimal places....

[Dan C]

I'm not certain who the first reporter was, but I have found the issue in our development system and have effectively 'bumped' the thread by one, including this forum link

6 minutes ago, R C-R said:

I seriously doubt there is any way to do manual rotation at 6 decimal places of precision!

You and me both!

I believe the internal system uses floating-point arithmetic (which I don't mind admitting is somewhat over my head...) but essentially this means that the value will always show as rounded externally, be that to 1 or 6 decimal places, whereas the internal precision will always be as many decimal places as it requires and using your division formula will always equal 360°.

[firstdefence]

lets hope it gets improved/tweaked. At least I have another method of input so its not such a issue, so I will use the Transform Panels R: input until it gets improved, thanks for bumping it up.

 

Bump up the Dup
Bump it up
While your paths are turning
And the turns are failing
Look ahead, the coder is coding'

Bump it up a little more,

Get the coding goin' on the 3rd floor,
See, cause that's where the codings at,
And you'd find out if you do that...

 

Word!

 

You know I learn so much from you guys, I've got a brainiac forehead now.

[R C-R]

Just now, firstdefence said:

At least I have another method of input so its not such a issue, so I will use the Transform Panels R: input until it gets improved, thanks for bumping it up.

How could the manual method be improved? The incremental angle for power duplicates could be anything -- there is no particular reason to limit it to integer degrees, half degrees, or any other value. Consider that for example users might want 7, 9, 11, or any other arbitrary number of duplicates, only a few of which are evenly divisible into 360.

 

The Transform Panels R: value method works perfectly for any number of dups. Isn't that not just good enough but preferable to trying to drag a rotation handle to exactly what you want it to be?

[firstdefence]

4 hours ago, R C-R said:

How could the manual method be improved? The incremental angle for power duplicates could be anything -- there is no particular reason to limit it to integer degrees, half degrees, or any other value. Consider that for example users might want 7, 9, 11, or any other arbitrary number of duplicates, only a few of which are evenly divisible into 360.

 

The Transform Panels R: value method works perfectly for any number of dups. Isn't that not just good enough but preferable to trying to drag a rotation handle to exactly what you want it to be?

I want to have my cake and eat it and I see nothing wrong with being hands-on and wanting to rotate an object with the rotate handle and it be an accurate movement in degrees, so, maybe a "fix to integer" checkbox would be a positive move, after all how many times do you need to rotate something 5.476215º

 

As it is, using R: is fine, Its just when you have an option to do something like rotation then I think it's reasonable for you to expect it to give you accurate feedback and be what it says, not, its 5.6435261º but we'll tell him its 5º

I like the hands on approach as well as punching numbers into boxes, makes me feel arty 

[carl123]

Holding the Shift key down fixes the hands on rotation approach to 15 degree jumps

Maybe the CTRL key or ALT key can be programmed to restrict manual rotation to integer values only

[R C-R]

55 minutes ago, firstdefence said:

As it is, using R: is fine, Its just when you have an option to do something like rotation then I think it's reasonable for you to expect it to give you accurate feedback and be what it says, not, its 5.6435261º but we'll tell him its 5º

But since the angle (apparently) is represented using floating point math, the actual number could extend to considerably more than 6 decimal places: if for example internally it is using 'double precision' (64 bit) f.p. digital math, the value would be significant to about 16 decimal digits. My guess is it is using less than 64 bit f.p. math (if it is indeed using f.p. math), but it seems likely it is more than 7 or 8 places.

 

Besides, just converting between binary & decimal representations, whether it is using integer or f.p. math internally, will incur a rounding error for many values, so in a sense the app has no choice & must give inaccurate feedback to users.

 

As for some option to constrain the rotation handle to snapping to 1° increments, consider how difficult it could be to actually use that -- depending on the zoom level & size of the object on the canvas, it could take an extremely steady hand to hit the desired angle. Plus, philosophically this does not seem very "arty" to me, at least in the sense of "hand drawn" or "freeform expression."

[firstdefence]

The solution is to use the R:

 

Why the R: can do it but moving the handle can't baffles me a little and the fact that, with <Shift> held down I can accurately rotate an object would suggest to me that it can actually be done and that having a setting in preferences to adjust the constrained rotation from 15º to a degree of your choosing is actually possible, because surely it would implement whatever math the R: is using?

[R C-R]

The math for 15° increments works out nicely; for 1° increments not so much. 

 

20+ years ago, I could have explained why that is so clearly & succinctly, Sadly, that time has long since past. 

[firstdefence]

It would go over my head R C-R 

[lepr]

.

 

[R C-R]

8 hours ago, owenr said:

The angle of rotation while you drag is calculated by elementary trigonometry from the pointer location relative to the pivot location.

I am not sure I can explain this very well & I am not certain of the details anyway, but with that in mind I think it may not be quite that simple. That is because the pointer's actual location is given in screen coordinates, which then have to be mapped to document coordinates at the current zoom level. Since that mapping rarely is a perfect 1:1 match, the pointer's location on the screen usually is an approximation of its actual location in terms of the document's coordinates. IOW, there is a small but variable amount of uncertainty about its actual location, which carries through to the snappedAngle calculation as part of the angle value.

 

That should not be much of a problem if the snap increment is reasonably large (like 15°) but as it is reduced toward zero the uncertainty begins to dominate the results, making precise snapping increasingly difficult. That is not an issue when using the Transform panel because everything there is done in 'document space' with no need to map anything to it from 'display space,' so to speak.

 

Does that make any sense?

[lepr]

.

[R C-R]

36 minutes ago, owenr said:

The whole point of snapping to an increment is that the user does not need to precisely position the pointer!

Yes, of course. But that works only when the increment is large enough that the inherent imprecision of the pointer's actual position in document coordinate space doesn't matter. IOW, the numeric x & y coordinates of the pointer on the screen & its numeric x & y coordinates in the document are not the same thing, & that must be taken into account.

 

Do you see what I mean?

[lepr]

.

[R C-R]

13 minutes ago, owenr said:

Rotating by one degree increments, for example, is easily achieved when the pointer is several centimeters (in screen space) from the pivot.

Except that you aren't actually rotating by exact, one degree increments, which would be more obvious if the callout displayed more decimal places.