gdalgorithms-list

Re: [Algorithms] Network prediction algorithms specific to racing?

[Jamie F. <ja...@qu...>]

Jason Hughes wrote:

[snip]

> It does occur to me that it may not be possible to mathematically map 
> uniquely into track space easily, but an artist could very well use a 
> good UV layout tool to create a giant flowing UV shell that could at 
> least create a fairly good coordinate space for the whole track.  
> Positive in U means heading straight along the track, V would be the 
> lateral axis.  There would definitely be discontinuities when branches 
> met, or when the player left the track (sometimes), but it could be done 
> with existing tools in human-aided fashion.  The very same mapping could 
> also use that for helping AI drive, come to think of it.  It's 
> effectively an artist-generated influence map at that point.

We used this on PS1 for a racing game (which wasn't released) back in 
'98; although the hint was per track quad rather than in a texture. The 
track was divided into strips of quads, and each quad had a vector 
associated with it that the AI used as a hint for what it should be 
doing. Worked fine in the end, but testing and debugging was a pain, as 
you'd have to first find a problem (test and test until a car hits 
something that misbehaves), work out which vector(s) gave bad hints, 
then tweak them... then test and test and test to see if the problem had 
gone away.

The plus side: it was fast; we had 30 racing cars on that little old PS1.

Jamie

> JH
> 
> On 4/15/2010 6:47 PM, Blair Holloway wrote:
>> Shawn Hargreaves wrote on his blog about having a track-space 
>> coordinate system in MotoGP:
>>
>> blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx 
>> <http://blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx>
>>
>> If you were to have the player's position and velocity transmitted in 
>> track space coordinates instead of world space, you'd be able to do 
>> dead reckoning in that space entirely - i.e. reckon forward based on 
>> the player's local track velocity rather than their world space 
>> velocity. As long as the player is on the track and not, say, driving 
>> perpendicular to it, the player would always interpolate along the 
>> track, even on corners.
>>
>> Corners are likely to be, quite literally, one of your corner cases, 
>> due to players needing to slow down to corner correctly - something 
>> the reckoning/interpolation would need to take into account. 
>> Additionally, if the player is driving fast diagonally across the 
>> track, there may be cases where he would be reckoned outside of the 
>> track, in which case you might need to detect those cases and switch 
>> to a world space prediction method.
>>
>> - Blair
>>
>> On Fri, Apr 16, 2010 at 7:50 AM, Megan Fox <sha...@gm... 
>> <mailto:sha...@gm...>> wrote:
>>
>>     At present, we have a fairly terrible scheme that amounts to no real
>>     rectification or prediction AND a dead-space that allows out-of-sync
>>     conditions to get around how jumpy it would be without it.  Not so
>>     good.  I was pulled off my other tasks and re-assigned to make it not
>>     suck / take it to polished instead of prototype, basically.
>>
>>     My suspicion is that dead reckoning (ie. like you say, simple
>>     extrapolation from last known pos/vel) will be "ok", but that it will
>>     tend to not produce the smooth arcs I'd like to see in a cart racer.
>>     I'm also not convinced that a second or third degree prediction from
>>     sampling the prior positions would be anywhere near usable if the
>>     player ever deviated from smooth arc driving.  So, just thought I'd
>>     see if there were any particular known-better-case solutions, given
>>     that it's a well-trodden domain.
>>
>>     On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes
>>     <jh...@st... <mailto:jh...@st...>>
>>     wrote:
>>     > I guess there are two aspects of this: prediction and visual
>>     rectification.
>>     >
>>     > We've been doing a networked basketball game recently, where one
>>     team is
>>     > entirely controlled remotely.  Even with fairly high latency, slow
>>     > moving objects (like players) will look okay using a smooth
>>     > rectification algorithm, but they're a little delayed from
>>     real-time.
>>     > High velocity objects  (ie. bullets or ballistic objects) are pretty
>>     > easy to sync as well, provided they are not controlled or
>>     intelligent.
>>     > The main issues we've had thus far involve rectifying the ball
>>     physical
>>     > state after a collision with a player, since that's often
>>     incorrect and
>>     > delayed.  Luckily, most collisions in basketball games result in the
>>     > ball being grabbed, so this isn't always an issue.  For
>>     reference, our
>>     > simple rectification code is X = Lerp(X, X', f), where f could vary
>>     > depending on the latency and current error.  Spline
>>     rectification would
>>     > be nicer, and we might implement that, though it may be overkill
>>     for us.
>>     >
>>     > I haven't tried prediction beyond simple linear extrapolation
>>     based on
>>     > the last single sample (position, velocity, orientation).  1st order
>>     > prediction would likely close most of the gaps for generally smooth
>>     > functions like position and orientation, but for velocity, I'm
>>     not sure
>>     > it would help in our case, since the velocity is basically joystick
>>     > angle for us and is generally discontinuous.
>>     >
>>     > Sorry I can't be more help with racing specifically.  Out of
>>     curiosity,
>>     > what have you tried and how did it work?
>>     >
>>     > Thanks,
>>     > JH
>>     >
>>     > Jason Hughes
>>     > President
>>     > Steel Penny Games, Inc.
>>     > Austin, TX
>>     >
>>     >
>>     > On 4/15/2010 3:34 PM, Megan Fox wrote:
>>     >> I'm currently fiddling with dead reckoning for a racing game I'm
>>     >> working on, but this seems like a specific enough domain that there
>>     >> ought to be specific-to-racing prediction approaches.  We have a
>>     >> fairly good idea of what the player is doing (trying to stay on the
>>     >> track), and that would seem to give more data that isn't really
>>     being
>>     >> exploited with standard approaches - but googling isn't turning up
>>     >> much.
>>     >>
>>     >> Do such algorithms exist?  Or, in practice, are the same approaches
>>     >> used in FPSes et al still the ones to use here?
>>     >>
>>     >>
>>     >
>>     >
>>     ------------------------------------------------------------------------------
>>     > Download Intel&#174; 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
>>     > GDA...@li...
>>     <mailto:GDA...@li...>
>>     > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>>     > Archives:
>>     >
>>     http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>     >
>>
>>
>>
>>     --
>>     Megan Fox
>>     http://www.shalinor.com/

Re: [Algorithms] Network prediction algorithms specific to racing?

[Darrell B. <db...@su...>]

I recently worked on a peer to peer cart racing game and we experimented
with dead reckoning and 2nd order polynomial interpolation but in the
end we found that simple linear interpolation gave us the smoothest
results in most cases.
 
We sent packets with compressed data for the position and orientation
and because the data was small enough we got away with sending 15
packets per second so the error margin was always quite small. Also, if
we'd used a delta compression method we could probably have increased
the send rate too.
 
Interestingly enough, we looked at compressing the position based on
track location but our tracks were fully 3D (loops, upside-down track,
jumps etc.) so with the extra information that would have been required
we didn't actually save that much more than if we just compressed the
cartesian coordinates. If you know the dimensions of the track and
therefore all the possible positions a racer can be in then you can
compress within a certain range of values which brings the data size
down too.
 
Darrell
 


________________________________

From: Jason Hughes [mailto:jh...@st...] 
Sent: 16 April 2010 07:25
To: gda...@li...
Subject: Re: [Algorithms] Network prediction algorithms specific to
racing?


Interesting.  A set of track space coordinates, unfortunately, does not
map continuously nor uniquely onto the cartesian world space, however.
Except with a drag strip.  :-)  Even an oval would have a discontinuity
at the checkered flag.  Shortcuts, branches, or even places where an
object might move jump between levels (fall off an upper deck to a lower
one) would be severe and unpredictable discontinuities in that space.
That severely impinges on the usefulness for prediction.

(Aside: I recently ran into this problem when implementing a spline
following camera system that indexes the spline directly based on the
position of the hero character.  Due to curvature of the spline, there
are multiple valid associated camera positions associated with a single
world-space point.)

It does occur to me that it may not be possible to mathematically map
uniquely into track space easily, but an artist could very well use a
good UV layout tool to create a giant flowing UV shell that could at
least create a fairly good coordinate space for the whole track.
Positive in U means heading straight along the track, V would be the
lateral axis.  There would definitely be discontinuities when branches
met, or when the player left the track (sometimes), but it could be done
with existing tools in human-aided fashion.  The very same mapping could
also use that for helping AI drive, come to think of it.  It's
effectively an artist-generated influence map at that point.

JH

On 4/15/2010 6:47 PM, Blair Holloway wrote: 

	Shawn Hargreaves wrote on his blog about having a track-space
coordinate system in MotoGP: 

	
blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.
aspx

	If you were to have the player's position and velocity
transmitted in track space coordinates instead of world space, you'd be
able to do dead reckoning in that space entirely - i.e. reckon forward
based on the player's local track velocity rather than their world space
velocity. As long as the player is on the track and not, say, driving
perpendicular to it, the player would always interpolate along the
track, even on corners.

	Corners are likely to be, quite literally, one of your corner
cases, due to players needing to slow down to corner correctly -
something the reckoning/interpolation would need to take into account.
Additionally, if the player is driving fast diagonally across the track,
there may be cases where he would be reckoned outside of the track, in
which case you might need to detect those cases and switch to a world
space prediction method.

	- Blair

	On Fri, Apr 16, 2010 at 7:50 AM, Megan Fox <sha...@gm...>
wrote:
	

		At present, we have a fairly terrible scheme that
amounts to no real
		rectification or prediction AND a dead-space that allows
out-of-sync
		conditions to get around how jumpy it would be without
it.  Not so
		good.  I was pulled off my other tasks and re-assigned
to make it not
		suck / take it to polished instead of prototype,
basically.
		
		My suspicion is that dead reckoning (ie. like you say,
simple
		extrapolation from last known pos/vel) will be "ok", but
that it will
		tend to not produce the smooth arcs I'd like to see in a
cart racer.
		I'm also not convinced that a second or third degree
prediction from
		sampling the prior positions would be anywhere near
usable if the
		player ever deviated from smooth arc driving.  So, just
thought I'd
		see if there were any particular known-better-case
solutions, given
		that it's a well-trodden domain.
		

		On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes
		<jh...@st...> wrote:
		> I guess there are two aspects of this: prediction and
visual rectification.
		>
		> We've been doing a networked basketball game recently,
where one team is
		> entirely controlled remotely.  Even with fairly high
latency, slow
		> moving objects (like players) will look okay using a
smooth
		> rectification algorithm, but they're a little delayed
from real-time.
		> High velocity objects  (ie. bullets or ballistic
objects) are pretty
		> easy to sync as well, provided they are not controlled
or intelligent.
		> The main issues we've had thus far involve rectifying
the ball physical
		> state after a collision with a player, since that's
often incorrect and
		> delayed.  Luckily, most collisions in basketball games
result in the
		> ball being grabbed, so this isn't always an issue.
For reference, our
		> simple rectification code is X = Lerp(X, X', f), where
f could vary
		> depending on the latency and current error.  Spline
rectification would
		> be nicer, and we might implement that, though it may
be overkill for us.
		>
		> I haven't tried prediction beyond simple linear
extrapolation based on
		> the last single sample (position, velocity,
orientation).  1st order
		> prediction would likely close most of the gaps for
generally smooth
		> functions like position and orientation, but for
velocity, I'm not sure
		> it would help in our case, since the velocity is
basically joystick
		> angle for us and is generally discontinuous.
		>
		> Sorry I can't be more help with racing specifically.
Out of curiosity,
		> what have you tried and how did it work?
		>
		> Thanks,
		> JH
		>
		> Jason Hughes
		> President
		> Steel Penny Games, Inc.
		> Austin, TX
		>
		>
		> On 4/15/2010 3:34 PM, Megan Fox wrote:
		>> I'm currently fiddling with dead reckoning for a
racing game I'm
		>> working on, but this seems like a specific enough
domain that there
		>> ought to be specific-to-racing prediction approaches.
We have a
		>> fairly good idea of what the player is doing (trying
to stay on the
		>> track), and that would seem to give more data that
isn't really being
		>> exploited with standard approaches - but googling
isn't turning up
		>> much.
		>>
		>> Do such algorithms exist?  Or, in practice, are the
same approaches
		>> used in FPSes et al still the ones to use here?
		>>
		>>
		>
		>
------------------------------------------------------------------------
------
		> Download Intel&#174; 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
		> GDA...@li...
		>
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
		> Archives:
		>
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t
		>
		
		
		
		
		--
		Megan Fox
		http://www.shalinor.com/
		
	
------------------------------------------------------------------------
------
		
		Download Intel&#174; 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
		GDA...@li...
	
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
		Archives:
	
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t
		


	
	
------------------------------------------------------------------------
------
	Download Intel&#174; 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
	GDA...@li...
	https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
	Archives:
	
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t

Re: [Algorithms] Network prediction algorithms specific to racing?

[Jason H. <jh...@st...>]

Interesting.  A set of track space coordinates, unfortunately, does not 
map continuously nor uniquely onto the cartesian world space, however.  
Except with a drag strip.  :-)  Even an oval would have a discontinuity 
at the checkered flag.  Shortcuts, branches, or even places where an 
object might move jump between levels (fall off an upper deck to a lower 
one) would be severe and unpredictable discontinuities in that space.  
That severely impinges on the usefulness for prediction.

(Aside: I recently ran into this problem when implementing a spline 
following camera system that indexes the spline directly based on the 
position of the hero character.  Due to curvature of the spline, there 
are multiple valid associated camera positions associated with a single 
world-space point.)

It does occur to me that it may not be possible to mathematically map 
uniquely into track space easily, but an artist could very well use a 
good UV layout tool to create a giant flowing UV shell that could at 
least create a fairly good coordinate space for the whole track.  
Positive in U means heading straight along the track, V would be the 
lateral axis.  There would definitely be discontinuities when branches 
met, or when the player left the track (sometimes), but it could be done 
with existing tools in human-aided fashion.  The very same mapping could 
also use that for helping AI drive, come to think of it.  It's 
effectively an artist-generated influence map at that point.

JH

On 4/15/2010 6:47 PM, Blair Holloway wrote:
> Shawn Hargreaves wrote on his blog about having a track-space 
> coordinate system in MotoGP:
>
> blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx 
> <http://blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx>
>
> If you were to have the player's position and velocity transmitted in 
> track space coordinates instead of world space, you'd be able to do 
> dead reckoning in that space entirely - i.e. reckon forward based on 
> the player's local track velocity rather than their world space 
> velocity. As long as the player is on the track and not, say, driving 
> perpendicular to it, the player would always interpolate along the 
> track, even on corners.
>
> Corners are likely to be, quite literally, one of your corner cases, 
> due to players needing to slow down to corner correctly - something 
> the reckoning/interpolation would need to take into account. 
> Additionally, if the player is driving fast diagonally across the 
> track, there may be cases where he would be reckoned outside of the 
> track, in which case you might need to detect those cases and switch 
> to a world space prediction method.
>
> - Blair
>
> On Fri, Apr 16, 2010 at 7:50 AM, Megan Fox <sha...@gm... 
> <mailto:sha...@gm...>> wrote:
>
>     At present, we have a fairly terrible scheme that amounts to no real
>     rectification or prediction AND a dead-space that allows out-of-sync
>     conditions to get around how jumpy it would be without it.  Not so
>     good.  I was pulled off my other tasks and re-assigned to make it not
>     suck / take it to polished instead of prototype, basically.
>
>     My suspicion is that dead reckoning (ie. like you say, simple
>     extrapolation from last known pos/vel) will be "ok", but that it will
>     tend to not produce the smooth arcs I'd like to see in a cart racer.
>     I'm also not convinced that a second or third degree prediction from
>     sampling the prior positions would be anywhere near usable if the
>     player ever deviated from smooth arc driving.  So, just thought I'd
>     see if there were any particular known-better-case solutions, given
>     that it's a well-trodden domain.
>
>     On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes
>     <jh...@st... <mailto:jh...@st...>>
>     wrote:
>     > I guess there are two aspects of this: prediction and visual
>     rectification.
>     >
>     > We've been doing a networked basketball game recently, where one
>     team is
>     > entirely controlled remotely.  Even with fairly high latency, slow
>     > moving objects (like players) will look okay using a smooth
>     > rectification algorithm, but they're a little delayed from
>     real-time.
>     > High velocity objects  (ie. bullets or ballistic objects) are pretty
>     > easy to sync as well, provided they are not controlled or
>     intelligent.
>     > The main issues we've had thus far involve rectifying the ball
>     physical
>     > state after a collision with a player, since that's often
>     incorrect and
>     > delayed.  Luckily, most collisions in basketball games result in the
>     > ball being grabbed, so this isn't always an issue.  For
>     reference, our
>     > simple rectification code is X = Lerp(X, X', f), where f could vary
>     > depending on the latency and current error.  Spline
>     rectification would
>     > be nicer, and we might implement that, though it may be overkill
>     for us.
>     >
>     > I haven't tried prediction beyond simple linear extrapolation
>     based on
>     > the last single sample (position, velocity, orientation).  1st order
>     > prediction would likely close most of the gaps for generally smooth
>     > functions like position and orientation, but for velocity, I'm
>     not sure
>     > it would help in our case, since the velocity is basically joystick
>     > angle for us and is generally discontinuous.
>     >
>     > Sorry I can't be more help with racing specifically.  Out of
>     curiosity,
>     > what have you tried and how did it work?
>     >
>     > Thanks,
>     > JH
>     >
>     > Jason Hughes
>     > President
>     > Steel Penny Games, Inc.
>     > Austin, TX
>     >
>     >
>     > On 4/15/2010 3:34 PM, Megan Fox wrote:
>     >> I'm currently fiddling with dead reckoning for a racing game I'm
>     >> working on, but this seems like a specific enough domain that there
>     >> ought to be specific-to-racing prediction approaches.  We have a
>     >> fairly good idea of what the player is doing (trying to stay on the
>     >> track), and that would seem to give more data that isn't really
>     being
>     >> exploited with standard approaches - but googling isn't turning up
>     >> much.
>     >>
>     >> Do such algorithms exist?  Or, in practice, are the same approaches
>     >> used in FPSes et al still the ones to use here?
>     >>
>     >>
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Download Intel&#174; 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
>     > GDA...@li...
>     <mailto:GDA...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>     > Archives:
>     >
>     http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>     >
>
>
>
>     --
>     Megan Fox
>     http://www.shalinor.com/
>
>     ------------------------------------------------------------------------------
>     Download Intel&#174; 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
>     GDA...@li...
>     <mailto:GDA...@li...>
>     https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>     Archives:
>     http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Network prediction algorithms specific to racing?

[Blair H. <thy...@ch...>]

Shawn Hargreaves wrote on his blog about having a track-space coordinate
system in MotoGP:

blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx

<http://blogs.msdn.com/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx>If
you were to have the player's position and velocity transmitted in track
space coordinates instead of world space, you'd be able to do dead reckoning
in that space entirely - i.e. reckon forward based on the player's local
track velocity rather than their world space velocity. As long as the player
is on the track and not, say, driving perpendicular to it, the player would
always interpolate along the track, even on corners.

Corners are likely to be, quite literally, one of your corner cases, due to
players needing to slow down to corner correctly - something the
reckoning/interpolation would need to take into account. Additionally, if
the player is driving fast diagonally across the track, there may be cases
where he would be reckoned outside of the track, in which case you might
need to detect those cases and switch to a world space prediction method.

- Blair

On Fri, Apr 16, 2010 at 7:50 AM, Megan Fox <sha...@gm...> wrote:

> At present, we have a fairly terrible scheme that amounts to no real
> rectification or prediction AND a dead-space that allows out-of-sync
> conditions to get around how jumpy it would be without it.  Not so
> good.  I was pulled off my other tasks and re-assigned to make it not
> suck / take it to polished instead of prototype, basically.
>
> My suspicion is that dead reckoning (ie. like you say, simple
> extrapolation from last known pos/vel) will be "ok", but that it will
> tend to not produce the smooth arcs I'd like to see in a cart racer.
> I'm also not convinced that a second or third degree prediction from
> sampling the prior positions would be anywhere near usable if the
> player ever deviated from smooth arc driving.  So, just thought I'd
> see if there were any particular known-better-case solutions, given
> that it's a well-trodden domain.
>
> On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes
> <jh...@st...> wrote:
> > I guess there are two aspects of this: prediction and visual
> rectification.
> >
> > We've been doing a networked basketball game recently, where one team is
> > entirely controlled remotely.  Even with fairly high latency, slow
> > moving objects (like players) will look okay using a smooth
> > rectification algorithm, but they're a little delayed from real-time.
> > High velocity objects  (ie. bullets or ballistic objects) are pretty
> > easy to sync as well, provided they are not controlled or intelligent.
> > The main issues we've had thus far involve rectifying the ball physical
> > state after a collision with a player, since that's often incorrect and
> > delayed.  Luckily, most collisions in basketball games result in the
> > ball being grabbed, so this isn't always an issue.  For reference, our
> > simple rectification code is X = Lerp(X, X', f), where f could vary
> > depending on the latency and current error.  Spline rectification would
> > be nicer, and we might implement that, though it may be overkill for us.
> >
> > I haven't tried prediction beyond simple linear extrapolation based on
> > the last single sample (position, velocity, orientation).  1st order
> > prediction would likely close most of the gaps for generally smooth
> > functions like position and orientation, but for velocity, I'm not sure
> > it would help in our case, since the velocity is basically joystick
> > angle for us and is generally discontinuous.
> >
> > Sorry I can't be more help with racing specifically.  Out of curiosity,
> > what have you tried and how did it work?
> >
> > Thanks,
> > JH
> >
> > Jason Hughes
> > President
> > Steel Penny Games, Inc.
> > Austin, TX
> >
> >
> > On 4/15/2010 3:34 PM, Megan Fox wrote:
> >> I'm currently fiddling with dead reckoning for a racing game I'm
> >> working on, but this seems like a specific enough domain that there
> >> ought to be specific-to-racing prediction approaches.  We have a
> >> fairly good idea of what the player is doing (trying to stay on the
> >> track), and that would seem to give more data that isn't really being
> >> exploited with standard approaches - but googling isn't turning up
> >> much.
> >>
> >> Do such algorithms exist?  Or, in practice, are the same approaches
> >> used in FPSes et al still the ones to use here?
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; 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
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> >
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
> >
>
>
>
> --
> Megan Fox
> http://www.shalinor.com/
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] Network prediction algorithms specific to racing?

[Megan F. <sha...@gm...>]

At present, we have a fairly terrible scheme that amounts to no real
rectification or prediction AND a dead-space that allows out-of-sync
conditions to get around how jumpy it would be without it.  Not so
good.  I was pulled off my other tasks and re-assigned to make it not
suck / take it to polished instead of prototype, basically.

My suspicion is that dead reckoning (ie. like you say, simple
extrapolation from last known pos/vel) will be "ok", but that it will
tend to not produce the smooth arcs I'd like to see in a cart racer.
I'm also not convinced that a second or third degree prediction from
sampling the prior positions would be anywhere near usable if the
player ever deviated from smooth arc driving.  So, just thought I'd
see if there were any particular known-better-case solutions, given
that it's a well-trodden domain.

On Thu, Apr 15, 2010 at 3:25 PM, Jason Hughes
<jh...@st...> wrote:
> I guess there are two aspects of this: prediction and visual rectification.
>
> We've been doing a networked basketball game recently, where one team is
> entirely controlled remotely.  Even with fairly high latency, slow
> moving objects (like players) will look okay using a smooth
> rectification algorithm, but they're a little delayed from real-time.
> High velocity objects  (ie. bullets or ballistic objects) are pretty
> easy to sync as well, provided they are not controlled or intelligent.
> The main issues we've had thus far involve rectifying the ball physical
> state after a collision with a player, since that's often incorrect and
> delayed.  Luckily, most collisions in basketball games result in the
> ball being grabbed, so this isn't always an issue.  For reference, our
> simple rectification code is X = Lerp(X, X', f), where f could vary
> depending on the latency and current error.  Spline rectification would
> be nicer, and we might implement that, though it may be overkill for us.
>
> I haven't tried prediction beyond simple linear extrapolation based on
> the last single sample (position, velocity, orientation).  1st order
> prediction would likely close most of the gaps for generally smooth
> functions like position and orientation, but for velocity, I'm not sure
> it would help in our case, since the velocity is basically joystick
> angle for us and is generally discontinuous.
>
> Sorry I can't be more help with racing specifically.  Out of curiosity,
> what have you tried and how did it work?
>
> Thanks,
> JH
>
> Jason Hughes
> President
> Steel Penny Games, Inc.
> Austin, TX
>
>
> On 4/15/2010 3:34 PM, Megan Fox wrote:
>> I'm currently fiddling with dead reckoning for a racing game I'm
>> working on, but this seems like a specific enough domain that there
>> ought to be specific-to-racing prediction approaches.  We have a
>> fairly good idea of what the player is doing (trying to stay on the
>> track), and that would seem to give more data that isn't really being
>> exploited with standard approaches - but googling isn't turning up
>> much.
>>
>> Do such algorithms exist?  Or, in practice, are the same approaches
>> used in FPSes et al still the ones to use here?
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Megan Fox
http://www.shalinor.com/

Re: [Algorithms] Network prediction algorithms specific to racing?

[Jason H. <jh...@st...>]

I guess there are two aspects of this: prediction and visual rectification.

We've been doing a networked basketball game recently, where one team is 
entirely controlled remotely.  Even with fairly high latency, slow 
moving objects (like players) will look okay using a smooth 
rectification algorithm, but they're a little delayed from real-time.  
High velocity objects  (ie. bullets or ballistic objects) are pretty 
easy to sync as well, provided they are not controlled or intelligent.  
The main issues we've had thus far involve rectifying the ball physical 
state after a collision with a player, since that's often incorrect and 
delayed.  Luckily, most collisions in basketball games result in the 
ball being grabbed, so this isn't always an issue.  For reference, our 
simple rectification code is X = Lerp(X, X', f), where f could vary 
depending on the latency and current error.  Spline rectification would 
be nicer, and we might implement that, though it may be overkill for us.

I haven't tried prediction beyond simple linear extrapolation based on 
the last single sample (position, velocity, orientation).  1st order 
prediction would likely close most of the gaps for generally smooth 
functions like position and orientation, but for velocity, I'm not sure 
it would help in our case, since the velocity is basically joystick 
angle for us and is generally discontinuous.

Sorry I can't be more help with racing specifically.  Out of curiosity, 
what have you tried and how did it work?

Thanks,
JH

Jason Hughes
President
Steel Penny Games, Inc.
Austin, TX


On 4/15/2010 3:34 PM, Megan Fox wrote:
> I'm currently fiddling with dead reckoning for a racing game I'm
> working on, but this seems like a specific enough domain that there
> ought to be specific-to-racing prediction approaches.  We have a
> fairly good idea of what the player is doing (trying to stay on the
> track), and that would seem to give more data that isn't really being
> exploited with standard approaches - but googling isn't turning up
> much.
>
> Do such algorithms exist?  Or, in practice, are the same approaches
> used in FPSes et al still the ones to use here?
>
>    

[Algorithms] Network prediction algorithms specific to racing?

[Megan F. <sha...@gm...>]

I'm currently fiddling with dead reckoning for a racing game I'm
working on, but this seems like a specific enough domain that there
ought to be specific-to-racing prediction approaches.  We have a
fairly good idea of what the player is doing (trying to stay on the
track), and that would seem to give more data that isn't really being
exploited with standard approaches - but googling isn't turning up
much.

Do such algorithms exist?  Or, in practice, are the same approaches
used in FPSes et al still the ones to use here?

-- 
Megan Fox
http://www.shalinor.com/

Re: [Algorithms] Cloud Rendering

[yann le p. <lep...@gm...>]

an other interesting paper :

http://evasion.imag.fr/Publications/2008/BNMBC08/   (pdf :
http://evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf )

,yann


On Tue, Apr 13, 2010 at 12:42 PM, Zafar Qamar
<zaf...@co...>wrote:

>  I cannot thank you people enough. I really appreciate the time and energy
> you’ve all spent in collating and sharing all that info.
>
> Hope it helps others too.
>
>
>
> Very much appreciated.
>
> Zafar
>
>
>
>
>
>
>
> *From:* Philip Bai [mailto:phi...@gm...]
> *Sent:* 13 April 2010 05:32
> *To:* Game Development Algorithms
> *Subject:* Re: [Algorithms] Cloud Rendering
>
>
>
> Thanks Jim!
>
> Really really informative.
>
> On Tue, Apr 13, 2010 at 12:54 AM, Jim Drygiannakis <
> jd...@ma...> wrote:
>
>  Hi,
>
> Since you are looking for links and ideas I'll drop my two cents (long time
> following the list, but this is my first post).
>
> 1) Cloud layer
> a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024>: Old thread at gdnet but with some nice ideas.
> b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on
> Modern GPUs : A technique similar to the above thread, but the lighting is
> performed on the GPU (iirc).
>
> 2) 3D clouds
> a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf>: Really nice looking clouds, but I don't remember any of the details.
> b) Realistic and Fast Cloud Rendering <http://niniane.org/clouds/> : Used
> in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty
> lighting
> c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf>: The above technique as it's used in Crysis.
> d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html>: Pretty old but still really good. Source code
> included <http://www.markmark.net/SkyWorks/>.
>
> I'm sure I had more of those but I unfortunately I haven't added them to my
> bookmark list.
>
> 3) Sky color
> a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/>: Preetham's classic paper. The model is simple but it's quite difficult to
> configure in order to get nice colors.
> b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf>: A way to implement the above paper using the GPU.
> c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf>: What the title says :)
> d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf>: Another classic paper by Nishita et al. The model might look a bit complex
> but it gives really nice results.
> e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf>: IIRC this describes a way to implement Nishita's method using the GPU.
> Might worth a read.
> f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html>: Really nice implementation of Nishita's method (iirc) on the GPU. Supports
> multiple scattering and the sun can be moved with no run-time overhead. A
> bit shader heavy though.
>
> Note that you can simplify Nishita's model (and all the derived
> implementations) a lot if you are not interested in planet rendering. I.e.
> for an FPS style game you can safely assume that the observer is always at
> (e.g.) (0, h, 0).
>
> That's it. You've probably already read/seen most of those, but you haven't
> mentioned anything so I tried. Hope the above help you get started.
>
> JD
>
>
>
>
>   On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <
> zaf...@co...> wrote:
>
>   Hi,
>
> I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D
> game.
>
>
>
> These are the main requirements...
>
>
>
> 1)        Have a high-cloud layer that can range from 0 to full coverage
>
> 2)        Have lower clouds (sprites) that fade&roll in and out and move
> around and are “lit by the Sun”, so the light can catch edges, and cause the
> other side to appear in shadow etc.
>
> 3)        Have colours of the sky change, as the sun rises/sets etc
>
>
>
> Can anyone suggest any ideas/tips/tricks or links to help me in my quest?
>
>
>
> Your input would be very much appreciated.
>
>
>
> Cheers
>
> Zaf
>
>
>
>
>
> **********************************************************************************
> Disclaimer
>
>
> The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.
>
>
> Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.
>
>
> Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
>
> Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
>
>
> --
> Bai, Gang.
> Master student.
> State Key Lab. of Virtual Reality.
> Beihang University.
> Beijing, China.
>
>
>
> Click here<https://www.mailcontrol.com/sr/N2LR9Q6ZTG3TndxI%21oX7UiVrncwsDD+5W3P71cjD%21twi%211jr58aCZwSNgu3Fc69w%21O0FAbn57ZqFfmYpsSvVwQ==>to report this email as spam.
>
>
>
>
> **********************************************************************************
> Disclaimer
>
>
> The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.
>
>
> Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.
>
>
> Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
>
> Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Yann Le Paih
Keraudrono
56150 BAUD
FRANCE
Portable: +33(0)610524356
lep...@gm...

Re: [Algorithms] Cloud Rendering

[Zafar Q. <zaf...@co...>]

I cannot thank you people enough. I really appreciate the time and energy you've all spent in collating and sharing all that info.
Hope it helps others too.

Very much appreciated.
Zafar



From: Philip Bai [mailto:phi...@gm...]
Sent: 13 April 2010 05:32
To: Game Development Algorithms
Subject: Re: [Algorithms] Cloud Rendering

Thanks Jim!
Really really informative.
On Tue, Apr 13, 2010 at 12:54 AM, Jim Drygiannakis <jd...@ma...<mailto:jd...@ma...>> wrote:

Hi,

Since you are looking for links and ideas I'll drop my two cents (long time following the list, but this is my first post).

1) Cloud layer
a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024> : Old thread at gdnet but with some nice ideas.
b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on Modern GPUs : A technique similar to the above thread, but the lighting is performed on the GPU (iirc).

2) 3D clouds
a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf> : Really nice looking clouds, but I don't remember any of the details.
b) Realistic and Fast Cloud Rendering<http://niniane.org/clouds/> : Used in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty lighting
c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf> : The above technique as it's used in Crysis.
d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html> : Pretty old but still really good. Source code included<http://www.markmark.net/SkyWorks/>.

I'm sure I had more of those but I unfortunately I haven't added them to my bookmark list.

3) Sky color
a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/> : Preetham's classic paper. The model is simple but it's quite difficult to configure in order to get nice colors.
b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf> : A way to implement the above paper using the GPU.
c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf> : What the title says :)
d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf> : Another classic paper by Nishita et al. The model might look a bit complex but it gives really nice results.
e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf> : IIRC this describes a way to implement Nishita's method using the GPU. Might worth a read.
f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html> : Really nice implementation of Nishita's method (iirc) on the GPU. Supports multiple scattering and the sun can be moved with no run-time overhead. A bit shader heavy though.

Note that you can simplify Nishita's model (and all the derived implementations) a lot if you are not interested in planet rendering. I.e. for an FPS style game you can safely assume that the observer is always at (e.g.) (0, h, 0).

That's it. You've probably already read/seen most of those, but you haven't mentioned anything so I tried. Hope the above help you get started.

JD




On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <zaf...@co...<mailto:zaf...@co...>> wrote:
Hi,
I'm trying to do some fairly realistic-looking cloud-rendering, in a 3D game.

These are the main requirements...


1)        Have a high-cloud layer that can range from 0 to full coverage

2)        Have lower clouds (sprites) that fade&roll in and out and move around and are "lit by the Sun", so the light can catch edges, and cause the other side to appear in shadow etc.

3)        Have colours of the sky change, as the sun rises/sets etc

Can anyone suggest any ideas/tips/tricks or links to help me in my quest?

Your input would be very much appreciated.

Cheers
Zaf


**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters' prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters' standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters' board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************


------------------------------------------------------------------------------
Download Intel&#174; 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
GDA...@li...<mailto:GDA...@li...>
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list


------------------------------------------------------------------------------
Download Intel&#174; 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
GDA...@li...<mailto:GDA...@li...>
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list



--
Bai, Gang.
Master student.
State Key Lab. of Virtual Reality.
Beihang University.
Beijing, China.


Click here<https://www.mailcontrol.com/sr/N2LR9Q6ZTG3TndxI!oX7UiVrncwsDD+5W3P71cjD!twi!1jr58aCZwSNgu3Fc69w!O0FAbn57ZqFfmYpsSvVwQ==> to report this email as spam.
**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. 

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************

Re: [Algorithms] Cloud Rendering

[Philip B. <phi...@gm...>]

Thanks Jim!
Really really informative.

On Tue, Apr 13, 2010 at 12:54 AM, Jim Drygiannakis <
jd...@ma...> wrote:

> Hi,
>
> Since you are looking for links and ideas I'll drop my two cents (long time
> following the list, but this is my first post).
>
> 1) Cloud layer
> a) Sky-rendering techniques - GameDev.net forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024>: Old thread at gdnet but with some nice ideas.
> b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on
> Modern GPUs : A technique similar to the above thread, but the lighting is
> performed on the GPU (iirc).
>
> 2) 3D clouds
> a) Interactive multiple anisotropic scattering in clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf>: Really nice looking clouds, but I don't remember any of the details.
> b) Realistic and Fast Cloud Rendering <http://niniane.org/clouds/> : Used
> in Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty
> lighting
> c) Real-time Atmospheric Effects in Games Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf>: The above technique as it's used in Crysis.
> d) Mark Harris' cloud rendering technique<http://www.markmark.net/clouds/index.html>: Pretty old but still really good. Source code
> included <http://www.markmark.net/SkyWorks/>.
>
> I'm sure I had more of those but I unfortunately I haven't added them to my
> bookmark list.
>
> 3) Sky color
> a) A Practical Analytic Model for Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/>: Preetham's classic paper. The model is simple but it's quite difficult to
> configure in order to get nice colors.
> b) Rendering Outdoor Light Scattering in Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf>: A way to implement the above paper using the GPU.
> c) A Critical Review of the Preetham Skylight Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf>: What the title says :)
> d) Display of the Earth Taking into Account Atmospheric Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf>: Another classic paper by Nishita et al. The model might look a bit complex
> but it gives really nice results.
> e) Real-time Rendering of Planets with Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf>: IIRC this describes a way to implement Nishita's method using the GPU.
> Might worth a read.
> f) Precomputed Atmospheric Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html>: Really nice implementation of Nishita's method (iirc) on the GPU. Supports
> multiple scattering and the sun can be moved with no run-time overhead. A
> bit shader heavy though.
>
> Note that you can simplify Nishita's model (and all the derived
> implementations) a lot if you are not interested in planet rendering. I.e.
> for an FPS style game you can safely assume that the observer is always at
> (e.g.) (0, h, 0).
>
> That's it. You've probably already read/seen most of those, but you haven't
> mentioned anything so I tried. Hope the above help you get started.
>
> JD
>
>
>
>
>
> On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <zaf...@co...>wrote:
>
>>  Hi,
>>
>> I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D
>> game.
>>
>>
>>
>> These are the main requirements...
>>
>>
>>
>> 1)        Have a high-cloud layer that can range from 0 to full coverage
>>
>> 2)        Have lower clouds (sprites) that fade&roll in and out and move
>> around and are “lit by the Sun”, so the light can catch edges, and cause the
>> other side to appear in shadow etc.
>>
>> 3)        Have colours of the sky change, as the sun rises/sets etc
>>
>>
>>
>> Can anyone suggest any ideas/tips/tricks or links to help me in my quest?
>>
>>
>>
>> Your input would be very much appreciated.
>>
>>
>>
>> Cheers
>>
>> Zaf
>>
>>
>>
>>
>> **********************************************************************************
>> Disclaimer
>>
>>
>> The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.
>>
>>
>> Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.
>>
>>
>> Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
>>
>> Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.
>>
>> This footnote also confirms that this email message has been swept by
>> SurfControl for the presence of computer viruses.
>>
>> **********************************************************************************
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Bai, Gang.
Master student.
State Key Lab. of Virtual Reality.
Beihang University.
Beijing, China.

Re: [Algorithms] Cloud Rendering

[Tony A. <ton...@gm...>]

I'd suggest you have a look at the paper "A Simple, Efficient Method for
Realistic Animation of
Clouds<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.4850>"
(pdf <http://nis-lab.is.s.u-tokyo.ac.jp/~nis/cdrom/sig00_cloud.pdf> and a
video <http://video.google.com/videoplay?docid=3133893853954925559#> - the
video is quite nice). It talks about modelling clouds with a cellular
automata as well as how they render them.

Additionally, vterrain has an extensive list of links on clouds -
http://www.vterrain.org/Atmosphere/Clouds/

-Tony
<http://www.vterrain.org/Atmosphere/Clouds/>

Re: [Algorithms] Cloud Rendering

[Jim D. <jd...@ma...>]

Hi,

Since you are looking for links and ideas I'll drop my two cents (long time
following the list, but this is my first post).

1) Cloud layer
a) Sky-rendering techniques - GameDev.net
forums<http://www.gamedev.net/community/forums/topic.asp?topic_id=86024>:
Old thread at gdnet but with some nice ideas.
b) Game Programming Gems v5, chapter 5.1, Realistic Cloud Rendering on
Modern GPUs : A technique similar to the above thread, but the lighting is
performed on the GPU (iirc).

2) 3D clouds
a) Interactive multiple anisotropic scattering in
clouds<http://www-evasion.imag.fr/Publications/2008/BNMBC08/clouds.pdf>:
Really nice looking clouds, but I don't remember any of the details.
b) Realistic and Fast Cloud Rendering <http://niniane.org/clouds/> : Used in
Flight Simulator 2004. Nice shapes (artist driven), cheap-and-dirty lighting
c) Real-time Atmospheric Effects in Games
Revisited<http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf>:
The above technique as it's used in Crysis.
d) Mark Harris' cloud rendering
technique<http://www.markmark.net/clouds/index.html>: Pretty old but
still really good. Source code
included <http://www.markmark.net/SkyWorks/>.

I'm sure I had more of those but I unfortunately I haven't added them to my
bookmark list.

3) Sky color
a) A Practical Analytic Model for
Daylight<http://www.cs.utah.edu/%7Eshirley/papers/sunsky/>: Preetham's
classic paper. The model is simple but it's quite difficult to
configure in order to get nice colors.
b) Rendering Outdoor Light Scattering in
Real-time<http://ati.amd.com/developer/dx9/ATI-LightScattering.pdf>: A
way to implement the above paper using the GPU.
c) A Critical Review of the Preetham Skylight
Model<http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf>:
What the title says :)
d) Display of the Earth Taking into Account Atmospheric
Scattering<http://nis-lab.is.s.u-tokyo.ac.jp/%7Enis/cdrom/sig93_nis.pdf>:
Another classic paper by Nishita et al. The model might look a bit
complex
but it gives really nice results.
e) Real-time Rendering of Planets with
Atmosphere<http://www.vis.uni-stuttgart.de/%7Eschafhts/HomePage/pubs/wscg07-schafhitzel.pdf>:
IIRC this describes a way to implement Nishita's method using the GPU.
Might worth a read.
f) Precomputed Atmospheric
Scattering<http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@11e7cdda2f7_f64b69/index_en.html>:
Really nice implementation of Nishita's method (iirc) on the GPU.
Supports
multiple scattering and the sun can be moved with no run-time overhead. A
bit shader heavy though.

Note that you can simplify Nishita's model (and all the derived
implementations) a lot if you are not interested in planet rendering. I.e.
for an FPS style game you can safely assume that the observer is always at
(e.g.) (0, h, 0).

That's it. You've probably already read/seen most of those, but you haven't
mentioned anything so I tried. Hope the above help you get started.

JD





On Mon, Apr 12, 2010 at 6:11 PM, Zafar Qamar <zaf...@co...>wrote:

>  Hi,
>
> I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D
> game.
>
>
>
> These are the main requirements...
>
>
>
> 1)        Have a high-cloud layer that can range from 0 to full coverage
>
> 2)        Have lower clouds (sprites) that fade&roll in and out and move
> around and are “lit by the Sun”, so the light can catch edges, and cause the
> other side to appear in shadow etc.
>
> 3)        Have colours of the sky change, as the sun rises/sets etc
>
>
>
> Can anyone suggest any ideas/tips/tricks or links to help me in my quest?
>
>
>
> Your input would be very much appreciated.
>
>
>
> Cheers
>
> Zaf
>
>
>
>
> **********************************************************************************
> Disclaimer
>
>
> The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.
>
>
> Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.
>
>
> Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
>
> Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.
>
> This footnote also confirms that this email message has been swept by
> SurfControl for the presence of computer viruses.
>
> **********************************************************************************
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] Cloud Rendering

[Jon W. <jw...@gm...>]

A few years ago, when programmable shaders and multi-texturing-passes were
novel, there was a lot written up on this. I remember a very in-depth
article by Naty Hoffman on light scattering and how it affects color in
haze, sunsets, etc. There are also cloud/sky/daylight models that you can
buy and plug into your game or simulation, if you want very realistic
effects.

If you just want to fake it, then some combination of
distance/elevation-based fog with a perturbation function, stand-in geometry
that uses normal maps to simulate cloud roundness, and spherical lighting
functions (clamp(1+NdotL) instead of clamp(NdotL), for example) is a
quick-and-easy start.

Elevation-based fog is typically implemented as two fog exponents, one for
"above" and one for "below" the separating plane, and you calculate how far
it travels within in each of the halves, and apply fog appropriately.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Mon, Apr 12, 2010 at 8:11 AM, Zafar Qamar <zaf...@co...>wrote:

>  Hi,
>
> I’m trying to do some fairly realistic-looking cloud-rendering, in a 3D
> game.
>
>
>
> These are the main requirements...
>
>
>
> 1)        Have a high-cloud layer that can range from 0 to full coverage
>
> 2)        Have lower clouds (sprites) that fade&roll in and out and move
> around and are “lit by the Sun”, so the light can catch edges, and cause the
> other side to appear in shadow etc.
>
> 3)        Have colours of the sky change, as the sun rises/sets etc
>
>
>
> Can anyone suggest any ideas/tips/tricks or links to help me in my quest?
>
>
>
> Your input would be very much appreciated.
>
>
>
> Cheers
>
> Zaf
>

[Algorithms] Cloud Rendering

[Zafar Q. <zaf...@co...>]

Hi,
I'm trying to do some fairly realistic-looking cloud-rendering, in a 3D game.

These are the main requirements...


1)        Have a high-cloud layer that can range from 0 to full coverage

2)        Have lower clouds (sprites) that fade&roll in and out and move around and are "lit by the Sun", so the light can catch edges, and cause the other side to appear in shadow etc.

3)        Have colours of the sky change, as the sun rises/sets etc

Can anyone suggest any ideas/tips/tricks or links to help me in my quest?

Your input would be very much appreciated.

Cheers
Zaf
**********************************************************************************
Disclaimer

The information and attached documentation in this e-mail is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. 

Attachments to this e-mail may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened.

Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.

This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************

Re: [Algorithms] Low pass filter on quaternions

[Tom F. <tom...@ee...>]

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:ry...@gm...]
> 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
> GDA...@li...
> 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

Re: [Algorithms] Low pass filter on quaternions

[Jon W. <jw...@gm...>]

"90% of this, 10% of that" is exactly a first-order IIR filter implemented
as a leaky integrator.

However, it's not true that "quick changes" have to be killed by an IIR. If
you view this as traditional signal analysis with four channels, and you go
higher-order (or multiple second-order, which is generally more stable) you
can do things like combining a highpass filter (I suppose to to weed out
"wave") with a wide notch filter (to weed out noise, but still allow really
strong transients such as presumably "wrist snap" movements).

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Mon, Mar 29, 2010 at 8:31 AM, Tom Plunket <ga...@fa...> 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.
>
> 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?
>
> Regardless of the solution for the filtered quaternions, I would think
> that lag would be preferable to overshoot.  The IIR filters certainly meet
> that criteria.  :)
>
>
> -tom!
>
> --
>
>

Re: [Algorithms] Low pass filter on quaternions

[Fabian G. <ry...@gm...>]

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

Re: [Algorithms] Low pass filter on quaternions

[Tom P. <ga...@fa...>]

> 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.

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?

Regardless of the solution for the filtered quaternions, I would think
that lag would be preferable to overshoot.  The IIR filters certainly meet
that criteria.  :)


-tom!

-- 

Re: [Algorithms] Low pass filter on quaternions

[Tom P. <ga...@fa...>]

> The torque can now be defined as log(Qrel) * Cspring, where Cspring is
> the spring constant. You will need to damp out oscillations, by
> multiplying the relative angular velocity (also a 3-vector) by a damping
> constant and subtracting it from the torque.

I love springs as much as anybody, but I've never satisfactorily solved
the "spike" problem, which is to say if the target value is sufficiently
far away from the at-rest current value, the damping doesn't kick in until
you've already blasted off into space.  I don't remember my calculus well
enough to solve this myself, but Game Gems 4 (I think?) has an article on
iterative critically damped springs.  Unfortunately, critically damped
springs also tend to converge very slowly.

-tom!

-- 

Re: [Algorithms] Low pass filter on quaternions

[Gino v. d. B. <gin...@gm...>]

Note that with any kind of filtering you will introduce some 
sluggishness since abrupt changes will be muffled. An intuitive way to 
get this done is through a dynamics simulation.

Define inertia for the controlled object and control its orientation 
through a damped spring. Let Q0 be the current orientation of the object 
and Q1 the desired orientation (the orientation of the input device). 
First make sure that Q0 and Q1 are in the same hemisphere (of a 4D unit 
sphere). Thus if the 4-component dot product of Q0 and Q1 is negative 
simply set Q1 to -Q1. Next take the relative rotation, which is Qrel = 
Q0 Q1*, where Q1* is the conjugate of Q1. We will use log(Qrel) the log 
of Qrel for computing the torque. The log of a quaternion [xyz,w]  is 
the 3-vector xyz * acos(w) / sqrt(1 - w * w) , (log([0, 0, 0: 1]) = (0, 
0, 0)). Instead of the log you could also use the vector part (xyz) as a 
cheap and dirty log, since acos(w) / sqrt(1 - w * w) approaches 1 for w 
around 1.

The torque can now be defined as log(Qrel) * Cspring, where Cspring is 
the spring constant. You will need to damp out oscillations, by 
multiplying the relative angular velocity (also a 3-vector) by a damping 
constant and subtracting it from the torque. If the input device does 
not provide an angular velocity, you can take a linear approximation of 
the angular velocity or simply assume a zero angular velocity. By 
setting the angular damping to 2 sqrt(inertia Cspring), you will get a 
critically damped spring (just enough damping to remove all 
oscillations). In an isolated setting you can use inertia = 1 (identity) 
and tweak the response of the spring damper by changing the spring 
constant (keeping the damping critical).

Just a thought...

Gino











On 3/28/2010 5:32 PM, John McCutchan wrote:
> Hi,
>
> Each quaternion represents the orientation of an input device. I want
> to remove jitter that comes from holding it in a human hand.
>
> John
>
> On Sun, Mar 28, 2010 at 12:56 AM, Marc B. Reynolds
> <mar...@or...>  wrote:
>    
>> Also, what do they represent?
>>
>> -----Original Message-----
>> From: Robin Green [mailto:rob...@gm...]
>> Sent: Sunday, March 28, 2010 8:36 AM
>> To: Game Development Algorithms
>> Subject: Re: [Algorithms] Low pass filter on quaternions
>>
>>
>> Do you want to lowpass the signal, or do you want to fit a smooth
>> curve to the samples?
>> Are the samples regularly spaced?
>>
>> - Robin Green
>>
>>
>>
>> On Sat, Mar 27, 2010 at 7:14 PM, John McCutchan<jo...@jo...>
>> wrote:
>>      
>>> Hi,
>>>
>>> I have a sequence of quaternions and want to filter out any high
>>> frequency changes. I'm wondering if anyone has a paper or some code
>>> for performing a low pass filter on quaternions?
>>>
>>> Thanks,
>>> --
>>> John McCutchan<jo...@jo...>
>>>
>>>
>>>        
>> ----------------------------------------------------------------------------
>> --
>>      
>>> Download Intel&#174; 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
>>> GDA...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>>> Archives:
>>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>>
>>>        
>> ----------------------------------------------------------------------------
>> --
>> Download Intel&#174; 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
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>
>>      
>
>
>    

Re: [Algorithms] volumetric spotlight

[Jeff R. <je...@8m...>]

OP here, thought I'd share my results. Thanks to Miles in particular for
being helpful.

http://i44.tinypic.com/2h4algx.jpg

Determined the distance through the fog cone by tracing the eye vector to
the far side of the cone, then clipping that distance against the depth
buffer. With the entry and exit points inside the volume, it turned out to
be fairly easy to evaluate the falloff integral implicitly. All told
compiles into about 50 shader instructions, one texture lookup, and no
overdraw. I might be able to squeeze the shader down a little more, but that
will come later.

Thanks guys,

Jeff

On Sun, Mar 28, 2010 at 9:18 AM, Bert Peers <be...@bp...> wrote:

> Darren Grant schreef:
>
> > The most complex approach is to write a ray-casting shader that
> > integrates over distance travelled by each eye ray through the umbra
> > volume. It is hard to get the results to overlap and intersect correctly
> > with the rest of the scene unless you have some sort of unified
> > rendering architecture built around ray-casting. Very pretty if you get
> > it working, but very difficult to deploy without limitations coming back
> > to get you later.
>
> I'd give that a try too.  There's some good shadowmap based stuff in
> ShaderX7 as well for easier integration with scene geometry (p. 331).
>
>
> Also check out I3D10's update to Crytek's Light propagation volumes.
>
>
> hth,
> bert
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Low pass filter on quaternions

[Jason H. <jh...@st...>]

The typical way to handle Wiimote pointer jitter (2D) is to attach a 
simple bimodal spring to the XY position on screen.  The clamped mode is 
enacted anytime the centroid of the last few samples is within some 
squared tolerance of the samples; return the centroid as long as that's 
true.  When the most recent sample deviates, spring toward the current 
sample value by lerping toward it at about 30% per frame for a few 
frames, after which you just return the current sample.  This gives a 
smooth transition between the modes.

For motion control, we tended to handle the smoothing within each object 
control rather than at the hardware driver level, since there were some 
control schemes that look for spikes and thresholds, and any kind of 
filters we applied would ultimately mask those sorts of details.

I do recall that we tried various methods for smoothing.  One of them 
maintained two axes in space for the up and forward.  They were allowed 
to drift away from orthonormal while smoothing points in space, since we 
did non-linear smoothing.  When returning the orientation of the remote 
to the game, we would re-orthogonalize the orientation by holding the 
"important axis" fixed--that is, the one that the user is primarily 
interested in controlling cleanly during the current activity--without 
modifying the internal axes we were tracking.

Seemed to work ok, but again, the technique should probably match the 
control in each section of the game.

JH

Jason Hughes
President
Steel Penny Games, Inc.
Austin, TX


On 3/28/2010 12:58 PM, Jon Watte 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.
>
> The motion capture tools people have had this problem for a long time. 
> I believe they convert to Euler, and run low-pass filtering there 
> (possibly higher than just first order), and then convert back, 
> because Euler is less sensitive around any particular spot.
>
> I'd also be interested in hearing from anyone who has done this in anger!
>
> Sincerely,
>
> jw
>
>
> --
> Americans might object: there is no way we would sacrifice our living 
> standards for the benefit of people in the rest of the world. 
> Nevertheless, whether we get there willingly or not, we shall soon 
> have lower consumption rates, because our present rates are 
> unsustainable.
>
>
>
> On Sun, Mar 28, 2010 at 10:22 AM, Juan Linietsky <re...@gm... 
> <mailto:re...@gm...>> wrote:
>
>     I don't have any code handy, but since for a lowpass filter you
>     need the "difference",  I guess you can obtain that with the
>     inverse or something similar.. Also keep in mind it may be easier
>     to just lowpass a 3x3 matrix since you want to rule out high freq
>     noise
>     ------Original Message------
>     From: John McCutchan
>     To: Game Development Algorithms
>     ReplyTo: Game Development Algorithms
>     Subject: [Algorithms] Low pass filter on quaternions
>     Sent: Mar 27, 2010 23:14
>
>     Hi,
>
>     I have a sequence of quaternions and want to filter out any high
>     frequency changes. I'm wondering if anyone has a paper or some code
>     for performing a low pass filter on quaternions?
>
>     Thanks,
>     --
>     John McCutchan <jo...@jo...
>     <mailto:jo...@jo...>>
>
>     ------------------------------------------------------------------------------
>     Download Intel&#174; 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
>     GDA...@li...
>     <mailto:GDA...@li...>
>     https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>     Archives:
>     http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>     ------------------------------------------------------------------------------
>     Download Intel&#174; 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
>     GDA...@li...
>     <mailto:GDA...@li...>
>     https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>     Archives:
>     http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Low pass filter on quaternions

[John M. <jo...@jo...>]

Hi,

Wiimote libraries won't help me. I'm really interested in filtering
quaternions directly.

Thanks,
John

On Sun, Mar 28, 2010 at 9:05 AM, Jon Watte <jw...@gm...> wrote:
> There are open source Wiimote input libraries you could probably take a look
> at. AFAICT, those generally use very simple, first-order filter type
> approaches.
> Sincerely,
> jw
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
>
>
>
> On Sun, Mar 28, 2010 at 8:32 AM, John McCutchan <jo...@jo...>
> wrote:
>>
>> Hi,
>>
>> Each quaternion represents the orientation of an input device. I want
>> to remove jitter that comes from holding it in a human hand.
>>
>> John
>>
>> On Sun, Mar 28, 2010 at 12:56 AM, Marc B. Reynolds
>> <mar...@or...> wrote:
>> > Also, what do they represent?
>> >
>> > -----Original Message-----
>> > From: Robin Green [mailto:rob...@gm...]
>> > Sent: Sunday, March 28, 2010 8:36 AM
>> > To: Game Development Algorithms
>> > Subject: Re: [Algorithms] Low pass filter on quaternions
>> >
>> >
>> > Do you want to lowpass the signal, or do you want to fit a smooth
>> > curve to the samples?
>> > Are the samples regularly spaced?
>> >
>> > - Robin Green
>> >
>> >
>> >
>> > On Sat, Mar 27, 2010 at 7:14 PM, John McCutchan <jo...@jo...>
>> > wrote:
>> >> Hi,
>> >>
>> >> I have a sequence of quaternions and want to filter out any high
>> >> frequency changes. I'm wondering if anyone has a paper or some code
>> >> for performing a low pass filter on quaternions?
>> >>
>> >> Thanks,
>> >> --
>> >> John McCutchan <jo...@jo...>
>> >>
>> >>
>> >
>> > ----------------------------------------------------------------------------
>> > --
>> >> Download Intel&#174; 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
>> >> GDA...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> >> Archives:
>> >>
>> >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>> >>
>> >
>> >
>> > ----------------------------------------------------------------------------
>> > --
>> > Download Intel&#174; 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
>> > GDA...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> > Archives:
>> >
>> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download Intel&#174; 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
>> > GDA...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> > Archives:
>> >
>> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>> >
>>
>>
>>
>> --
>> John McCutchan <jo...@jo...>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
John McCutchan <jo...@jo...>

Re: [Algorithms] Low pass filter on quaternions

[Jon W. <jw...@gm...>]

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.

The motion capture tools people have had this problem for a long time. I
believe they convert to Euler, and run low-pass filtering there (possibly
higher than just first order), and then convert back, because Euler is less
sensitive around any particular spot.

I'd also be interested in hearing from anyone who has done this in anger!

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Sun, Mar 28, 2010 at 10:22 AM, Juan Linietsky <re...@gm...> wrote:

> I don't have any code handy, but since for a lowpass filter you need the
> "difference",  I guess you can obtain that with the inverse or something
> similar.. Also keep in mind it may be easier to just lowpass a 3x3 matrix
> since you want to rule out high freq noise
> ------Original Message------
> From: John McCutchan
> To: Game Development Algorithms
> ReplyTo: Game Development Algorithms
> Subject: [Algorithms] Low pass filter on quaternions
> Sent: Mar 27, 2010 23:14
>
> Hi,
>
> I have a sequence of quaternions and want to filter out any high
> frequency changes. I'm wondering if anyone has a paper or some code
> for performing a low pass filter on quaternions?
>
> Thanks,
> --
> John McCutchan <jo...@jo...>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] Low pass filter on quaternions

[Juan L. <re...@gm...>]

I don't have any code handy, but since for a lowpass filter you need the "difference",  I guess you can obtain that with the inverse or something similar.. Also keep in mind it may be easier to just lowpass a 3x3 matrix since you want to rule out high freq noise
------Original Message------
From: John McCutchan
To: Game Development Algorithms
ReplyTo: Game Development Algorithms
Subject: [Algorithms] Low pass filter on quaternions
Sent: Mar 27, 2010 23:14

Hi,

I have a sequence of quaternions and want to filter out any high
frequency changes. I'm wondering if anyone has a paper or some code
for performing a low pass filter on quaternions?

Thanks,
-- 
John McCutchan <jo...@jo...>

------------------------------------------------------------------------------
Download Intel&#174; 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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list