Verify my motion blur idea
What about vsync and tearing? If youre running sub 60fps wont you get nasty tearing? I know my game looks like crap at anything below 60fps, but GORGEOUS at 60fps vsync. Wont we be giving that up if we use motion blur?
Why don't you just enable vsync if you're worried about tearing? In DirectX just apply D3DPRESENT_INTERVAL_ONE, OpenGL probably does something just as simple.
Also, couldn't you just have the motion blur quality depend on the machine? For instance, on machines running your game under 60fps, just disable motion blur. Then for the beefy machines that can handle 120+, use the wasted frames.
Also, couldn't you just have the motion blur quality depend on the machine? For instance, on machines running your game under 60fps, just disable motion blur. Then for the beefy machines that can handle 120+, use the wasted frames.
Well, the reason that you can lock the framerate under 60 FPS (like 30 as I mentioned) is because of the accuracy of the motion blur. The only reason that 40-50-60 frames still seem off with current games is because of the lack of that same motion blur. If you can sample 3-4 targets+ for every frame (30Hz) there is no need to bring the framerate any higher. Beefier machines can simply render more samples and their motion blur will be that much more accurate.
Perhaps that sounds stupid, but have the 'extra frames' to be rendered full resolution? It would be interesting to see how it looks with extra frames rendered a 1/2 the main resolution. Since this would speed it up a lot (I suppose), then you can survive with less power without 'wasting' 80% of the power just for the motion blur, reducing the usage down to, let's say, 50%...
Correct me if I'm wrong... but isn't the best way to render motion blur like this:
1. When rendering pixels, store the velocity of that pixel (relative to camera) into a 'velocity' buffer.
2. Do a post process on the final image, whereby you blur pixels in the direction and magnitude of that pixels velocity.
3. Remove banding on the motion blur, by doing a random texture lookup on a gray scale noise texture and use that value (0-1) to offset where you take the samples from. That effectively removes the banding.
4. With access to the Z-buffer as well, you can make sure pixels in the distance do not blur over the top of pixels near the front. So a fast moving car behind a lamppost, will not blur the lamppost in the foreground.
1. When rendering pixels, store the velocity of that pixel (relative to camera) into a 'velocity' buffer.
2. Do a post process on the final image, whereby you blur pixels in the direction and magnitude of that pixels velocity.
3. Remove banding on the motion blur, by doing a random texture lookup on a gray scale noise texture and use that value (0-1) to offset where you take the samples from. That effectively removes the banding.
4. With access to the Z-buffer as well, you can make sure pixels in the distance do not blur over the top of pixels near the front. So a fast moving car behind a lamppost, will not blur the lamppost in the foreground.
This is a more common method, but it isn't true motion blur. No image-based effect can be.
I agree, but this is the closest we can get which doesnt require multiple frame renders (costly), and the blur is relatively accurate to the average users eye.
There is a motion blur example using the accumulation buffer in the OpenGL Red Book. It's available free online so have a look at that. [smile]
I think that the idea described in that article( this one to be exact) is completely useless in real-time. Why? This sentence reveals it all:
Trying to accomplish this in modern games where the rendering already goes multipass is completely impossible. That would mean having e.g. 6 passes(one per light) * 4(just to stick with the above-mentioned example) just to have a motion blur :) In my honest opinion that is insane.
There's is a much better(i.e. maybe not that accurate, but accurate enough to be unnoticable by the human eye, and a lot faster as well)technique out there. There have been a interesting discussion on this topic here at GD.net, check this out.
Quote:Written in that article on freespace.virgin.net
For example, to create a 4 second animation with 100 motion-blurred frames, you might begin by rendering 400 frames
Trying to accomplish this in modern games where the rendering already goes multipass is completely impossible. That would mean having e.g. 6 passes(one per light) * 4(just to stick with the above-mentioned example) just to have a motion blur :) In my honest opinion that is insane.
There's is a much better(i.e. maybe not that accurate, but accurate enough to be unnoticable by the human eye, and a lot faster as well)technique out there. There have been a interesting discussion on this topic here at GD.net, check this out.
Quote:Original post by Hybrid
I agree, but this is the closest we can get which doesnt require multiple frame renders (costly), and the blur is relatively accurate to the average users eye.
I've seen once some pictures done with this method (ray traced offline) and it looked really good! If it can give 'decent enough' results in a high quality raytracer, then I suppose that in a real time app it will be more than enough...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement