|Anonymous | Login||10-23-2021 12:15 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000826||[Croquet] Jasmine||minor||always||01-14-05 01:02||01-27-05 21:06|
|Summary||0000826: TDragger issue|
If you grab an TDragger object with the cursor at say the center of the screen,
and then holding down the mouse button drag it here and there for a while
and then return the cursor to the center of the screen,
the dragged object will no longer be in the center of the screen.
I think the expected behaviour would that each location of the cursor
should correspond to a single location of the TDragger, regardless of
cursor movement history.
The effect can be quite large
and sometimes i lose objects off the side of the viewport
and need to chase them with the avatar.
TDraggerFix-daf.1.cs [^] (2,363 bytes) 01-16-05 17:32
TDraggerFix-oxe.1.cs [^] (1,544 bytes) 01-27-05 21:05
(0001087 - 160 - 160 - 160 - 160 - 160 - 160)
|This happens when you move the object back and and forth; the movement in the plane assume constant distance. It works fine when you only shift-drag the object.|
(0001092 - 427 - 427 - 427 - 427 - 427 - 427)
|Here is a potential fix. This pretty much replaces these methods with code copied fairly directly from TWindow (I just did this same thing for the ODE demos). They now use the local frame of reference instead of the global, for the most part. I was not able to test the methods called when controlKeyPressed is true because when I try to use the control key and left-click or right-click, I get a menu. Is this another bug?|
(0001096 - 398 - 456 - 456 - 456 - 456 - 456)
The fix looks good to me! Thanks!
I made one small modification for myself tho -
i notice that when an object is dragged beyond the horizon,
it 'comes back', which is excellent, but it also moves to
a different plane. (Looks like the plane reflected across Y at the camera).
For my purposes this is inconvenient, so i added the following line right after "delta _ p - p0." :
delta y: 0.0.
(0001100 - 178 - 178 - 178 - 178 - 178 - 178)
|If you make your change so that the movement plane is not reflected when passing the horizon, doesn't that mean that the object is no longer tracking exactly to the mouse cursor?|
(0001101 - 489 - 561 - 561 - 561 - 561 - 561)
but i felt that having a cursor/dragger discrepancy
was preferable to having the dragger move out of its
ie, it seems to me that the behavior of a dragger
in response to a plain click-and-drag should be
to move within the horizontal plane it's already in,
and not move out of it.
another option would be to simply leave the object at
the horizon when the cursor crosses the horizon,
but again it seems more useful to me to have the object return.
(0001102 - 333 - 476 - 476 - 476 - 476 - 476)
note - for those who do want the dragger to remain in the originally specified plane, my fix above should really be the more general this:
"remove component perpendicular to plane"
perp _ plainNormal * (delta dot: plainNormal).
delta _ delta - perp.
(change "delta y: 0." to that)
(0001107 - 163 - 181 - 181 - 181 - 181 - 181)
added change set which corrects for rotation of parent frames
and the TDragger's own rotation.
(it also restricts the dragger to stay in it's original plane :)
|01-14-05 01:02||elenzil||New Issue|
|01-15-05 06:08||andreas||Note Added: 0001087|
|01-15-05 06:08||andreas||Status||new => confirmed|
|01-16-05 17:32||dfaught||File Added: TDraggerFix-daf.1.cs|
|01-16-05 17:37||dfaught||Note Added: 0001092|
|01-24-05 22:34||elenzil||Note Added: 0001096|
|01-25-05 15:15||dfaught||Note Added: 0001100|
|01-25-05 21:23||elenzil||Note Added: 0001101|
|01-26-05 00:50||elenzil||Note Added: 0001102|
|01-27-05 21:05||elenzil||File Added: TDraggerFix-oxe.1.cs|
|01-27-05 21:06||elenzil||Note Added: 0001107|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
62 total queries executed.|
41 unique queries executed.