[Gtkradiant] Update: TranslateFree (Dominant axis movement)

Thu Mar 22 10:10:26 CDT 2007

Hi
I just got  your mail, I am quite familiar with the radiant editors, this tool is just implemented differently obviously, but thx for the advice.

Didn t know of that tool, I just tested it and it works, however its pretty restrictive since you can only move into on direction at a time and it seems you have to disable it in order to select the next vertex vertex.

Maybe add my adjustment as a preference? Since toggle the mode to translate just a few vertices, disable it to select the next vertices... consumes quite some time when working with lots of patches.

cu

-------- Original-Nachricht --------
Datum: Thu, 22 Mar 2007 14:59:04 -0000
Von: "Joseph, William" <WJoseph at europe.ea.com>
An: "Eduard Aumüller" <basiror at gmx.de>
Betreff: RE: [Gtkradiant] Update: TranslateFree  (Dominant axis movement)

> 
> I am completely familiar with the GtkRadiant source code, the current
> behaviour, and the behaviour of all previous versions of GtkRadiant and
> QERadiant.
> 
> Have you used the axis-contrained Translate tool?
> 
> 
> -----Original Message-----
> From: gtkradiant-bounces at zerowing.idsoftware.com
> [mailto:gtkradiant-bounces at zerowing.idsoftware.com] On Behalf Of "Eduard Aumüller"
> Sent: 22 March 2007 14:55
> To: GtkRadiant developer discussion
> Subject: Re: [Gtkradiant] Update: TranslateFree (Dominant axis movement)
> 
> 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
> 
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out