Re: Low pass filter on quaternions

Linear interpolation and renormalization of quaternions is totally fine. As
always, the standard text on this is:
http://number-none.com/product/Understanding%20Slerp,%20Then%20Not%20Using%2
0It/ 

TomF.


> -----Original Message-----
> From: Fabian Giesen [mailto:[email protected]]
> Sent: Monday, March 29, 2010 10:10 AM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Low pass filter on quaternions
> 
> On 29.03.2010 17:31, Tom Plunket wrote:
> >
> >> The problem is that Quaternions are not quite linear enough. Running
> a
> >> naive filter on the axis component when the rotation is close to
> identity
> >> (and the axis component is small) may cause excessive jitter.
> >
> > Since the rotation is close to zero, though, it doesn't really matter
> if
> > your axis flips all around.  The net result is still one of very
> little
> > rotation.
> >
> >> I'd also be interested in hearing from anyone who has done this in
> anger!
> >
> > Years ago, before I had any idea what quaternions meant, I just did
> > IIR-style filtering on them.  You know, "add 10% of this frame's
> value to
> > 90% of the current frame's value, and use that as the new current
> value."
> > Despite the fact that this is horrifying to many purists, it actually
> > worked out well for the application I was using it in.  Doing this
> with
> > controller input may lead to an undesirable amount of lag, though.
> 
> I don't see any problems with this whatsoever, and don't see why
> "purists" would. Building linear combinations of quaternions (and
> that's
> what filters do) is a perfectly well-defined and reasonable thing to
> do.
> You should normalize the result before you use it though - but don't
> feed the normalized output back into IIR filters, use the unnormalized
> value there (or you introduce nonlinearities into the filter).
> 
> To be clear, the normalization isn't a hack; it's a perfectly fine
> projection operator, and normalize(w_0*q_0 + w_1*q_1 + ...) behaves
> pretty much like one would expect, except for interpolated paths not
> being constant velocity. But all other parametrizations suffer from
> other and usually more serious limitations that make them a lot less
> suitable for filtering in: spherical linear interpolation yields
> constant velocity but requires you to write linear combination betweeen
> 3 or more participants as blend tree, and different ways of building
> this tree yield different results; Euler angles have gimbal lock and
> the
> interpolation between rotations "a" and "b" doesn't take the shortest
> path between them; taking the log of a and b, interpolating, then
> exponentiating likewise doesn't take the shortest path. The rotation
> group SO(3) is fundamentally non-flat; as a result, there's no "right"
> way to linearize rotations and interpolate/filter them, just different
> ways to get rid of the curvature with different tradeoffs.
> 
> And yes, the "axis component" is jittery if your rotation is close to
> identity, but that's perfectly reasonable. A rotation of 1e-5 radians
> around the x axis *is* similar to a rotation of 1e-5 radians around the
> axis (0.8,0.6,0), by any reasonable metric - distance of the resulting
> rotation matrix to the identity matrix in any matrix norm, relative
> error of transformed points, or plain magnitude of the angle. The axis
> for small rotations isn't jittery because of anything to do with the
> quaternion representation, it's jittery because the problem of finding
> the axis of rotation is inherently ill-posed for a transformation
> that's
> close to identity.
> 
> But the quaternion doesn't store (axis, angle), it stores
> (cos(angle/2),
> sin(angle/2)*axis), and that is perfectly well-behaved near identity.
> 
> > When this question was posed, I started wondering how they do it on
> mouse
> > drivers, since there is no apparent lag between me moving the mouse
> and
> > the cursor moving on the screen.  Maybe the solution there is that
> they
> > run at a much higher sample rate?  Maybe the filtering is done in
> > hardware?
> 
> Mouse driver's dont filter. The only transform applied to the input
> mickeys (=x/y deltas) is pointer ballistics (which, roughly speaking,
> makes slow mouse movements slower and fast movements faster), but
> there's no noise at all in what you get from the hardware. As long as
> the mouse doesn't move, you really do get exactly zero, every frame.
> 
> I don't know whether the hardware does any filtering or if the
> mechanisms are inherently noise-resilient (as old mechanical and
> opto-mechanical mice were), but what you get from the hardware via USB
> is already perfectly clean.
> 
> -Fabian
> 
> -----------------------------------------------------------------------
> -------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> GDAlgorithms-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-
> list
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.437 / Virus Database: 271.1.1/2742 - Release Date:
> 03/29/10 06:32:00


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list