[Gtkradiant] Update: TranslateFree (Dominant axis movement)

"Eduard Aumüller" basiror at gmx.de
Thu Mar 22 09:54:56 CDT 2007


Hi,
I think we are talking about something completely different

The problem that occured prior to my fix happens when editing in the CamWindow and not in the orthogonal views.

Just create a patch , go into the camwindow and try to edit the vertices from a arbitrary direction and you will realise the vertices will move into all 3 x,y,z directions which makes editing in the camwindow useless.

The selection mechanism calculated the offset between the drag point (Lbutton down) and the current cursor location dependent on the device coordinates you pass to the mechanism.
It doesn t care whether it should translate the vertex into all 3 directions
so if you want to move the vertex upwards(z) and into y direction you probably move it into x direction too

In my fix I choose 2 pretty far away coordinates in devices coordinates(0,900) (900,0) to determine the 2 axis influenced the most  and cancle out translation into the 3rd direction

just play around with the current radiant and a fixed version in the CamWindow

this also effects brush editing. The old radiant editors used to behave the same way as my fixed radiant does now

This fix doesn t change the behaviour in the orthogonal views, only in the camwindow


P.S.: maybe replace (0,900) & (900,0) with some much large numbers for the case that someone is using a very high resolution or drags right at the border of the editing window.

(0,2500)(2500,0) should do the job, or remember the drag devices coordinates and add 900 into x&y direction and use this to calculate the most effected axis



-------- Original-Nachricht --------
Datum: Thu, 22 Mar 2007 15:18:25 +0100
Von: namespace <spam at codecreator.net>
An: GtkRadiant developer discussion <gtkradiant at zerowing.idsoftware.com>
Betreff: Re: [Gtkradiant] Update: TranslateFree  (Dominant axis movement)

> Hi!
> 
> Was your cursor inside the yellow box around the center of translation
> axis?
> If so, then the translation is not locked to one axis. This may happen
> by accident, esp. when looking downward as the y-axis becomes very short
> due to perspective projection.
> 
> Maybe I misunderstood your steps to reproduce that bug, but I can't
> reproduce
> multiaxis-translation when selecting just one axis.
> 
> cu
> namespace
> 
> 
> Am Mittwoch, 21. März 2007 08:53 schrieb Eduard Aumüller:
> > Hi,
> >
> > at the current revision the TranslateFree behaves like this:
> >
> > 1. create a patch somewhere on the x-axis
> > 2. in the camera view look parallel to the x-axis
> > 3. rotate the camera at the downwards
> > 4. if you select a vertex of the patch now and move it upwards( mouse
> delta
> > on the y-axis) a lot you will experience that the vertex is translated
> into
> > x-axis direction as well, against your expectations
> >
> > The reason why is because the ray through your mouse cursor is projected
> > onto the far plane and the deltas between  mouse drag(x,y) and mouse
> > drop(x,y) are computed and since you are looking downwards a little a
> > little delta into x-axis direction is computed as well.
> >
> >
> > In my update I have calculated 2 reference directions, moving the cursor
> in
> > window coordinates into (900,0) & (0,900) direction
> >
> > I then calculate the drag&drop delta vectors  and use these to determine
> > the main axis of movement
> >
> > so 2 axis are used and the 3rd axis component of the translation vector
> is
> > cancled out.
> >
> > The result is a translate along the 2 main axis
> >
> > For more information see the selection.cpp.diff
> >
> > Please at this to the svn
> >
> > cu
> 
> -- 
> www.codecreator.net | GPG: 0xD4DB516D

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out



More information about the Gtkradiant mailing list