Motion blur

[iceman]

sorry but isnt jumping around all over the place the standard behaviour for windows armagetron ? well thats what I have been putting up with for 2 years maybe its wrong ? who knows

[hang3r]

no iv never had any problems, untill i messed with GetTime

[Z-Man]

The problem with the milliseconds was that frequency/10^6 adds too much rounding error; for me, frequency was just about 3.5 * 10^6. You have to multiply the time with 10^6, then divide the result by the frequency. All while taking care not to produce overflows. I added the corrected suggestion to CVS and made it so that if the high performance counter is available, the game time is no longer smoothed. Hooray! Under what name do you want to be credited in the AUTHORS file?

[Lucifer]

Hey, did anybody's motion blur code ever get put in cvs? If not, nd someone still has some good performing stuff, could they post it here? I'd like to add it as a configuration option, at least. Having it there means someone will theoretically improve it, you know.

[Z-Man]

The hacks discussed here are not really suited for general use. The real place to do it would be the game loop. There, we also have the option NOT to simulate the full physics each sub-frame, but using extrapolation only. This could gain us some FPS. Maybe I have time for it the next days.

[andi75]

http://www.bit-tech.net/gaming/2005/12/ ... cts/1.html

shows a few examples of Motion Blur in Call of Duty 2, and why just reusing previous frames is *not* a good idea.

[Z-Man]

and why just reusing previous frames is *not* a good idea.

Yep, that's why we don't do it We were experimenting with the accumulation buffer technique.

[Jonathan]

Indeed, Andreas. I had to explain the difference all the time to people new to the thread. Averaging with the previous frame is not quite the same as averaging uniformly-distributed samples within a frame. I'm beginning to feel the urge to draw an example in space rather than time.

[andi75]

However, you'll need to average quite a few samples for it to look good. Apparently CoD 2 with all the shiny new effects enabled (DOF, HDR & motion blur) runs at 0.5 FPS on current high end (e.g. gf 6800 and up) hardware.

I think the best 'bang-for-the-buck' motion blur these days is to use this approach:


- Draw the scene to the z-buffer
- For each object in the scene, compute its screen-space motion vector between the current and the last frame:
- Group objects with similiar motion vectors, and render them to a buffer (using the current z-buffer and GL_LEQUAL)
- For each buffer, draw a fullscreen quad. At each pixel, sample n-pixels into the direction of the buffer's average motion vector. Accumulate these samples and store the result into the frame buffer.

I stole the basic idea from ATIs "Ruby" demo. Too bad I haven't had the time to come up with a demo yet.

[Z-Man]

I can see how that works well for
a) a FPS game where the main blur comes from the camera spinning around its current position
b) rain
c) a strategy game or top-down racer where the camera stays at a fixed angle
It does not sound too good for racing games (where the main motion blur comes from the camera speeding forward -> many different movement vectors) or, sadly, our games except in the camera a la c). The smart and custom cameras in AA rotate quickly around a point far away of the current camera position. That, too, leads to too many different movement vectors. If you want to cheat, you have to store the movement vectors per pixel and make your post-process filter use that per-pixel information. Possible? Certainly. Worthwile? Perhaps. Do *I* have time for that? Certainly not The bang-for-buck ratio of the accumulation buffer blur, if your bucks is measured in hours spent coding, clearly beats all pixel shader trickery. We basically have it working, Jonathan is happy with the performance, I don't like it because my LCD screens add more than enough blurring for my tastes, but who cares what I think?

[Jonathan]

Jonathan is happy with the performance

Not exactly. The way I implemented it (hack the buffer swap function) multiplies both CPU and GPU requirements for a certain framerate, with some extra load for the GPU. At lower resolutions I could maintain my refresh rate, but at higher resolutions (which I prefer over motion blur) it gets slow, as well as when I get seriously CPU-bound with lots of walls. I know the CPU thing can be improved though, as nemo once got better framerates with what I think was another 7450 (I have a 7457), but clocked at <2/3 the speed, when we were both CPU-bound on a complex map. Note: I think the other hardware had a similar speed difference, and that my GPU was A LOT faster. Possibilities: he had better optimization flags, or his slightly newer CVS version helped.

But, back on topic, I DID get playable speed out of it, though most playable means always maintaining the refresh rate to me.