Closed GoogleCodeExporter closed 9 years ago
This one is proving to be quite tricky. It's easy enough to set the
pointGripContainer to be rotated like the poly, which puts the poly point grips
in
the right place. But the problem after that is that the points are displaced
from the
cursor position whenever you try to drag them.
Still looking into it, but if anyone has any suggestions on how to tackle it
that'd
be great.
Original comment by adeve...@gmail.com
on 18 Aug 2009 at 3:57
I agree - this one is tricky.
I think what you're saying is you tried to set the transform on the
pointGripContainer and rotate the whole <g>. I agree, this will be problematic
because people are still dragging in an axis-aligned perspective so I'm not
sure what
that would do to the drag tracking math.
It sounds like if you did this, then you could do some trig math in the
mousemove
function when in polyedit mode to convert the dx,dy into the rotated dx,dy - I
haven't found the time to spend on this one because it's involved.
The only other thing I can think of to fix this is to figure out the rotation
math
and then manually change the coordinates of each point grip in the container.
But
actually, will that help? You'd still have the dragging math problem I think.
I suppose you could always check in what you've done so far and we can try to
figure
out the math afterwards - this would only break poly edit mode for rotated
polys -
and that's already broken anyway! :)
Original comment by codedr...@gmail.com
on 18 Aug 2009 at 4:03
Changed the summary to describe the remaining problem.
Original comment by adeve...@gmail.com
on 18 Aug 2009 at 8:01
Original comment by codedr...@gmail.com
on 18 Aug 2009 at 8:03
Ok, I figured out what the problem is - but I'm not yet sure how to solve it.
I've
checked in my work-in-progress code as r413.
First, some background:
- the rotate feature currently works by figuring out the center of the shape's
bounding box and then rotating the shape a number of degrees around this center
- so a shape could get the transform="rotate(35,200,100)" if the user rotated
it 35
degrees
- if the user then tries to change the shape's size (or shape in the polyedit
case),
this actually affects the bounding box (and thus, its center)
What I've done in my code is figure out what the original rotation center is
(200,100) in my example above by parsing the transform attribute. Then I
determine
the ray from this center to the poly point that I'm dragging. Then I rotate
this ray
into the element's rotated coordinate system. Then I modify the x,y mouse
coordinates by this transform so that the poly point is dragged to the mouse
location.
This works great.
Unfortunately, it breaks subsequent rotations after you've moved a rotated poly
point! :(
So I'm still thinking of the 'right' way to solve this. This is the tenet that
I'm
working from:
- if a user rotates a shape 30 degrees, that shape stays rotated 30 degrees
(even if
they later resize or move the poly's points around)
Original comment by codedr...@gmail.com
on 19 Aug 2009 at 3:49
Original comment by codedr...@gmail.com
on 19 Aug 2009 at 2:31
This is again seriously broken. I may tackle this as part of the experimental
rotator branch.
Original comment by codedr...@gmail.com
on 20 Aug 2009 at 6:25
Finally seem to have solved the math issues in 471. You can:
- edit points in a rotated poly
- resize rotated elements
- translate rotated elements
without unexpected results. Problems can be opened as new issues.
Original comment by codedr...@gmail.com
on 26 Aug 2009 at 5:08
Original issue reported on code.google.com by
codedr...@gmail.com
on 17 Aug 2009 at 3:59