Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Nick London, posted on February 03, 2002

Image Description, by Nick London

Not an incredibly exiting image, but this is real-time, incredibly fast motion blur in action. :) I assure you it looks awesome moving, although I cant release any binaries due to the nature of the project, sorry. :P

Incredibly easy to do, all you need to do is disable clearing the Color buffer and render the scene with a low alpha, like glColor(1.0, 1.0, 1.0, 0.2), and viola! Fast and quite cool looking. :)

Only problem is that the objects become transparent (obviously) but this can be fixed by sorting and rendering the polygons front to back. And the problem here is that if you use alpha in any of your textures you'll get wierd results.

But I'd imagine for in-game cutscenes or merely incredibly fast-paced games this effect would prove quite handy, since there's almost no performance hit at all.

Has anyone ever tried this method before? And are there better ways to get around the 'transparent object' problem? Let me know.

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
Orangy Tang

February 03, 2002, 12:00 PM

Neat, but not true motion blur (best i've seen is the effects on 3dMark 2001, but thats probably some sort of scene-specific hack). I think Motorhead used this technique - or at least something very like it, it definatly adds to the sense of speed in a fast moving game like that and looks impressive while moving :)


February 03, 2002, 12:04 PM

Very nice. Will this work if the user is moving forward as well? Or would the objects end up covering their own blur trailers?

(Ignorance is one of my primary attributes ;))

Jari Komppa

February 03, 2002, 12:08 PM

How about doing it with a-buffer or lacking that, rendering to texture and blending those?


February 03, 2002, 01:42 PM

Nice work. There's a variation of this trick which is often used in the demo scene. It has a significantly higher fillrate consumption in the general case but solves the transparency problem. First of all, do not clear the color buffer between frames. You first render the scene into a texture. Now setup a full-screen polygon with this texture covering it and the appropriate vertex alpha and then blend this onto the existing color buffer. This effectively gives you the effect you are describing but with none of transparency artifacts. Cheers.

Tim Aidley

February 03, 2002, 01:56 PM

That effect is used a great deal on Playstation and Playstation 2 games. Metal Gear Solid uses it to good effect, and Grand Theft Auto 3 on the PS2 has a slight version of it on all the time.

It's not real motion blur, of course, more like overblown persistance of vision - much like the effect you get playing on old LCD monitors (or a palm pilot!)

Oh, and to fix your problems with ordering and alpha, render the whole scene normally in the back buffer and then blit to the front buffer with a certain alpha (e.g. 0.75). Clear the back buffer as usual, just don't flip the front and back as you usually would.

If you experience 'tearing' you could triple buffer instead.


February 03, 2002, 02:47 PM

Word of caution: This only works with a single-buffered display. As soon as you use double-buffering, the back buffer content is undefined, and it's pure luck if you get the color buffer of the last frame.

- Andreas

P. Kramer

February 03, 2002, 02:55 PM

Hi it just happened that a ran into
another kind of motion blur effect described
at nvidia's website.
It requires a vertex/pixel shader capable card,
like the geforce3 or the radeon8500.

The link to the effect is:


February 03, 2002, 04:19 PM

Looks quite cool, as Tim mentions this/similar thing is used on PS2 - Often to try and Blend the rendering of fields more and reduce interlace flicker. Also for special effects.

We found it can make you feel quite sick after a while of very high blur :) - but leads to some quite trippy experiences.



February 03, 2002, 05:11 PM

Wow - looks really really great!
Go on with stuff like that!

Have fun


February 03, 2002, 05:46 PM

The orignal method, as described, suffers from artifacts if you're relying on the Z buffer for hidden surface elimination, as hidden faces will still affect the frame buffer. If you're using a BSP based renderer (which is overdraw free) then it's not so bad.

If you have render-to-texture, that's clearly the best way to achieve this effect, as others have already said.

If you don't have render-to-texture, but you do have CopyTexSubImage() (in GL parlance) you can achieve this effect fairly efficiently (still keeping all data on the card, not involving the CPU or the bus) by doing:

Initialize by creating a texture (call it "history") large enough to fill the entire screen.

For each frame:

1) render new scene to framebuffer (as normal)
2) blend a "history" texture onto the entire screen
3) CopyTexSubImage the screen into the "history" texture
4) flip buffers

Set the amount of blur by adjusting the blend factor used in 2). If you initialize the history texture to black, you'll get a somewhat soft fade-in when you start rendering, which looks cool, too. You can also fade to black at the end in the same way.

Mathieu 'POĻ' HENRI

February 03, 2002, 07:30 PM

my question may sound stupid but is there any other method to do motion/radial blur than the classic : blend previous_screen with current screen ??
I can't find something faster and easier, nothing surprising that this effects has been seen in many demos since many years


February 03, 2002, 07:58 PM

(D3D8, I don't know anything else)
It works even better because polygones are not transparent with this trick but we still have a problem as far as I see (if I am wrong, tell me) :
To render in a texture, you have to say set it as the render target, then render ... and then RErender the scene to the screen. So it cuts the FPS by 2.

The problem here is that we have to copy the display buffer to a texture. One way to do it is to bring back the buffer from video memory to system memory, copy the picture, byte by byte, into the texture, and then everything back to video mem .... don't like it.

Does it exist a function that copies the content oof a surface to a texture INSIDE the video mem without bringing it back to sysmem ?


February 03, 2002, 08:07 PM

This is not a real motion blur. Good looking but not a good one.

In real life, motion blur are due to movement and the fact that a picture can not be taken in 0.000000 sec. It lasts from 1/1000 to 1/10 sec (usually, on everyday reflex camera).

In your exemple, only polygones "going backwards" (= facing the opposite of the moving direction) are "motion blured" (= transformed and faded). IRL, every polygones are blured because of the motion.

In broadcast 3D animation, like in 3DSMax, the trick is to take pictures (the more the better) before and after the actual time and to blend all this images. The timespan of the images is the time it took to take the picture in real life. The same trick is used too in depth of field (we do not take picture at slightly different date but slightly different position).


February 03, 2002, 08:33 PM

In broadcast 3D animation, like in 3DSMax, the trick is to take pictures (the more the better) before and after the actual time and to blend all this images.

Actually, that's effectively what happens here. Imagine a static scene--neither the objects nor the camera is in motion. In this case the alpha blending will be a no-op since ax + (1-a)x is trivially x. Now imagine an object moving in a circular trajectory. In this case the object will effectively leave a trail behind. Images of the object from previous frames will fade as time passes, eventually disappearing. The net effect is that object will have a relatively smooth trail the length of which is proportional to the speed of the object. The standard high-end scan-line rendering algorithm for motion blur is not too dissimilar from this. Admittedly, the samples are accumulated each frame from scratch instead of accumulating into the existing color buffer.

David Notario

February 03, 2002, 08:38 PM

hmm, that method is flakey, as u state in your comment.

what i've done in the past is render to texture, u have a texture as an acumulator, u render the scene into another texture, blend it with the acumulator, and then dump it to the frame buffer.

you can check it out at in action

Download Nature v2.0


February 03, 2002, 08:43 PM

Well, I know it's not really a new method, but it's the fastest method I've found (Most rely on Accum buffers (Yuck!) and that vertex/pixel shader on Nvidia only gets an FPS of 19 for a simple scene on my system) with practically no performance hit (If you exclude the hit from alpha blending everything and whatever trick you decide to use for getting rid of the transparency problem).

And it works while you're going up, down, back, forwards, all directions... and still looks effective. :)

About the only real difficulty is making the scene have a consistant alpha level (Sort of render the scene and copy it across to the front buffer with every pixel having the same alpha value)... and blitting seems kinda slow, especially to a texture.

I'm also aware this isn't 'real' motion blur, but hey, we dont have 'real' lighting real-time either. :)

Sniper BoB

February 03, 2002, 09:46 PM

If you just want to motion blur a particular object why don't you boot up a classic and take a look. I'm talking about Duke Nuk'em 3D. One of the weapons fires a bouncing explosive ball. To create the effect of motion blur on the object the ball was just rendered from oldest position to newist position (for X positions). The resulting effect is actually not terrible considering the age of the game. So if you remove some alpha progressively for each older instance you could very easily create an acceptable motion blur effect for a single object. The only issue with this is that it multiplies the number of polys in that object by X trails. So use sparingly.

Cem Cebenoyan

February 04, 2002, 12:31 AM

I don't understand why people keep saying this technique is "almost free". It requires alpha blending the entire framebuffer, incurring at least one extra color read per pixel, and certainly more with the way it's formulated above (rendering to offscreen texture and blending should be faster). If you just render and don't worry about z-buffering artifacts, you incur an extra color read for every single pixel that would be written the framebuffer (so, counting overdraw).

Considering memory bandwidth is just about the #1 thing slowing down realtime graphics these days, I'd hardly say this technique is "free".

Doesn't mean it doesn't look cool, though! And it's certainly simple to implement.


February 04, 2002, 12:38 AM

One neat thing you could do with do with kind of effect (although in practice I would use bgl's method) is simulate being drunk. What I was thinking was some kind of multiplayer bar fight game. Alcohol would give you health, but as a side effect impair your vision. Weapons includes but not limited to:

Beer or Whiskey bottle (thrown)
Cracked bottle (melee weapon)
Pool Que

The game would be pretty frantic.... duck behind the bar, chuck a beer bottle at someone, get cracked over the head by a guy with a pool que....

Just another one of my many strange ideas that get thought up but nothing done about...

Rasmus Christian Kaae

February 04, 2002, 02:19 AM

Which is the same way psykotic (per) described it ;-)

William Dahlberg

February 04, 2002, 02:19 AM

Now, that would be a cool game!


February 04, 2002, 03:53 AM

Hi there,

a small variant can be used to overcome the polygon-sorting problem as well as the transparencies in the scene. All you have to do is render your scene off-screen and then draw a full-screen sprite textured with the new frame on top of the screen buffer with the alpha set to whatever you like. That way you can even create cool effects like zooming and stuff if you modify the screen buffer before you draw the alpha-ed sprite.


February 04, 2002, 03:55 AM

and next time I'll read the messages before I post, so I won't look so much like a smart-ass.


February 04, 2002, 04:04 AM

some Ideas from a non-programmer
first of all for anyone who owns an N-64 this exact technique is used whenever the player is "drugged" or is hurt so that the screen becomes blurry for a bit

another Idea you could render the entire scene to a polygon and then use mipmapping and fading between mipmaps to simulate a focal change (like when using binoculars)


February 04, 2002, 04:32 AM

another Idea you could render the entire scene to a polygon and then use mipmapping and fading between mipmaps to simulate a focal change (like when using binoculars)

Interesting. But I don't think mipmaps are the solution here. As every frame is used only once, you blur it and use it as a texture once, no need to have several resolutions of the frame.
What you can do is draw to the screen buffer, then copy to off-screen, use your favorite blurring technique, and then use the Z-buffer as an alpha channel (using the 8 bits in the middle gives best results) to copy the blurred version back on the screen buffer, so that the polys in the distance have low alpha and are blurred and polys in focus have high alpha and look sharp.
Do I make sense ?


February 04, 2002, 05:01 AM

"The problem here is that we have to copy the display buffer to a texture. One way to do it is to bring back the buffer from video memory to system memory, copy the picture, byte by byte, into the texture, and then everything back to video mem .... don't like it. "

Geez... if you're doing it this way, it will surely hurt. But there is CopyTexImage in OGL, which makes things a lot easier. :)


February 04, 2002, 05:10 AM

That looks GRAT (really), but it's a mistake to call it motion blur, it should be called "trail blur" (?)

The real motion blur (as our eyes percept it) is done "accumulating" the image on the retina, so the result isn't a NEAT object with a blurred trail, but something like a "front trail", an image of a quite neat object, and a "back trail"...

That's explaination suxx, I know. :D

Anyway a good way to do fast blur, not that accumulation superslow method :D



February 04, 2002, 05:42 AM

Also used in Xtreme G3 as well. This is used to hide the screen jitter that the PS2 really suffers from. If the frame rate falls below the screen refresh rate (50 Hz on PAL, 60 Hz on NTSC) it jitters like crazy.


February 04, 2002, 07:51 AM

As I said in one of my previous posts, doing real-time real motion blur is completly unfeasable (spelling?)... and it's not like we dont use fake tricks for lighting, yet we still call it lighting. :)

It's motion blur to me, 'cause it looks like motion blur. :)


February 04, 2002, 09:07 AM

And don't forget WGL_ARB_pbuffer!

This thread contains 37 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.