Thread: [Algorithms] Frame independent Camera Shake
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Amir H. F. <ah...@ad...> - 2009-12-19 07:17:28
|
Hello everyone, I am trying to implement a camera shake feature and I was wondering what a robust and standard technique for it could be. Currently I am using this formula : value = a * sin(nx)/mx; to come up with the displacement necessary for the camera node in time, however, variable frame rates can cause the final result to behave differently. I was wondering what other developers do for implementing camera shakes. Regards, Amir |
|
From: Jason H. <jh...@st...> - 2009-12-19 07:54:23
|
Camera shake is inherently tied to frame rate. A shake that looks good at 20hz will not necessarily be impressive at 30hz. Even so, if you make sure the shake occurs according to delta-time rather than a fixed step per frame, that's at least going in the right direction. For very low framerates, you may lose all sense of shake at all, just because the frequency of the shake is a multiple of the frequency of the frames! Nothing much you can do there. If you have that problem, the best I can suggest is try using a translation-based, non-periodic shake, rather than a rotationally-based one. The benefit of that is, you get the same sensation of shake regardless of the scale of your scene (rotation affects distant objects more, obviously), and non-periodic prevents you from losing the shaking sensation just because your framerate varies or drops. Eg. camTrans = vector.random() * scale On Wing Commander: Prophecy (or was it WC4?) I put in a camera shake that was framerate independent in different way... when you got hit, I computed an axis and angle based on where the shot contacted your ship and how much damage you had taken, then rotated the camera (for both the HUD and the 3D scene) + on even frames, - on odd frames, and lerped the angle down toward zero over time. This gave a kind of drunken-image that worked at high or low frame rates. Two different approaches, two different situations. Best, JH Jason Hughes President Steel Penny Games, Inc. Austin, TX Amir H. Fassihi wrote: > Hello everyone, > > I am trying to implement a camera shake feature and I was wondering > what a robust and standard technique for it could be. > Currently I am using this formula : value = a * sin(nx)/mx; to come up > with the displacement necessary for the camera node in time, however, > variable frame rates can cause the final result to behave differently. > > I was wondering what other developers do for implementing camera shakes. > > Regards, > > Amir > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ------------------------------------------------------------------------ > > _______________________________________________ > 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: Amir H. F. <ah...@ad...> - 2009-12-19 09:13:35
|
Thank you Jason for the descriptions, would you elaborate the non-periodic shake a bit more. Does this : camTrans = vector.random() * scale mean that a random translation is computed every frame and applied to the camera? On Sat, Dec 19, 2009 at 11:05 AM, Jason Hughes <jh...@st...>wrote: > Camera shake is inherently tied to frame rate. A shake that looks good at > 20hz will not necessarily be impressive at 30hz. Even so, if you make sure > the shake occurs according to delta-time rather than a fixed step per frame, > that's at least going in the right direction. For very low framerates, you > may lose all sense of shake at all, just because the frequency of the shake > is a multiple of the frequency of the frames! Nothing much you can do > there. > > If you have that problem, the best I can suggest is try using a > translation-based, non-periodic shake, rather than a rotationally-based > one. The benefit of that is, you get the same sensation of shake regardless > of the scale of your scene (rotation affects distant objects more, > obviously), and non-periodic prevents you from losing the shaking sensation > just because your framerate varies or drops. Eg. camTrans = vector.random() > * scale > > On Wing Commander: Prophecy (or was it WC4?) I put in a camera shake that > was framerate independent in different way... when you got hit, I computed > an axis and angle based on where the shot contacted your ship and how much > damage you had taken, then rotated the camera (for both the HUD and the 3D > scene) + on even frames, - on odd frames, and lerped the angle down toward > zero over time. This gave a kind of drunken-image that worked at high or > low frame rates. > > Two different approaches, two different situations. > > Best, > JH > > Jason Hughes > President > Steel Penny Games, Inc. > Austin, TX > > > > Amir H. Fassihi wrote: > > Hello everyone, > > I am trying to implement a camera shake feature and I was wondering what a > robust and standard technique for it could be. > Currently I am using this formula : value = a * sin(nx)/mx; to come up with > the displacement necessary for the camera node in time, however, variable > frame rates can cause the final result to behave differently. > > I was wondering what other developers do for implementing camera shakes. > > Regards, > > Amir > > ------------------------------ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customershttp://p.sf.net/sfu/verizon-dev2dev > > ------------------------------ > > _______________________________________________ > GDAlgorithms-list mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives:http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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: Jason H. <jh...@st...> - 2009-12-19 09:28:44
|
Yes. You don't want the camera position to wander away, so the random amount is an offset from where the camera 'actually' is, before applying any shake. Every frame, you just pick a new spot to put the camera. The intensity is controlled by the scale factor. You might want to make sure the shake vector is a randomized unit vector within the plane parallel to the near plane (ie. XY in camera local space), so you can get more reliable results. Or perhaps non-unit will appeal to you. That's more a matter of taste than science at this point. JH Jason Hughes President Steel Penny Games, Inc. Austin, TX Amir H. Fassihi wrote: > Thank you Jason for the descriptions, would you elaborate the > non-periodic shake a bit more. Does this : camTrans = vector.random() > * scale mean that a random translation is computed every frame and > applied to the camera? > > |
|
From: Jon W. <jw...@gm...> - 2009-12-19 17:20:40
|
In general, shake is a sum of almost-instantaneous impulses off-center, plus the attempts of the camera person to center the camera. Thus, you can implement camera shake as a sequence of random impulses (Brownian motion style), and a first-order error correction dampened spring. The rate and magnitude of impulses are two main tweakables, plus how much the shake affects camera orientation vs position (turns out, orientation is much wilder than position :-) I'd start with 3 degrees of orientation affect at 5 Hz, and then tweak from there (or set it at that and let the artists make it right :-) 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 Fri, Dec 18, 2009 at 11:17 PM, Amir H. Fassihi <ah...@ad...> wrote: > Hello everyone, > > I am trying to implement a camera shake feature and I was wondering what a > robust and standard technique for it could be. > Currently I am using this formula : value = a * sin(nx)/mx; to come up with > the displacement necessary for the camera node in time, however, variable > frame rates can cause the final result to behave differently. > > I was wondering what other developers do for implementing camera shakes. > > Regards, > > Amir > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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: Gino v. d. B. <gin...@gm...> - 2009-12-21 09:45:40
|
You may consider to leave out position shake altogether because slight position changes do not show on objects that are further than a few meters away. Also, ease back on the camera roll because it makes people nauseous. For a racing game I simulated the offset on the yaw and pitch by a point mass that was suspended by a spring damper just as how John described. The impulses where fed from the actual game physics so the camera shake would look more natural (more vertical shake while driving, random shake when colliding.) Gino On 19-12-2009 18:20, Jon Watte wrote: > In general, shake is a sum of almost-instantaneous impulses > off-center, plus the attempts of the camera person to center the > camera. Thus, you can implement camera shake as a sequence of random > impulses (Brownian motion style), and a first-order error correction > dampened spring. The rate and magnitude of impulses are two main > tweakables, plus how much the shake affects camera orientation vs > position (turns out, orientation is much wilder than position :-) > I'd start with 3 degrees of orientation affect at 5 Hz, and then tweak > from there (or set it at that and let the artists make it right :-) > > 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 Fri, Dec 18, 2009 at 11:17 PM, Amir H. Fassihi <ah...@ad... > <mailto:ah...@ad...>> wrote: > > Hello everyone, > > I am trying to implement a camera shake feature and I was > wondering what a robust and standard technique for it could be. > Currently I am using this formula : value = a * sin(nx)/mx; to > come up with the displacement necessary for the camera node in > time, however, variable frame rates can cause the final result to > behave differently. > > I was wondering what other developers do for implementing camera > shakes. > > Regards, > > Amir > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution > fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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 > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > > > _______________________________________________ > 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: Sam M. <sam...@ge...> - 2009-12-21 12:01:40
|
I’d agree with Gino. Positional shake just wasn’t obvious enough and looked wrong to me in both 3rd person and 1st person cameras when I last tried it. Rotational shake was the way to go.
I didn’t run into a conflict between frame rate and shake rate, although I can see how this could be a problem. Perhaps because the changing shake rate changed fast enough that you didn’t notice any aliasing.
Straightforward sine waves looks a bit too smooth though. In order to get the jittery look I just clamped them beyond some threshold so you got the ‘shaking a penny in a box’ effect.
Just my 2p.
Ta,
Sam
From: Gino van den Bergen [mailto:gin...@gm...]
Sent: 21 December 2009 09:46
To: gda...@li...
Subject: Re: [Algorithms] Frame independent Camera Shake
You may consider to leave out position shake altogether because slight position changes do not show on objects that are further than a few meters away. Also, ease back on the camera roll because it makes people nauseous. For a racing game I simulated the offset on the yaw and pitch by a point mass that was suspended by a spring damper just as how John described. The impulses where fed from the actual game physics so the camera shake would look more natural (more vertical shake while driving, random shake when colliding.)
Gino
On 19-12-2009 18:20, Jon Watte wrote:
In general, shake is a sum of almost-instantaneous impulses off-center, plus the attempts of the camera person to center the camera. Thus, you can implement camera shake as a sequence of random impulses (Brownian motion style), and a first-order error correction dampened spring. The rate and magnitude of impulses are two main tweakables, plus how much the shake affects camera orientation vs position (turns out, orientation is much wilder than position :-)
I'd start with 3 degrees of orientation affect at 5 Hz, and then tweak from there (or set it at that and let the artists make it right :-)
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 Fri, Dec 18, 2009 at 11:17 PM, Amir H. Fassihi <ah...@ad...> wrote:
Hello everyone,
I am trying to implement a camera shake feature and I was wondering what a robust and standard technique for it could be.
Currently I am using this formula : value = a * sin(nx)/mx; to come up with the displacement necessary for the camera node in time, however, variable frame rates can cause the final result to behave differently.
I was wondering what other developers do for implementing camera shakes.
Regards,
Amir
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
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
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
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: Will V. <wi...@se...> - 2009-12-21 14:18:31
|
If you have the ability to blur your output image, you can layer this on top of camera shake in very small amounts - e.g. one frame of blur when you hit something. It can be quite effective - I reckon it looks like high frequency shake, as a counterpoint to the (relatively) low frequency shake provided by moving the camera. If you already have *motion* blur there isn't much point, but there are platforms where that isn't practical still. Will |
|
From: Andy F. <pad...@ob...> - 2009-12-21 15:10:30
|
Damping would be important to a realistic effect. Scale the sine impulses by a square or cubic function with a decay of around a second. As Will says, the blur simulates high frequency shake, so you don't really need to add higher harmonics onto your sine waves if you have that - make it proportional to the rms amplitude of the movement. Andy On Mon, Dec 21, 2009 at 11:57:11PM +1300, Will Vale wrote: > > If you have the ability to blur your output image, you can layer this on > top of camera shake in very small amounts - e.g. one frame of blur when > you hit something. It can be quite effective - I reckon it looks like high > frequency shake, as a counterpoint to the (relatively) low frequency shake > provided by moving the camera. > > If you already have *motion* blur there isn't much point, but there are > platforms where that isn't practical still. > > Will > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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