pouët.net

Go to bottom

Random adding motion blur to demo captures thread

category: offtopic [glöplog]
Some of stills of my motion blur experiment on demo captures

First method result:
BB Image

Crap.


New method results:
BB Image

BB Image

BB Image


Debris clips:
Full frame-to-frame motion blur - standard simple stuff, "incorrect" to some people. mp4, 24 fps
Shutter motion blur - motion blur at 48 fps, then drop every other frame. Suppose to be like a movie-camera output or such. mp4, 24 fps



My method is capturing demos at 120 fps, then use a motion estimator library to take it to 960 fps [or more..], then simply merge all the frames down to whatever target fps. No blur filter required or used. But this does use a hell of a lot of CPU time. The results are pretty though and rather accurate. Wanted to release more motion-blurred clips, but never got around to it. That, and I think I lost my code in a file system crash.

Why? Purely curiosity. Not about to start releasing my demo caps with motion blur; I'll leave that up to Trixter. :)

[/thread]
added on the 2009-10-26 04:47:07 by micksam7 micksam7
Looks nice. Would be great to see some full captures of demos with this :)
added on the 2009-10-26 09:09:21 by xTr1m xTr1m
Why haven't I heard that version of the "Debris"-soundtrack before?
added on the 2009-10-26 09:21:34 by gloom gloom
micksam7: Awesome. I guess using the motion vectors directly to blur should be a lot faster, and it should yield (roughly) the same results. But this is definitely cool. One of the bigger benefits of it is that you can lower the frame-rate and still get acceptable results, compared to non-motion blurred results (as you already did by going down to 24fps, which usually looks crap for demos). Perhaps it also allows to compress a bit harder, due to less high frequencies?
added on the 2009-10-26 15:35:23 by kusma kusma
It looks very cinematic... I like it
added on the 2009-10-26 15:45:26 by texel texel
awesome idea.
added on the 2009-10-26 16:43:38 by Claw Claw
kusma: Using motion vectors from video files for any kind of effect or analysis is usually a bad idea. The reason is that in many cases, they do *not* specify the actual direction in which things move ("true motion"). They only point to some arbitrary position in the image that happens to look like the (macro)block in question. In ~90% of all cases, they will be close to true motion, but the remaining 10% of the vectors won't play nice and lead to really annoying artifacts. So nothing saves you from a full-scale motion analysis, and even then you can't generate 100% correct motion vector fields.

Aside from that, using motion estimation to generate nice motion blur looks tempting. However, I still doubt that it would really work all that well for artificial image content (read: demos). In "real", natural images, there's always some kind of texture on objects the motion estimator can lock to. A lot of demos and games, however, have large areas of (nearly) uniform color where proper tracking of motion, especially at object edges, is next to impossible.
On the other hand, I have seen demos on commercial "100 Hz" TV sets (which also use motion estimation to interpolate between images, which is not all that different from adding artifical motion blur) with surprisingly good quality (considering how badly they fail on some natural image content), so it might be worth a try.
added on the 2009-10-26 16:50:55 by KeyJ KeyJ
Looks great on debris. I'd much prefer to watch the motion blurred version than the normal one, even at 24fps instead of 30 (30 would still be preferred to 24 of course :))

On the other hand, I can't see it working so well for those demos with 1-frame screen flashes and the like. For some effects, you'd effectively lose detail rather than gaining motion blur too. So overall, it's maybe a bad idea to apply it to every demo.

Also, some effects are frame-rate dependent (yeah, maybe they shouldn't be, but it happens) so rendering at 120fps and reducing to 24 is going to really mess up the effect speed.

Considering how much cooler it looks, I'd be very happy to see this applied to the more 'cinematic' demos.
added on the 2009-10-26 16:57:39 by psonice psonice
KeyJ: I wasn't talking about using MPEG motion vectors. AFAICT, he hasn't compressed the video yet, so most likely there are none. The motion estimation library is probably using different algorithms than MPEG compressors.
added on the 2009-10-26 17:02:44 by kusma kusma
I didn't expect this thread to pick up much :(

gloom - That's the soundtrack that I've always heard, unless I accidentally added the wrong audio file [wouldn't be the first time]

KeyJ - So far, using motion estimation seems to be working out very well. Note I am using a high rate source in the first place.

kusma - Yes, it does allow me to lower the bitrate drastically

All - I recovered my code. I'll get a full sample or two done today I suppose..
added on the 2009-10-26 17:09:33 by micksam7 micksam7
kusma: OK, I see.

micksam7: Yes, the higher the input frame rate, the shorter the motion vectors, and the smaller the possible motion vector errors. So I'd be surprised to see any noticeable artifacts when going from 120 to 960 anyway :) I was rather talking about using more modest frame rates in the 48-60 Hz (or even 24-30 Hz) range to limit the computational complexity.
added on the 2009-10-26 17:30:55 by KeyJ KeyJ
KeyJ, doesn't that entirely depend on which motion estimation technique that is used? granted, it's never 100% perfect, but it is possible to use motion estimation algorithms that were actually intended for predicting true motion, instead of those used for compression algorithms.

i've no clue exactly what is out there, but did churn out an implementation of the "3D recursive search" algorithm (G. de Haan) at some point, which is intended exactly to (efficiently) produce true motion vectors (used in TV upconverters). it worked very well for me (and *significantly* better than some open source motion estimators from compression packages)
added on the 2009-10-26 17:36:39 by skrebbel skrebbel
more on-topic, imho the "true motion" upconverter from MVTools (for AVISynth) produces rather decent results. It's open source and rather well structured, so getting the motion vectors only shouldn't be too complicated.
added on the 2009-10-26 17:38:27 by skrebbel skrebbel
micksam7: Perhaps you should consider trying some Gaussian weighting of the frames instead of simple avarage (unless you're already doing that, of couse)?
added on the 2009-10-26 17:49:50 by kusma kusma
BB Image

Captures coming after a few hours of cpu time..
added on the 2009-10-26 19:55:38 by micksam7 micksam7
kusma: nah, real camera motion blur actually is very close to a box filter (the incoming photons don't have any more influence in the middle of the exposure than they have at the beginning or end), and using different filters gives results that just look weird.
added on the 2009-10-26 20:07:46 by ryg ryg
the result is quite hard to notice. if nobody told me about it i will never have see a difference just by watching the video. however, thats a nice effect, with this these demos looks more like cg.

i'm wondering : how did raytracers do for 3d movies (eg: in "toy story" , while some balls are bouncing, they are blurred)

did the raytracers use objects velocity vectors (they have the full 3d scene and their properties) and then blur objects locally?

or did they use similar techniques as here (thus movement analysis by checking whats happening between two frames), thus after rendering ?

also: i'd curious to know how these fake motion blurs should render on old msdos demos/intro from 90's. maybe their resolution/color space is just not big enough to make something good
added on the 2009-10-26 23:12:05 by Tigrou Tigrou
I dunno, I just watched this, but I think it looks fantastic. :)
added on the 2009-10-26 23:55:35 by rc55 rc55
ryg: Aha, OK.

Tigrou: Good motion blur is hard to see. I think the main benefit is that the frame-rate can be lowered without crippling the motion-"feel", thus reducing the file-size drastically.
added on the 2009-10-27 00:00:55 by kusma kusma
tigrou: afaik motion blur in Pixar's Renderman is done by REYES -that is the micropolygons thing- and the effect should be based in the micropolygons, so it looks as a rasterization effect, so probably it is not raytracing
added on the 2009-10-27 00:09:57 by texel texel
Post processing motion blur has exactly the same problems has DOF... that's my retarded comment for the day.
added on the 2009-10-27 01:28:11 by xernobyl xernobyl
*has,
that was my standard grammar error for the day.
added on the 2009-10-27 01:28:41 by xernobyl xernobyl
*as
this was the correction.
added on the 2009-10-27 01:29:11 by xernobyl xernobyl
You'll probaly never get good results !! .. Motion-Blur is a tricky thing ..

I've thought about a deferred shading like technique .. encoding normal and motion vector fields delivered from the rendering-engine on IPP-shader base .. with X264 GMC motion frames for semi camera-wise vector fields .. and a lil bonus from local-motion objects in a 'disturbance' function ..

It could also do Post-Displacement-Mapping .. on the other hand ..

It's just an idea for IPP .. working with the capturix .. throwing my thoughts ..
added on the 2009-10-27 02:49:16 by yumeji yumeji
The debris-motionblur-2424 already looks really great! It's like debris by Dreamworks or something.

The only strange thing is: in debris-motionblur-2448, the shaking of the camera that is supposed to happen in the first shot is a lot more noticeable than in 2424.
added on the 2009-10-27 03:04:02 by yesso yesso

login

Go to top