Motion Blur

Started by
7 comments, last by weasalmongler 16 years, 11 months ago
Hi guys, I was wondering if anyone could recommend me a good motion blur algorithm that is relatively low cost and looks quite good. I have just tried an implementation of the Direct3D Per Pixel Motion blur demo technique (in the SDK with velocity buffers) and for the most part it works quite well. However, if you have a large polygon that fills most of the screen, you get horrible distortion artifacts that completely destroys the effect. I'm looking for either a way to fix this technique up to remove these artifacts or to find a new technique that is better. The renderer that I'm making is a deferred renderer, so is actually quite suited to the velocity buffer technique, so it is a shame that so far it hasn't worked that well. I am also working in DirectX 10 so I could use geometry shaders if need be, but from what I've seen they are a bit too slow. I don't want to use the new DX10 motion blur technique (the ogre demo) as framerates are appauling on my system and I want my game to work in real time ;). Thanks in advance for any help!
Advertisement
I think it'd be easier just to make sure that the player didn't get too close to any one polygon. Motion blur is just a way to make transitions from frames look smoother.
Rendering the render target onto a transparent quad without clearing the backbuffer is a very cheap way of getting motion blur. The level of transparency will correspond to the alpha component of the quad. Don't know how it compares visually to other methods, but seeing that it's so easy to implement you may as well give it a go.
sevensevens: That is always an option, but if a level had a large polygon for a wall then it might cause a few problems. I don't really want to have to subdivide my walls to increase polygon count in order to remove these artifacts if possible. I'm still not sure what the artifacts are caused by so there might still be a way of removing them.

Barakus: The method that you have described is from what I can tell, heavily framerate dependent. If you are running at a very high framerate then the older frames will be overwritten so fast that you won't have a chance to see the blur. I had a look at a few samples using that technique that you mentioned and unfortunately I couldn't see any motion blur in the demos at all. I believe this to be the reason.

Thanks for your suggestions, I'm still looking for more if anyone wants to help out :).
Well there's always the "correct" way, IE temporal anti-aliasing. However I very much doubt you'd like to render your scene 8 times a frame. :P

I've implemented the per-pixel-velocity method in the past, and I've generally been disappointed with the results. It helps as far as smoothing everything out, but artifacts can be quite noticeable. I like the method in the DX10 sample, but like you've said the performance isn't where it needs to be.

Quote:Original post by weasalmongler
sevensevens: That is always an option, but if a level had a large polygon for a wall then it might cause a few problems. I don't really want to have to subdivide my walls to increase polygon count in order to remove these artifacts if possible. I'm still not sure what the artifacts are caused by so there might still be a way of removing them.



The artifacts don't have anything to do with the poly-count, its a limitation of the specific implementation. Since you're just using a blur as a post-process, the kernel will sample things it shouldn't sample because you don't know where object boundaries are. I believe some people have attempted to remedy this by using different foreground/background buffers.

Well, the artifact that I am talking about is slightly different to just the edges being wrong. It causes the whole polygon to flicker and distort and basically go crazy. It is a known issue with the technique, it's quite hard to describe without a video though.
Hi,

The DirectX motion blur demo divides by w in the vertex shader to get the resultant screen space values. This isn't accurate enough since w values can't be linearly interpolated (which is what is happening here). Instead, pass your values through to the pixel shader and do the divide by w there.

Additionally, there are some other problems with large velocity values and negative w values generated from the previous transform... I believe they are solved in this thread:

http://www.gamedev.net/community/forums/topic.asp?topic_id=390791&whichpage=1

Good luck,
stoo
Thank you! That fixed all the artifacts that I was experiencing and now I'm getting some pretty decent results. I had kind of linked the problem to the divide by w, but I hadn't quite worked out what to do about it. Shame I didn't think about moving it to the pixel shader! I'll have a read of that other page as well and see if I can improve the technique further. Thanks again!

This topic is closed to new replies.

Advertisement