Thread: Re: [Algorithms] Formula for Damping f times (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Alen L. <ale...@cr...> - 2009-06-05 11:49:14
|
Paul wrote at 6/5/2009: > x *= 1.0f-(k*deltaTime); Note this: x1 = x0*(1-k*d) x2 = x1*(1-k*d) = x0*(1-k*d)*(1-k*d) = x0*(1 - k*2*d + k^2*d^2) If you skip and do two steps at a time: x2 = x0*(1-k*2*d) So, this formula does not behave well with step variance. OP didn't state he requires this explicitly, but it is important to note as it can cause weird results later if you don't pay attention to that. I'd prefer using pow(), as Fabian described, unless performance is extremely critical there. JM2C, Alen |
|
From: <Pau...@sc...> - 2009-06-05 13:10:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > So, this formula does not behave well with step variance. OP didn't > state he requires this explicitly, but it is important to note as it > can cause weird results later if you don't pay attention to that. > I'd prefer using pow(), as Fabian described, unless performance is > extremely critical there. Ahhh, we have a fixed timestep - i should have mentioned that up front, thanks for pointing that out alen.... Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSikS+3ajGqjtoMHxAQhlaQf/TxisNYwY0Z+2d0z3+0g/yKzVfKXUhe/J hUI1sSrVl5USAQ0Tn8I+9eXJPNsOPSMLZsFd1TuFUdR06A+QX81wh7Xp4IVRl5yT pxam+UZBD6eJyPQKQrnMI3lMUxefOKD3ZqJs0YX/6GkKgsE4rxEi1Egc14kBj85V Wb+lIl5pIYA6OEB7gFgNljAqtTgfJfldDymscQ++yJ1pFRZboj0lNLpscx6guhnn z60xpbndIxkW0wv/v2q3foXfUaE4tZ36w9CbEmNGSJlK3UK0VAV+sjogtNf3c51D z03lV8GPB4FlqK9PBcfNF1K2ZVB3upXaYKc7nr9OG7mwOJUwn4PBcA== =wc34 -----END PGP SIGNATURE----- |
|
From: Ola O. <ola...@gm...> - 2009-06-05 12:48:59
|
> x *= 1.0f-(k*deltaTime);
>
> So k = 1 = damped to zero velocity over 1 second at 30fps.
Hm, zero after one second? Really? If we have 30 fps and deltaTime thus is
1/30 (and k = 1 as stated), then the rhs = 29/30, expanding that would mean
that x30 = x0 * (29/30)^30 which is approximately x30 = x0 * 0.36
I did get up at 5am this morning so I apologize if I missed/messed something
here, but that appears a fair way from zero.
cheers
.ola
----- Original Message -----
From: <Pau...@sc...>
To: "Game Development Algorithms" <gda...@li...>
Sent: Friday, June 05, 2009 12:31 PM
Subject: Re: [Algorithms] Formula for Damping f times
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>> Hi,
>> This is a semi-trivial but I can't quite remember the answer, even
>> though I've done it before.
>>
>> I have an update function sort of like this..
>>
>> void updateX( float deltaTime)
>> {
>> x = x*k;
>> }
>>
>> k is a constant less than 1.0.
>>
>> Now to do the damping properly I need to perform "x=x*k" deltaTime
>> times, where deltaTime is a fraction.
>>
>> Can anyone help with this please? I recall it just being a log or
>> something.
>
> We just do something very simple:
>
> x *= 1.0f-(k*deltaTime);
>
> So k = 1 = damped to zero velocity over 1 second at 30fps.
>
> Cheers, Paul.
> **********************************************************************
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify pos...@sc...
> This footnote also confirms that this email message has been checked for
> all known viruses.
> Sony Computer Entertainment Europe Limited
> Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
> Kingdom
> Registered in England: 3277793
> **********************************************************************
> P Please consider the environment before printing this e-mail
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 2.9.1 (Build 287)
> Charset: US-ASCII
>
> wsBVAwUBSijz83ajGqjtoMHxAQh+mwgAgByk+DsOHJIg2O411+jQwAialPE3VZ7x
> QMb1t6mG2Ujx8niel3gT9u1PoGEMNiV1rjAvV2O9mCeGgEI4NE9ZDcgB3JF9DJbB
> eq/lNz/EJDaL+deC8wYyyW5TGJoTKW5fz2WvpYmia0RniH1wuLDmjQJR0d2aGbIM
> knI7FpZVEDjMtRvK5nwGJNWkoaiBInSTLJ3+rYrZbtVxeC0AVPgp4lrPL9zGQmpE
> M8CKMs67cwn7xZJnJOTqfdAbnavapIxSvDtAZBDNB7Ba/kX552mv0E+0nMgj4bzC
> 9ft1PoF+05psOXKvCGJXDX3uVpJSJM9OL3SVfC57i114dnDsgfiNTA==
> =tza9
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> 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
|
|
From: <Pau...@sc...> - 2009-06-05 14:53:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I did get up at 5am this morning so I apologize if I missed/messed something > here, but that appears a fair way from zero. Yep, looks like i'm having a bad day today :D I think i need to go back to bed... Thats fridays for you.... :) ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSikXHXajGqjtoMHxAQh1ZwgAsTDMOmp5R/IdHqDBxpt+oRuULS2BGHsO R6BNERdVLXKwhAbFkmD/U4Z//zls1O6mEDVHkHDWw0qK2BUYRYBfkzQJYpLWWXK5 AVnID6Txw3i1FlNedXyO3H/mhNPJCQRhn4VJ+llHKDeVJh7F4grbeIcKXpFOyzxl wJsn4o3I+2beA0I/jPawe2rI+lcPo6ayFFPBnQcm+qWm0rfgJQ3xwH/3Wu5QQURG uN7pMacUBB0tVJX/kaMAkW7sUtdNaVEqHV9dTlvHcm7o7biyPTyroTTDh/iZwfUM SDKPwIi+dmQjRQxjErAiEuRR3L540OflZmtCaWXH9UaQmAlqWHVeKg== =p6By -----END PGP SIGNATURE----- |
|
From: Jeff R. <je...@8m...> - 2009-06-05 15:06:38
|
x *= e ^ k * dt (where k < 0) is my good old standby. Works well with variable time steps. The call to exp() can be expensive, but if you have a lot of things decaying at the same rate you can compute exp( k * dt ) once for the frame and keep reusing it. cheers, jeff On Fri, Jun 5, 2009 at 8:01 AM, <Pau...@sc...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > I did get up at 5am this morning so I apologize if I missed/messed > something > > here, but that appears a fair way from zero. > > Yep, looks like i'm having a bad day today :D I think i need to go back to > bed... Thats fridays for you.... :) > ********************************************************************** > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify pos...@sc... > This footnote also confirms that this email message has been checked for > all known viruses. > Sony Computer Entertainment Europe Limited > Registered Office: 10 Great Marlborough Street, London W1F 7LP, United > Kingdom > Registered in England: 3277793 > ********************************************************************** > P Please consider the environment before printing this e-mail > > -----BEGIN PGP SIGNATURE----- > Version: PGP Universal 2.9.1 (Build 287) > Charset: US-ASCII > > wsBVAwUBSikXHXajGqjtoMHxAQh1ZwgAsTDMOmp5R/IdHqDBxpt+oRuULS2BGHsO > R6BNERdVLXKwhAbFkmD/U4Z//zls1O6mEDVHkHDWw0qK2BUYRYBfkzQJYpLWWXK5 > AVnID6Txw3i1FlNedXyO3H/mhNPJCQRhn4VJ+llHKDeVJh7F4grbeIcKXpFOyzxl > wJsn4o3I+2beA0I/jPawe2rI+lcPo6ayFFPBnQcm+qWm0rfgJQ3xwH/3Wu5QQURG > uN7pMacUBB0tVJX/kaMAkW7sUtdNaVEqHV9dTlvHcm7o7biyPTyroTTDh/iZwfUM > SDKPwIi+dmQjRQxjErAiEuRR3L540OflZmtCaWXH9UaQmAlqWHVeKg== > =p6By > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > 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 -------------------------------------------- |
|
From: Robin G. <rob...@gm...> - 2009-06-05 19:22:31
|
exp() is one of the simplest and most direct math function to implement. It should be approximately the cost of, say, five or sequential six multiply-adds (and that includes range reduction and reconstruction). Do not fear exp(). pow(), however, is a different story. - Robin Green. On Fri, Jun 5, 2009 at 8:06 AM, Jeff Russell<je...@8m...> wrote: > x *= e ^ k * dt (where k < 0) is my good old standby. Works well with > variable time steps. The call to exp() can be expensive, but if you have a > lot of things decaying at the same rate you can compute exp( k * dt ) once > for the frame and keep reusing it. > cheers, > jeff |
|
From: Fabian G. <f.g...@49...> - 2009-06-06 09:33:09
|
> exp() is one of the simplest and most direct math function to > implement. It should be approximately the cost of, say, five or > sequential six multiply-adds (and that includes range reduction and > reconstruction). Do not fear exp(). > > pow(), however, is a different story. But since the log is only done on k (which is, presumably, a constant), you can just store log(k) directly and do exp(log(k)*t) (with some small loss in accuracy that's unlikely to be a problem). Also, if you have them, base-2 log and exp are usually slightly faster and have less potential for extra rounding errors on IEEE FP machines. -Fabian Giesen |
|
From: Robin G. <rob...@gm...> - 2009-06-09 00:10:29
|
On Sat, Jun 6, 2009 at 2:32 AM, Fabian Giesen<f.g...@49...> wrote:
>
> But since the log is only done on k (which is, presumably, a constant),
> you can just store log(k) directly and do exp(log(k)*t) (with some small
> loss in accuracy that's unlikely to be a problem).
Yes, in theory, but these tables have to be run using a higher number
of bits than normal as they have a large effect in the reconstructed
value. Check out the use of static tables with a second "continuation"
table in "powf.c" from the Cephes single precision library
"single.tgz". Compare it to the simplicity of "exp2f.c".
http://www.netlib.org/cephes/
- Robin Green.
|
|
From: Richard F. <ra...@gm...> - 2009-06-09 07:41:40
|
the only robust solution i have found to this situation has been to
create a sub second k and apply it multiple times.
float subTimeStep = 0.05f; // 20fps
subK = exp(log(k)*subTimeStep);
mUpdateTimer += deltaTime;
while( mUpdateTimer > 0 )
{
mUpdateTimer -= subTimeStep;
x = x*subK;
}
anything else either is slower, or has accuracy issues that make
network code impossible to debug.
2009/6/5 Zafar Qamar <zaf...@co...>:
> Hi,
> This is a semi-trivial but I can't quite remember the answer, even
> though I've done it before.
>
> I have an update function sort of like this..
>
> void updateX( float deltaTime)
> {
> x = x*k;
> }
>
> k is a constant less than 1.0.
>
> Now to do the damping properly I need to perform "x=x*k" deltaTime
> times, where deltaTime is a fraction.
>
> Can anyone help with this please? I recall it just being a log or
> something.
>
> Cheers
> Zafar Qamar
> **********************************************************************************
> 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.
> **********************************************************************************
>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> 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
--
fabs();
Just because the world is full of people that think just like you,
doesn't mean the other ones can't be right.
|
|
From: Alen L. <ale...@cr...> - 2009-06-09 08:32:30
|
I guess you use this only if you run with fixed timestep of 20fps?
Aeln
Richard wrote at 6/9/2009:
> the only robust solution i have found to this situation has been to
> create a sub second k and apply it multiple times.
> float subTimeStep = 0.05f; // 20fps
> subK = exp(log(k)*subTimeStep);
> mUpdateTimer += deltaTime;
> while( mUpdateTimer > 0 )
> {
> mUpdateTimer -= subTimeStep;
> x = x*subK;
> }
> anything else either is slower, or has accuracy issues that make
> network code impossible to debug.
> 2009/6/5 Zafar Qamar <zaf...@co...>:
>> Hi,
>> This is a semi-trivial but I can't quite remember the answer, even
>> though I've done it before.
>>
>> I have an update function sort of like this..
>>
>> void updateX( float deltaTime)
>> {
>> x = x*k;
>> }
>>
>> k is a constant less than 1.0.
>>
>> Now to do the damping properly I need to perform "x=x*k" deltaTime
>> times, where deltaTime is a fraction.
>>
>> Can anyone help with this please? I recall it just being a log or
>> something.
>>
>> Cheers
>> Zafar Qamar
>> **********************************************************************************
>> 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.
>> **********************************************************************************
>>
>>
>> ------------------------------------------------------------------------------
>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>> looking to deploy the next generation of Solaris that includes the latest
>> innovations from Sun and the OpenSource community. Download a copy and
>> enjoy capabilities such as Networking, Storage and Virtualization.
>> Go to: http://p.sf.net/sfu/opensolaris-get
>> _______________________________________________
>> 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
--
Alen
|
|
From: Richard F. <ra...@gm...> - 2009-06-09 08:44:26
|
it's a suggestion, not a requirement. The important part is that the
value is constant across the whole system. Right now, I'm lucky enough
to not need a physics model any higher resolution than 20fps, but the
same approach should be taken when you need to do higher resolution
(closer to the ground or other objects).
After spending many years trying to "fix" physics models that run with
variable frame lengths, I realise that it's just not possible. The
beginnings of chaos theory with the Lorenz attractor have convinced me
that it is impossible to be safe and variable in physics models.
One little thing nags at me now, due to this "impossibility", have we
proven that space and time is not continuous?
2009/6/9 Alen Ladavac <ale...@cr...>:
> I guess you use this only if you run with fixed timestep of 20fps?
>
> Aeln
>
> Richard wrote at 6/9/2009:
>
>> the only robust solution i have found to this situation has been to
>> create a sub second k and apply it multiple times.
>
>> float subTimeStep = 0.05f; // 20fps
>> subK = exp(log(k)*subTimeStep);
>
>> mUpdateTimer += deltaTime;
>> while( mUpdateTimer > 0 )
>> {
>> mUpdateTimer -= subTimeStep;
>> x = x*subK;
>> }
>
>> anything else either is slower, or has accuracy issues that make
>> network code impossible to debug.
>
>> 2009/6/5 Zafar Qamar <zaf...@co...>:
>>> Hi,
>>> This is a semi-trivial but I can't quite remember the answer, even
>>> though I've done it before.
>>>
>>> I have an update function sort of like this..
>>>
>>> void updateX( float deltaTime)
>>> {
>>> x = x*k;
>>> }
>>>
>>> k is a constant less than 1.0.
>>>
>>> Now to do the damping properly I need to perform "x=x*k" deltaTime
>>> times, where deltaTime is a fraction.
>>>
>>> Can anyone help with this please? I recall it just being a log or
>>> something.
>>>
>>> Cheers
>>> Zafar Qamar
>>> **********************************************************************************
>>> 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.
>>> **********************************************************************************
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>> looking to deploy the next generation of Solaris that includes the latest
>>> innovations from Sun and the OpenSource community. Download a copy and
>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>> _______________________________________________
>>> 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
>
>
>
>
>
>
> --
> Alen
>
>
--
fabs();
Just because the world is full of people that think just like you,
doesn't mean the other ones can't be right.
|
|
From: Fabian G. <f.g...@49...> - 2009-06-09 09:11:24
|
> it's a suggestion, not a requirement. The important part is that the > value is constant across the whole system. Right now, I'm lucky enough > to not need a physics model any higher resolution than 20fps, but the > same approach should be taken when you need to do higher resolution > (closer to the ground or other objects). > > After spending many years trying to "fix" physics models that run with > variable frame lengths, I realise that it's just not possible. The > beginnings of chaos theory with the Lorenz attractor have convinced me > that it is impossible to be safe and variable in physics models. > > One little thing nags at me now, due to this "impossibility", have we > proven that space and time is not continuous? Well, you don't have the problem with "real" real numbers, this problem is caused by approximating reals with rational numbers. Of course, now the argument hinges on whether real numbers actually exist in physical reality or are merely theoretical constructs. But this is definitely OT so I'll stop now :) -Fabian Giesen |
|
From: Richard F. <ra...@gm...> - 2009-06-09 10:09:36
|
2009/6/9 Fabian Giesen <f.g...@49...>: >> After spending many years trying to "fix" physics models that run with >> variable frame lengths, I realise that it's just not possible. The >> beginnings of chaos theory with the Lorenz attractor have convinced me >> that it is impossible to be safe and variable in physics models. > > Well, you don't have the problem with "real" real numbers, this problem > is caused by approximating reals with rational numbers. > > -Fabian Giesen indeed, this is something, i think, that many computer engineers need to "get over". The fact that we don't have real Reals should be justification enough for fixed point math in physics models and also renderers that work with non-trivial algebra but require repeatability. -- fabs(); Just because the world is full of people that think just like you, doesn't mean the other ones can't be right. |
|
From: Alen L. <ale...@cr...> - 2009-06-09 11:11:56
|
Richard wrote at 6/9/2009: > indeed, this is something, i think, that many computer engineers need > to "get over". The fact that we don't have real Reals should be > justification enough for fixed point math in physics models and also > renderers that work with non-trivial algebra but require > repeatability. It depends on what you want to do with your physics models. On the other hand you could say that some computer engineers need to get over trying to make everything 100% repeatable. Not saying that a complete mess of maths is acceptable, but seeing both sides of the story, I more and more believe that perfect repeatability is kind of like a philosopher's stone. JM2C, Alen |
|
From: Richard F. <ra...@gm...> - 2009-06-09 12:58:29
|
I'd say that you have to aim for 100% repeatable with a physics model that is meant to be part of a network game, but for non multiplayer games you could get away with it. However, what do you benefit from variable time step apart from reduced CPU time on tasks? Not much I'd say. What you gain from fixed time step, fixed point math, or at least repeatable math, is the ability to debug your model. 2009/6/9 Alen Ladavac <ale...@cr...>: > Richard wrote at 6/9/2009: >> indeed, this is something, i think, that many computer engineers need >> to "get over". The fact that we don't have real Reals should be >> justification enough for fixed point math in physics models and also >> renderers that work with non-trivial algebra but require >> repeatability. > > It depends on what you want to do with your physics models. On the > other hand you could say that some computer engineers need to get over > trying to make everything 100% repeatable. Not saying that a complete > mess of maths is acceptable, but seeing both sides of the story, I > more and more believe that perfect repeatability is kind of like a > philosopher's stone. > > JM2C, > Alen > > -- fabs(); Just because the world is full of people that think just like you, doesn't mean the other ones can't be right. |
|
From: Alen L. <ale...@cr...> - 2009-06-10 05:35:35
|
Richard wrote at 6/9/2009: > I'd say that you have to aim for 100% repeatable with a physics model > that is meant to be part of a network game, but for non multiplayer > games you could get away with it. Hm, I'd say that "100% repeatable" would mean "can repeat the exactly same results when re-simulating from exactly same inputs, no matter for how long the simulation lasts". For most network games you will have some server synchronization anyway, and what is needed there is just "approximately the same results when resimulating from exactly the same inputs, for some shorter period of time". A packet comes in from the server every once in a while and corrects eventual inconsistencies anyway. Granted, for some platforms and gametypes, you want to use full lock-step, and then you need 100% repeatability. > However, what do you benefit from variable time step apart from > reduced CPU time on tasks? Not much I'd say. Exactly that. Reduced CPU time on AI, collision and physics. And not just reduced, but more scalable. And that is very important. Fixed time step leads to situations where a slower machine gets even slower. What would be the spiral of death, unless you limit the longest frame possible, but even with the limit, a slower machine is non-linearly slower than a faster machine. E.g. let's say one step takes 1ms to process on machine A, and 5ms on machine B. At the same time, rendering takes 9ms on A, and by extension 45ms on B. So with variable timestep, X runs at 1000/(1+9)=100fps, while Y runs at 1000/(5+45ms)=20fps. Let's say you want to fix the timestep at 50Hz. X still runs at 50fps, while poor Y is now at around 1000/(5*3+45)~=16.7fps. Plus the fact that X now has some interpolation and some input lag (this is 20ms lag in local actions, which a skilled deathmatcher will notice). Of course, this is oversimplified, but I hope it illustrates the problem. I'm not saying that you can let everything run at any rate. Some things (ragdolls, e.g.) may require step subdivisions, as they cannot really run at 10Hz. But forcing everything to the same rate is prohibitively expensive on slower machines, if the physics is intense, IME. > What you gain from fixed time step, fixed point math, or at least > repeatable math, is the ability to debug your model. Doing it both ways, my experience is that the amount time you save by simpler debugging due to repeatability, is completely overwhelmed by the amount of debugging needed to keep the repeatability. So I'd say you choose fixed time step on the basis of whether you really need _so exact_ repeatability for networking, not just for simpler debugging. If you can get away with _mostly repeatable_ and resync every once in a while, you life is definitely simpler. JM3C, Alen |
|
From: Zafar Q. <zaf...@co...> - 2009-06-16 14:23:15
|
Hi All, Thanks for all the help you people have given me in the past. A question about blurring. I want to do a soft blur in HLSL. Preferably in one-pass. I've read lots of stuff but I want to know if anyone has managed to come up with a solution that works in one-pass and achieves a soft blur, AND is fast. Any help much appreciated. Cheers Zafar Qamar ********************************************************************************** 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. ********************************************************************************** |
|
From: Oscar F. <os...@tr...> - 2009-06-16 20:54:39
|
What sort of blur do you want? (ie full screen?) What sort of kernel do you want to use? (ie Gaussian?) What sort of hardware are you targetting? I'd be very surprised, though, if you could beat a 2 pass (horizontal then vertical) blur though. To do the equivalent in a single pass would require a stupid amount of samples. The 2 pass 7 tap per pass gaussian blur (ie 14 samples and 2 writes per pixel) would require 49 samples and 1 write per pixel to do in a single pass. I'd be very surprised if you could get an equivalent blur for the same cost as doing 2 passes. I'll be very interested if some can show me an equivalently good single pass method, but I doubt they will ... Oscar 2009/6/16 Zafar Qamar <zaf...@co...> > Hi All, > > Thanks for all the help you people have given me in the past. > > A question about blurring. > I want to do a soft blur in HLSL. Preferably in one-pass. > I've read lots of stuff but I want to know if anyone has managed to come > up with a solution that works in one-pass and achieves a soft blur, AND > is fast. > > Any help much appreciated. > > Cheers > Zafar Qamar > > > ********************************************************************************** > 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. > > ********************************************************************************** > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > 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 |
|
From: Steve L. <sm...@go...> - 2009-06-16 20:54:49
|
> Hi All, > > Thanks for all the help you people have given me in the past. > > A question about blurring. > I want to do a soft blur in HLSL. Preferably in one-pass. > I've read lots of stuff but I want to know if anyone has managed to > come > up with a solution that works in one-pass and achieves a soft blur, AND > is fast. > > Any help much appreciated. > > Cheers > Zafar Qamar Its generally quicker to do a two-pass Gaussian blur (the Gaussian kernel is separable so you can reduce the number of texture samples from N^2 to 2*N by doing two passes, one horizontal and one vertical. I believe this also keeps it on topic since this is an algorithmic optimisation ;) Thanks, Steve. |
|
From: Jon W. <jw...@gm...> - 2009-06-16 21:17:31
|
Zafar Qamar wrote: > Hi All, > > Thanks for all the help you people have given me in the past. > > A question about blurring. > I want to do a soft blur in HLSL. Preferably in one-pass. > I've read lots of stuff but I want to know if anyone has managed to come > up with a solution that works in one-pass and achieves a soft blur, AND > is fast. > You can't do it in a single pass (as in: the forward pass when you render), because the output of blur is non-local, and the geometry pixel shader only has access to local information. Thus, it has to be done as a post-process, where you can use non-local (image-space) input. Second, you can calculate the Gaussian blur in a single post-processing pass if you want. It's no different from doing the horizontal and vertical in two different passes, except for the amount of math involved. If you do that, then you'll be using a large amount of pixel shader instructions compared to framebuffer writes, which will generally be slower than just doing two separate passes on render targets. All hardware is decent enough at fill rate compared to shader instructions that it doesn't make sense to try to do it in a single post-process pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that detemrination may change, but we're nowhere near there just yet :-) Sincerely, jw |
|
From: Ivan-Assen I. <iva...@gm...> - 2009-08-11 08:18:33
|
> Second, you can calculate the Gaussian blur in a single post-processing > pass if you want. It's no different from doing the horizontal and > vertical in two different passes, except for the amount of math > involved. If you do that, then you'll be using a large amount of pixel > shader instructions compared to framebuffer writes, which will generally > be slower than just doing two separate passes on render targets. All > hardware is decent enough at fill rate compared to shader instructions > that it doesn't make sense to try to do it in a single post-process > pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that > detemrination may change, but we're nowhere near there just yet :-) I beg to disagree - it still depends on the particular hardware and filter sizes. There's this weird piece of hardware that has sold in the mid-two-digit millions, yet refuses to sample from its framebuffer, so if you're doing two passes, you have to do transfer the results from the first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster in one pass instead of separated in H and V. |
|
From: Mark S. <ma...@4c...> - 2009-08-11 09:23:36
|
Ivan-Assen Ivanov wrote: >> Second, you can calculate the Gaussian blur in a single post-processing >> pass if you want. It's no different from doing the horizontal and >> vertical in two different passes, except for the amount of math >> involved. If you do that, then you'll be using a large amount of pixel >> shader instructions compared to framebuffer writes, which will generally >> be slower than just doing two separate passes on render targets. All >> hardware is decent enough at fill rate compared to shader instructions >> that it doesn't make sense to try to do it in a single post-process >> pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that >> detemrination may change, but we're nowhere near there just yet :-) >> > > I beg to disagree - it still depends on the particular hardware and > filter sizes. > > There's this weird piece of hardware that has > sold in the mid-two-digit millions, yet refuses to sample from its framebuffer, > so if you're doing two passes, you have to do transfer the results from the > first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster > in one pass instead of separated in H and V. > > I'm curious, what hardware is that? This is the first I've heard of this and I'm wondering if it's something I'd need to worry about. |
|
From: Fabian G. <f.g...@49...> - 2009-08-11 09:29:13
|
Mark Sararu schrieb: > Ivan-Assen Ivanov wrote: >> There's this weird piece of hardware that has >> sold in the mid-two-digit millions, yet refuses to sample from its framebuffer, >> so if you're doing two passes, you have to do transfer the results from the >> first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster >> in one pass instead of separated in H and V. >> >> > I'm curious, what hardware is that? This is the first I've heard of this > and I'm wondering if it's something I'd need to worry about. It's not something you need to worry about unless you're a console developer. Cheers, -Fabian |
|
From: Oscar F. <os...@tr...> - 2009-08-11 09:24:43
|
heh ... I never thought of trying that ... I just removed the fullscreen blur in the end ... it didn't add anything to the game and was just there because another platform, with a very very quick frame buffer that sold even more units, had cycles to burn :D 2009/8/11 Ivan-Assen Ivanov <iva...@gm...> > > Second, you can calculate the Gaussian blur in a single post-processing > > pass if you want. It's no different from doing the horizontal and > > vertical in two different passes, except for the amount of math > > involved. If you do that, then you'll be using a large amount of pixel > > shader instructions compared to framebuffer writes, which will generally > > be slower than just doing two separate passes on render targets. All > > hardware is decent enough at fill rate compared to shader instructions > > that it doesn't make sense to try to do it in a single post-process > > pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that > > detemrination may change, but we're nowhere near there just yet :-) > > I beg to disagree - it still depends on the particular hardware and > filter sizes. > > There's this weird piece of hardware that has > sold in the mid-two-digit millions, yet refuses to sample from its > framebuffer, > so if you're doing two passes, you have to do transfer the results from the > first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster > in one pass instead of separated in H and V. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X